Cross-Ledger Exchange

Reconciliation with a counterparty ran through Excel: they exported a file, we parsed it. Both bugs we found were in the channel, not the reconciliation logic. A tax ID stored as a number lost its leading zero — 8 of 129 counterparties dropped out of the reconciliation silently. A number format containing a non-breaking space turned every amount above a thousand into zero. Each time we fixed the specific instance while the class of failure stayed put.

We replaced the channel instead of patching instances. A read-only processor runs inside the counterparty's database and emits structured JSON against a published schema; our receiver checks it against our ledger and produces an Excel report with a class and reason for every discrepancy.

The contract was frozen before the first line of production code: JSON Schema, a three-layer validator (structure, decimal precision, total arithmetic), and a set of negative fixtures following one rule — one file, one class of breakage. A side benefit: the exporter emits object identifiers rather than names, so matching no longer depends on both databases spelling a counterparty identically.

The contract is covered by automated tests and went through a two-track code review by two independent AI engines. The tracks surfaced different holes, and both hit the same target — silent pass-through: a trailing newline in a tax ID counted as valid, and duplicate JSON keys bypassed the schema version check. Both classes were closed before the contract went live.