Policy Logic as Versioned Interfaces
Policy is the operating system of public services. Agents must treat it as a formal, versioned interface. Every rule an agent applies must be traceable to an authoritative source, at a specific version, at a specific point in time.
1.1 Canonical Representation of Policy
Each agency or service provider shall publish a single authoritative expression of its policy rules for each program or service domain. This canonical representation serves as the sole source of truth for agent behavior.
Requirements
- Machine-readable format: Policy rules must be expressed in a structured, parseable format that agents can consume directly.
- Human-readable companion: Every machine-readable policy expression must have a corresponding plain-language version accessible to caseworkers, applicants, and oversight bodies.
- Consistency guarantee: The machine-readable and human-readable versions must be generated from the same source or verified as equivalent. Divergence between the two is a compliance failure.
- Scope declaration: Each policy expression must declare its scope — what programs, populations, geographies, and time periods it covers.
- Dependency mapping: Where policy rules depend on external data sources (income thresholds, federal poverty levels, regulatory definitions), those dependencies must be explicitly declared with source references and update schedules.
Policy that cannot be read by both a machine and a person cannot be accountably enforced by either.
1.2 Version Control Requirements
Policy changes over time. Agents must always know which version they are applying. Every determination must be permanently linked to the version that produced it.
Requirements
- Unique version identifiers: Every policy update — substantive rule change, threshold adjustment, or clarification — must receive a unique version identifier.
- Determination anchoring: Agents must carry the policy version identifier in every determination, recommendation, or action they produce.
- Appeals and review references: Any appeal, review, or audit must be able to reference the exact policy version in effect at the time of the determination.
- Transition rules: When policy versions change, the canonical source must specify transition rules — whether pending cases are grandfathered, re-evaluated, or handled under specific transition logic.
- Rollback capability: Systems must retain prior policy versions in full and support re-evaluation of a case under a previous version for appeals, audits, or error correction.
1.3 Reasoning Attachments
Every action an agent takes must produce a reasoning file — a structured record of how the agent arrived at its determination. This is a core output of the system.
Required elements
- Inputs received: The complete set of data inputs the agent used, including sources and timestamps.
- Policy version applied: The specific version identifier of the policy rules the agent followed.
- Rule path: The sequence of policy rules evaluated, including which branches were taken, which were bypassed, and why.
- Intermediate steps: Calculations, lookups, comparisons, or transformations the agent performed between receiving inputs and producing a determination.
- Confidence indicators: Where applicable, the agent's assessment of input quality, rule applicability, or determination certainty.
- Exclusions: Inputs the agent received but did not use, with an explanation of why they were excluded.
Example: Benefits Eligibility Determination
An agent evaluating benefits eligibility attaches a reasoning file showing: household income data (source: verified payroll records, retrieved 2024-03-15), policy version SNAP-2024-03-v2, rule path through household size calculation, income threshold comparison, and categorical eligibility check. The file notes that self-reported savings data was received but excluded pending verification, triggering an incomplete-information hold rather than a denial.