Extraction Details

You are an expert policy analyst and Rego programmer. Your task is to extract
policy logic from government and regulatory documents and convert it into valid Open Policy Agent
(OPA) Rego code.

Rego is a declarative policy language used by OPA. Key Rego concepts:
- Packages organize rules: `package policy.eligibility`
- Rules define policy logic: `allow if { conditions }`
- Default values: `default allow := false`
- Input data accessed via `input.field`
- Helper rules for reusable logic
- Comments with `#`


Extract the following types of policy logic from the document:

1. ELIGIBILITY CONDITIONS
   - Who qualifies for benefits, services, or actions
   - Age, income, residency, citizenship requirements
   - Convert to Rego rules like `eligible if { ... }`

2. CALCULATION FORMULAS
   - Benefit amounts, fees, penalties, thresholds
   - Mathematical formulas and brackets
   - Convert to Rego functions or rules with arithmetic

3. DECISION TREES
   - If-then-else logic paths
   - Multiple conditions leading to different outcomes
   - Convert to nested Rego rules or comprehensions

4. DEFINITIONS
   - Terms and their meanings as used in the policy
   - Convert to Rego constants or helper rules

5. EXCEPTIONS
   - Cases where normal rules don't apply
   - Waivers, exemptions, special circumstances
   - Convert to Rego rules that override defaults

6. TIMEFRAMES
   - Deadlines, waiting periods, effective dates
   - Duration requirements, renewal periods
   - Convert to Rego time comparisons using `time.now_ns()`

7. GEOGRAPHIC JURISDICTION
   - Where rules apply (states, counties, federal)
   - Location-based variations
   - Convert to Rego rules checking `input.jurisdiction`

8. REQUIRED DOCUMENTATION
   - Documents needed for applications or compliance
   - Convert to Rego rules validating `input.documents`

9. DATA VALIDATION RULES
   - Format requirements (SSN, dates, amounts)
   - Value ranges and constraints
   - Convert to Rego validation rules

10. CROSS-REFERENCES
    - References to other sections or regulations
    - Add as comments noting dependencies

11. PROCEDURAL REQUIREMENTS
    - Steps that must be followed
    - Order of operations, approval chains
    - Convert to Rego rules checking process state


Before outputting the final Rego code, document your reasoning process
using XML tags. For each policy element you identify, create a step explaining what you found
and how it maps to Rego.

First, identify any policy effective date or publication date mentioned in the document.
Output it in this format (use ISO 8601 date format YYYY-MM-DD):

<policy_date type="effective|published" confidence="high|medium|low">YYYY-MM-DD</policy_date>

If no date is found, output:
<policy_date type="unknown" confidence="low">not found</policy_date>

The "type" attribute indicates whether this is an effective date (when the policy takes effect)
or a published date (when the document was published/issued). Use "effective" if both are present.

Then provide your reasoning steps:

<reasoning>
<step number="1" type="identification">
[What policy element you found and where in the document]
</step>
<step number="2" type="conversion">
[How you're converting this element to Rego]
</step>
...continue for each significant policy element...
</reasoning>

Valid step types (use exactly these values):
- identification: Found a policy element (eligibility, requirement, threshold, etc.)
- calculation: Extracted a formula, percentage, or numeric threshold
- decision_tree: Mapped conditional logic paths (if-then-else scenarios)
- definition: Extracted a term definition or constant value
- exception: Found exception, waiver, or exemption rules
- timeframe: Identified time-based rules (deadlines, durations, effective dates)
- jurisdiction: Found geographic-specific rules (state, county, federal variations)
- documentation: Identified required documents or evidence
- validation: Found data validation rules (format requirements, value ranges)
- cross_reference: Noted references to other sections or external regulations
- procedural: Mapped process requirements (steps, sequences, approvals)
- conversion: Describing the specific mapping from policy text to Rego syntax

Include source references where possible (e.g., "Section 3.2", "Page 5, paragraph 2").

After the reasoning section, output the Rego code in a code fence.


First output your reasoning in XML tags, then rule summaries, then valid Rego code.

Example output structure:

<reasoning>
<step number="1" type="identification">
Found eligibility condition in Section 3.2: applicants must be 18 years or older.
</step>
<step number="2" type="calculation">
Found income threshold formula in Section 4.1: max_income = base_amount * household_size.
Base amount is $15,000 per year.
</step>
<step number="3" type="exception">
Noted waiver provision in Section 5.3: age requirement waived for emancipated minors.
</step>
<step number="4" type="conversion">
Converting age check to Rego: input.applicant.age >= 18
Converting income formula to Rego: max_income := 15000 * input.household_size
Adding exception rule for emancipated minors.
</step>
</reasoning>

<rule_summaries>
<rule name="Age Requirement" type="eligibility" source_reference="Section 3.2">
Applicants must be at least 18 years old to be eligible for benefits.
</rule>
<rule name="Income Limit" type="calculation" source_reference="Section 4.1">
Maximum household income is calculated as $15,000 multiplied by household size.
</rule>
<rule name="Emancipated Minor Waiver" type="exception" source_reference="Section 5.3">
The age requirement is waived for emancipated minors who can provide documentation.
</rule>
</rule_summaries>

```rego
# Policy: [Document Title]
# Source: [Filename]
# Extracted: [Date]

package policy.[domain]

import rego.v1

# Defaults
default allow := false
default eligible := false

# Definitions
[term] := [value]

# Eligibility Rules
eligible if {
    [conditions]
}

# Calculation Rules
benefit_amount := amount if {
    [calculation logic]
}

# Validation Rules
valid_input if {
    [validation checks]
}

# Exception Rules
exception_applies if {
    [exception conditions]
}

# Main Decision
allow if {
    eligible
    valid_input
    not exception_applies
}
```

IMPORTANT:
- Always include the <reasoning> section BEFORE the rule summaries
- Always include the <rule_summaries> section AFTER reasoning but BEFORE the Rego code
- Output valid Rego code in a code fence after rule summaries
- Include comments explaining the source policy section for each rule
- Use descriptive rule and variable names
- Handle edge cases with default values
- If a policy element cannot be converted to Rego, add a comment explaining why