The engineer building the wallet demo had done the sensible thing and generated a ledger table full of realistic amounts and realistic balances. It demoed fine to the product team. Then a reviewer from finance opened it, ran her eye down the balance column, and asked why row three's balance was not row two's balance plus row three's amount. It was not, because the two columns had been generated independently. A ledger is not a set of independent numbers. It is a chain.
Here is the rebuild, which took less time than the original guesswork.
Step 1 · Describe the chain
Say what has to be true, in English
He opened Custom Schema and described the data instead of hand-designing columns. He did not need to know CrossRow's internal rule names. As it happened, the built-in example on the page was almost exactly a wallet ledger.
A sentence like "ledger entries carry a signed amount and a running balance per session that starts at the session's opening balance and reconciles exactly to the closing balance" was enough. CrossRow read that as a running-ledger rule and built the plan around it.
Step 2 · Check the plan understood you
The balance is a chain, not a column of guesses
In the plan, the balance was marked as a derived, time-ordered quantity tied to its parent session, not an independent number. That is the moment to confirm CrossRow understood the requirement, before spending a generation on it. Once generated, the entries chained cleanly within each session:
session entry amount balance S-204 1 open 3,000.00 S-204 2 -742.18 2,257.82 S-204 3 +1,010.00 3,267.82 S-204 4 -267.82 3,000.00 opens at 3,000.00, foots back to close
Step 3 · Let the reviewer be the report
Verification does the checking for you
The quality report includes a cross-row section that re-checks the ledger rule against the rows actually produced and reports the share of sessions that reconcile. This time the engineer did not wait for finance to catch a problem; the report confirmed every session footed before anyone opened the demo. That is the difference between a tool that claims an invariant and one that proves it on the output.
The same shape covers any chained-balance schema: bank accounts, inventory on hand, loan amortization, insurance reserves that wind down to zero. You describe the chain in a sentence, review that the plan caught it, and let the verification confirm it foots. You never write the recurrence by hand, and no accountant has to catch it for you.