For decades, enterprise software has been built around the system of record — a database that holds the authoritative copy of what an organization believes to be true. Each party keeps its own. The buyer’s ERP records one version of a transaction; the vendor’s records another. The trouble is structural: two systems of record for the same transaction will, eventually, disagree. When they do, both sides reconstruct the truth from email threads, PDFs, and memory. That reconstruction is what we call reconciliation, audit, and dispute resolution — and it is enormously expensive.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.
The coordination model
A system of coordination does not store two copies and reconcile them later. It produces one record that both parties co-author at the moment of agreement.| Systems of record | Systems of coordination |
|---|---|
| Each party keeps a private copy | One co-authored record |
| Truth is reconstructed after the fact | Truth is established at the moment of agreement |
| Reconciliation is a permanent cost | Reconciliation is structurally unnecessary |
| Trust is assumed from origin | Trust is verified at the point of action |
When both parties co-author the same event, there are no two independent records to reconcile. Agreement is guaranteed by construction, not recovered by effort.
Why now
This shift was always desirable; it is now urgent. As execution gets cheaper and faster — and increasingly performed by autonomous agents — the volume of transactions that would need reconstruction grows faster than any team can reconstruct them. The only scalable answer is to produce the proof once, at the moment of coordination.Why reconciliation should not exist
The deterministic-commerce argument in full.