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.

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.

The seven

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

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

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

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

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

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

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

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.

See five of the seven enforced in a working build

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.