> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cast.digitalfinancehq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Policy Version

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

<Info>**`primitive.policy`** — the rules that govern what happens, pinned in time.</Info>

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

<Warning>
  **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.
</Warning>

## 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.

<Note>
  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.
</Note>

## Example

```text POL-v4.2 theme={"dark"}
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.