Where behaviour lives
Schema stops at the field; validation, state transitions and background jobs are documented separately, in the system-design corpus.
Everything up to this stage describes schema — entities, fields, and the relationships between them. None of it says what happens when a document is submitted, what runs in the background, or what a concurrent edit does to a ledger. That is a different kind of document, and it lives under System designs: 73 vendor-neutral write-ups of the behaviour behind this data model — validation, state transitions, idempotency, concurrency, and what tends to break as a system like this grows.
Start with these four
They pair directly with the core model (stage 2) and the core four (stage 3):
General ledger & multi-currency posting
How a submitted transaction becomes a balanced set of GL Entry rows, and how cross-currency amounts are converted at write time.
Inventory valuation & stock ledger
How a stock movement becomes a valuation-rate-aware Stock Ledger Entry, and where moving-average and FIFO/LIFO costing diverge.
Ledger integrity, repost & self-healing
What “append-only” costs when a posted ledger drifts, and how that’s detected and repaired without an in-place edit.
Approval authorization & transaction limits
How a value-based rule blocks submission until the right role signs off — the enforcement layer no ERD shows.
Reading the rest
Each of the 73 documents follows the same six-section shape — Requirements, High-Level Design, Deep Dive, Scale and Reliability, Trade-off Analysis, and what to revisit as the system grows. The System designs overview groups them by the same areas as the entities they describe; start from whichever module you read in stage 3 and are most curious about.