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

# Work Order

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

<Info>**`primitive.work_order`** — where the accounting work happens between an event and a ledger entry.</Info>

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

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

## The three tracks

<CardGroup cols={3}>
  <Card title="Authorization" icon="signature">
    Has the counterparty co-authored the terms? Advances on a bilateral confirmation event.
  </Card>

  <Card title="Control" icon="circle-check">
    Has policy cleared the payment? Records auto-approval or the approver's identity.
  </Card>

  <Card title="Settlement" icon="money-bill-transfer">
    Has value moved and posted? Tracks posting generation and ERP export.
  </Card>
</CardGroup>

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.

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