[Invariants]
Data Reliability Suite
Invariants that cross the legacy DB, the mirror, the RPCs, the lake and the rendered UI — each one born from a real incident.
Every layer looked fine on its own. The bugs lived between layers: a mirror that drifted, an RPC that filtered differently, a card that rounded.
Built the suite as a runnable skill for the coding agent and kept a family of invariants per dashboard.
A check that compares a copy with itself stays green forever — and one critical reconciliation check did exactly that while a cost line was double the source.
01 · Families per dashboard
Numbered invariants per dashboard (L1–L13 for leads, I1–I13 for affiliates), each with its query and tolerance.
02 · Three layers per number
The value, the perimeter (which rows) and the copy (mirror vs source). Tolerances are measured, not inherited.
03 · External oracles
Where possible a check compares with something outside the system — like the analyst's manual monthly ROI method.
04 · Red before green
A new invariant has to fail on the bug it guards against before it's accepted.
05 · UI in the loop
A headless browser reads the rendered card and compares it with the RPC.
! brokeA critical check compared the mirror with the mirror and stayed green while the call-center line was twice the source.
→ changedChecks now compare against an independent copy (mirror vs source DB) with a measured tolerance.
! brokeA check judged the current open month, which diverges by construction, and blocked valid rebuilds.
→ changedOnly closed months are judged.