Policy bundles

Policy bundles are the design for versioned rules that a validation gate can evaluate against a proposed action. They are not part of the frozen public caller-memory API, and this page is architecture guidance rather than a callable integration contract.

DESIGN STATE. Do not create production dependencies on the example bundle IDs, rule types, payloads, or verdict persistence shown here until a deployed contract graduates.

Intended shape

A bundle would identify:

• a stable bundle ID and explicit version;
• lifecycle status such as draft, active, or deprecated;
• deterministic invariants, assertions, and forbidden conditions;
• qualitative rules delegated to an isolated grader;
• the exact facts and evidence required by each rule.

Versioning is essential because a later rule change must not silently rewrite what an earlier decision was evaluated against.

Intended evaluation boundary

proposed action
  + versioned bundle
  + relevant evidence/facts
  -> deterministic checks
  -> optional isolated qualitative grading
  -> external verdict design: allowed | denied | needs_human

The model grader, where used, supplies a bounded assessment; the server-side gate owns the verdict. An agent or client must not recreate the policy decision in its prompt.

Examples are illustrative

Finance reconciliation and coding-contract bundles appear in internal designs because they exercise different failure classes. They do not establish that those bundles are public, deployed for customers, or proven across domains.

Graduation requires a source-defined runtime, persisted versioned bundles, negative tests that observe denial, evidence-linked verdicts, rerun behavior, tenant isolation, and a public or contracted interface.

Continue with Validation gate, Locked facts, and Evidence references.