The practitioner is a program, and it is allowed to refuse.

Three outcomes, not twoCLEAN means the control was tested and held. EXCEPTION means it was tested and did not. DISCLAIMER means there was not enough evidence to conclude — and it is never rolled up as a pass. A procedure that can only produce good news is marketing, so refusing to conclude is a first-class result.

Three corrections we made to ourselves. The cross-chain reconciliation has been wrong three times, and the wrongness was instructive each time. (i) It asserted availableFunds + escrowedFunds ≤ totalAvailable across two contracts and reported a 400 UBA exception against Flare — figures never defined to relate; the 400 UBA is a fee the asset manager nets off, now disclosed as C5 rather than judged. (ii) It asserted escrowedFunds = totalAvailable − immediatelyAvailable, which held exactly and could never fail, because both sides derive from one storage slot (§ 3.3). (iii) It asserted availableFunds + escrowedFunds ≤ Balance and produced a 497,844,875,522 drop shortfall — caught before publication: XRPL escrow removes XRP from the account balance and holds it in Escrow objects, so adding Flare's escrowed figure to a balance that already excludes it double-counts every escrow.

C3 now reconciles the two things that genuinely must agree — Flare's escrowedFunds against the sum of the vault's Escrow objects on XRPL, which on live data match to the drop — and C4 compares Flare's spendable claim against the liquid balance after the ledger's own reserve. A false accusation is far more damaging to an assurance register than a missed finding.

Every correction this project has ever made is published in full, including the ones that reached the public before being withdrawn. [ Read the errata → ]

The false accusation we measuredRead both chains once, and an honest agent looks insolvent. An agent pays a redemption on the XRP Ledger first; Flare's underlyingBalanceUBA only falls once that payment is confirmed back on Flare. Inside that window the agent appears short by exactly the payment in flight.

t1  flare 408,410.89 | xrpl 394,344.37 | diff −14,066.52   <- false shortfall
t2  flare 393,423.10 | xrpl 394,344.37 | diff   +921.27   <- truth, 45s later

Flare fell by 14,987.784 XRP between those readings — matching, to the drop, the payment this agent had already made at XRP Ledger 106,099,993. That equality is what makes it settlement lag rather than a coincidence, and it is why a shortfall here is never published from a single observation.

Why this section existsAn earlier version of C3 asserted escrowedFunds = totalAvailable − immediatelyAvailable. It held exactly, every period. It also could not fail: coreVaultAvailableAmount() derives both of its outputs from that same escrowedFunds, so this very fault injection moved both sides of the identity together and the control stayed green. It had been printing CLEAN for reasons having nothing to do with the vault's health.

Four controls do not move under this fault. That matters as much as the one that does — a check that fires on everything is no more informative than one that fires on nothing.

Reproduce it: pnpm --filter @therecord/procedure redrun. The script exits non-zero if C3 stays CLEAN, so a control that stops being able to fail breaks the build.