Work Order

The container holding the full context and decisions for a payment.

primitive.work_order — where the accounting work happens between an event and a ledger entry.

A work order is the container that holds the full context and decisions for a payment. It tracks three parallel states — Authorization, Control, and Settlement — without collapsing them into one.

Constraint

Every decision is recorded as an immutable event. The work order does not store a mutable “current status” that overwrites history — each transition appends to the decision log.

The three tracks

Authorization

Has the counterparty co-authored the terms? Advances on a bilateral confirmation event.

Control

Has policy cleared the payment? Records auto-approval or the approver’s identity.

Settlement

Has value moved and posted? Tracks posting generation and ERP export.

Keeping the three tracks separate is what lets CAST express states the single-status model cannot — for example, confirmed by the vendor but held pending budget review, or approved but not yet settled.

Why the decision record matters

An auditor testing a transaction asks three questions: who approved this, why, and what did they know at the time? Under the old model, the answers require reconstructing from email, ERP entries, and memory. Under CAST, the work-order decision record answers all three directly.

A signature without context is a claim. A signature with a decision record — the conditions evaluated, the budget position, the approver’s identity — is a proof. CAST produces the proof.