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

# The seven structural invariants

> Seven non-relaxable constraints enforced at the schema level — structural impossibilities, not application rules.

CAST's guarantees do not depend on the application behaving well. Seven structural invariants are enforced at the schema level — through foreign keys, triggers, rules, and unique indexes — so they hold against a bug, a migration, or a direct database write. They are structural impossibilities, not policies the code is trusted to follow.

<Note>
  An invariant enforced in application code is a promise. An invariant enforced in the schema is a fact. These seven are facts: there is no code path, including a direct `INSERT`, that can violate them.
</Note>

## The seven

<Steps>
  <Step title="A Posting requires a Bilateral Event">
    Every ledger entry carries a non-nullable foreign key to the bilateral event that authorized it. A posting with no co-authored event behind it cannot be inserted.
  </Step>

  <Step title="A Bilateral Event requires a confirmed Work Order state">
    The co-authored event cannot exist unless the Work Order has reached the confirmed state — authorization precedes the record, not the other way around.
  </Step>

  <Step title="Lineage hash chain integrity across all events">
    Every event's lineage hash chains to the prior state. A break in the chain is detectable, so tampering cannot pass silently.
  </Step>

  <Step title="A single active Policy Version at any time">
    A partial unique index makes "more than one active policy" unrepresentable. Exactly one policy governs at any moment.
  </Step>

  <Step title="Settlement export requires an approved Control track">
    Value cannot be exported for settlement unless the Work Order's control track has reached approved — the decision is a precondition to the disbursement.
  </Step>

  <Step title="Hard-coded triggers cannot be policy-suppressed">
    First payment to a new vendor and any bank-account change are hard-coded triggers. No policy change can suppress them — closing the path by which a configuration edit, rather than a confirmation, moves a high-risk payment through.
  </Step>

  <Step title="Events are append-only — no updates, no deletes">
    The event log only grows. A correction is a new event, never an edit. The system never updates or deletes an event.
  </Step>
</Steps>

## Why seven, and why at the schema level

These are the invariants of the **full architecture**. They span the whole lifecycle — from the authorization gate, through the control decision, to settlement export — and they hold system-wide properties like lineage integrity and single-policy governance.

Placing them in the schema rather than the application is the entire point. Application code changes weekly; the schema changes rarely and survives every refactor. A verifier reading the database in 2031 — with no access to the application that ran in 2026 — can confirm all seven held, because the constraints are part of the data model itself.

<Card title="See five of the seven enforced in a working build" icon="code" href="/implementation/layer-0-demo">
  The Layer 0 demo operates on the bilateral loop and enforces five of these seven today; settlement-stage invariants are exercised as that scope is built.
</Card>