CAST in 5 minutes

The mental model that makes everything else legible.

Everything in CAST is an event or a projection of events. The flow below is the mental model the rest of the guide builds on.

The CAST flow

Event
  ↓
Policy Version
  ↓
Work Order
  ↓
Posting
  ↓
Case  (only on exception)

And running through all of it: lineage() — the immutable hash chain that binds every step back to the originating event.

Lineage is a property of the chain, not a sixth object. It is what makes a posting traceable to the event, decision, and policy version that produced it.

How to read the flow

1. An event is recorded

   Something happens — an invoice arrives, a vendor confirms, a payment settles. Events are append-only. No updates, no deletes, ever.

2. A policy version governs it

   Each event is pinned to the immutable policy version in force at the time. The policy decides what needs authorization, what auto-approves, and how exceptions are handled.

3. A work order holds the context

   The work order is where the accounting work happens between an event and a ledger entry, tracking authorization, control, and settlement in parallel.

4. A posting is produced

   Only after mutual authorization is complete does a journal-ready posting exist — carrying its full history back to the originating event.

5. A case opens on exception

   A dispute, non-response, or budget breach becomes a governed case. Resolution events are appended; nothing prior is ever rewritten.

The shift this represents

The ledger has historically been the system of record. In CAST, the event log is the system of record, and the ledger is a projection of it. That inversion is the heart of the architecture.

The ledger is no longer the system of record

Why the event log is primary and the ledger is derived.