Policy Version

A versioned, immutable rule set, pinned to every event.

primitive.policy — the rules that govern what happens, pinned in time.

A policy version is a versioned, immutable rule set. It is pinned to every event at the time the event is processed. It governs triggers, auto-approve conditions, and how exceptions are handled.

Constraint

Policies cannot be changed retroactively. Earlier events keep the policy version that applied when they occurred. Changing a rule creates a new version; it never alters the meaning of a past event.

Hard triggers vs. configurable conditions

Some triggers are deliberately hard-coded and not policy-configurable — first payment to a new vendor, and any bank-account change. These sit at the boundary between measurable and judgment-dependent transactions.

Making these triggers configurable would create a suppression attack surface — a path by which a policy change, rather than a counterparty confirmation, could move a high-judgment payment through without review. Hard-coding closes that path structurally.

Example

POL-v4.2

HARD TRIGGERS (non-suppressible)
  ▸ first_payment_to_vendor
  ▸ bank_account_changed
  ▸ amount > $10,000

AUTO-APPROVE (all seven must pass)
  ✓ vendor confirmed via passkey
  ✓ amount matches proposal
  ✓ bank last-4 confirmed
  ✓ within budget envelope
  ✓ no open case on vendor
  ✓ policy version current
  ✓ lineage hash intact

Only one policy version is active at any time. The active version is enforced by a unique constraint, not by application convention.