Documentation

Policy bundles

Policy Bundles

A policy bundle is a versioned set of rules that codifies a domain's invariants. It's what the gate evaluates a proposed action against. Bundles are how the same deterministic gate governs finance, coding, support, and voice — only the bundle differs.

The gate is bundle-agnostic. It doesn't know finance from coding. It evaluates whatever bundle the caller names.

Anatomy of a bundle

A bundle has:

  • A stable id (finance.recon.v0, coding.contracts.v0).
  • A version (v0.1.0) — bumping it creates a new row; old decisions pin to the version that produced them.
  • A status (active, draft, deprecated).
  • A list of rules, each with a type that decides how it's evaluated.

Rule types

| Type | Evaluated by | Example | | :--- | :--- | :--- | | invariant | Deterministic checker (no LLM) | "Proposed balance must equal the locked opening balance." | | assertion | Deterministic checker | "Response shape must match the API contract." | | forbidden | Deterministic checker | "Diff must not contain a forbidden string." | | qualitative | LLM grader (see The Validation Gate) | "Is this refund explanation coherent given the ticket history?" |

Deterministic rules run in the gate directly. Qualitative rules are delegated to the grader, which returns a band the gate consumes (PASS / CHATTER / REJECT). Grader scores. Gate decides.

Bundle #1 — finance.recon.v0

The proof case for high-stakes auditable workflows. Its rules catch the failure mode finance auditors fear most: an agent claiming a per-entity balance the data doesn't support (un-attributed drift). A clean per-entity balance that isn't derivable from the data produces a denied verdict — that's the feature, not a limitation.

Bundle #2 — coding.contracts.v0

The bundle that lets Mnemix dogfood itself. Five deterministic rules catch the drift modes that plague coding agents after long context:

  1. api_contract_preserved — a route-handler change must not alter the response shape declared in a locked fact. Denied.
  2. dependency_version_pinned — a package.json change must not bump a pinned version without an override evidence ref. Denied.
  3. test_runner_consistency — if the locked fact says test runner = vitest, an import of jest/mocha/chai is denied. Denied.
  4. file_path_resolved_correctly — a referenced file or symbol must resolve to a known entity; if unresolved, needs_human (catches hallucinated file paths).
  5. mission_scope_preserved — a change must stay within the mission contract's declared scope. Denied on out-of-scope edits.

Two wildly different domains — finance and coding — same architecture, same gate, same primitives. That's the domain-agnostic proof.

Versioning and rerun stability

Bundles are rerun-hash stable. A verdict records the exact bundle version that produced it. When you bump finance.recon.v0 from v0.1.0 to v0.2.0, every prior verdict still re-runs against v0.1.0 and returns the identical result. This is what makes the audit guarantee hold across time.

Never silently mutate an active bundle. Bump the version. Old verdicts must reproduce.

Authoring rules (today) vs. learning them (later)

For v1, bundle authoring is human. The feedback loop already collects the data that could someday let bundles be learned from outcomes, but that's a research path, not a current capability. The substrate is ready for it; the product doesn't ship it yet.

What's out of scope (v1)

  • Multi-bundle composition — one bundle per gate call.
  • Bundle marketplace — a later phase, after bundle-agnosticism is proven with two live bundles.

See also