> ## 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.
# CAST Field Guide
> Both parties sign before the money moves. A bilateral coordination protocol for commercial payments — and the verification layer beneath an agentic economy.
This is the CAST Field Guide — our thinking on trust, settlement, and accountability, and the architecture beneath them. For the product itself, see [cast.digitalfinancehq.com](https://cast.digitalfinancehq.com).
## Both parties sign before the money moves.
CAST adds a mutual authorization step before a payment is released. Both parties co-author one cryptographically bound record of the transaction — who is paying, who is receiving, how much, and where it goes. That record becomes the authorization, and it travels with the payment through the ERP, the audit, the lender, and the insurer as tamper-evident proof.
The proof is produced once, at transaction time. Verification cost drops to near zero, because checking a hash is structurally cheaper than reconstructing a decision chain.
## The problem
Every commercial payment today is authorized by one side. The payer approves an invoice internally; the counterparty learns of the transaction only when — or if — the money arrives. A process where only one party has confirmed the terms before value moves is not a bilateral authorization. It is a unilateral instruction with a hope attached.
The cost is concrete: roughly **\$2.9B** in annual U.S. losses to Business Email Compromise, plus the reconciliation drag, audit archaeology, and lender friction that follow from records no downstream party can trust without re-checking. This is not a software bug to patch — the trust model under commercial payments was never bilateral.
## The causal chain
The business logic is one line: unilateral approval is what lets fraud, disputes, and reconciliation happen — and mutual authorization is what removes them, leaving proof behind.
```mermaid theme={"dark"}
flowchart TD
A[Unilateral approval
one party authorizes] --> B[Fraud · disputes · reconciliation
the counterparty never confirmed]
B --> C[CAST mutual authorization
both parties co-author the record]
C --> D[Proof before release
tamper-evident, independently verifiable]
style A fill:#fff,stroke:#df1b41,stroke-width:2px,color:#0a2540
style B fill:#fff,stroke:#f5a623,stroke-width:2px,color:#0a2540
style C fill:#f5f3ff,stroke:#635bff,stroke-width:2px,color:#0a2540
style D fill:#f0fdf4,stroke:#15be53,stroke-width:2px,color:#0a2540
```
## The reframe
Stopping payment fraud is the door most people walk through. Behind it is a larger shift. As AI commoditizes execution — the cost of generating financial output approaches zero — the binding constraint moves from **production** to **verification**. The question stops being *can we produce this output* and becomes *can we prove this output is trustworthy.*
**Verification is the invariant.** CAST replaces opinion-based reconstruction — an auditor reading email threads — with proof-based verification: a lineage-hash check anyone can run, without contacting either counterparty. This is the verification-bottleneck thesis (Catalini, Hui & Wu, 2026) made concrete.
## Why now
Businesses already spend billions validating transactions *after* they execute — reconciliation, audit, dispute resolution, fraud recovery. As AI drives transaction volume up and execution cost toward zero, that after-the-fact model breaks. Verification has to move earlier — to the moment of agreement, before value leaves the building. CAST is that shift made concrete.
## Start here
The thesis in five minutes, and the shift from systems of record to systems of coordination.
Event, Policy Version, Work Order, Posting, Case. Everything else is a projection of these five objects.
Structural impossibilities enforced in the schema — controls that remove the failure, not just throttle it.
Why accounts payable is the first deployable proof of a vertical-agnostic architecture.
## The architecture, briefly
CAST is built on five canonical objects, with lineage — the immutable hash chain — running through all of them. The guarantees are enforced where they survive every refactor: in the schema, not the application.
A portable proof history the counterparty owns and carries across every buyer — the network that compounds.
The settlement layer beneath an agentic economy: even a perfectly-secured agent's payment requires bilateral co-authorship.
Original essays on deterministic commerce, zero trust, and liability as a service.
A working build — one bilateral payment, with a verifier that recomputes the proof in the browser.
## The takeaway
Spend thirty minutes here and the conclusion should be unavoidable: CAST holds a fundamentally different model for how work, trust, settlement, AI, and accountability should operate — one where agreement is guaranteed by construction rather than reconstructed after the fact.
**Confirm & Pay is the first CAST application** — accounts payable, built on the mutual-authorization protocol described throughout this guide. It is one instantiation of the architecture, not the whole of it.
The product, live — how mutual authorization stops fraud before release.
Book a walkthrough of the Layer 0 demo, or reach out — [contact@digitalfinancehq.com](mailto:contact@digitalfinancehq.com).