Run our numbers against us.

The claims table.

Every sentence our marketing makes is a row here, checked against production. A claim that can't survive its query doesn't ship. Current: 14 TRUE · 2 PARTIAL · 2 UNDERSTATED · 1 FALSE · 1 TRUE-NARROW · 1 WITHDRAWN — launch is defined as FALSE = 0, and yes, we publish the FALSE ones. The 21–22 Aug movements, each on production evidence, none on a promise: C1 flipped TRUE when the dashboard shipped an honest coverage model and a screenshot showed it computing "3 of 6 active projects checked"; C2 flipped TRUE when the empty project registry was seeded with six real rows and an authenticated read returned them; C6 flipped TRUE when a real sign-out shipped and one click collapsed 47 accumulated sessions to 1 with audit rows written. C4, C17 and C18 were WITHDRAWN as surface rulings — the sentences they judged no longer render on any production surface (the audit page lives only on a never-merged branch; the marketing route was blanked and its receipt line deleted) — each with a stated reopen condition, because a claim with no surface can be neither true nor false in public. And C12 moved the honest wrong way: TRUE → FALSE, because the same dashboard rebalance that fixed C1 moved the live security score to 77/100 while our claim row still pins "74/100" — the number went stale the moment the product got better, and the row says so until it is re-scoped. One moved on 18 Aug: our own serving check was convicted FALSE by our own crash test that morning (D127, D128) and re-earned TRUE-NARROW that night, when the rebuilt check caught the still-broken canary at 23:01 UTC — see C13 and D131. It was narrow because 3 of our 5 enrolled projects recorded "cannot verify" (their deployment URLs sit behind login). On 19 Aug an authenticated bypass — sent only on the gated side, never on the public one — brought lendingfinancialgroup.com.au and medisential.com inside hourly coverage, and on 20 Aug the fifth project (no public surface at all) came inside through a bypass used on both sides of its comparison: 5 of 5 covered, D130 CLOSED. The same window added and closed D139: the check’s own fetch layer froze on a day-old view and published four false greens about unbounces; we caught it from its own recorded premises, published it while it was still failing, and the no-store fix was proven by two clean production passes on 20 Aug — the frozen streak ended at exactly 21 rows, at exactly the fix deploy.

The corrections ledger — 31 published here, verbatim.

Every time our own analysis was wrong, what we claimed, and why it was wrong — root cause included, never deleted. A discrepancy we are publishing rather than quietly closing: 31 corrections are printed below, and the register now holds 38. The two sets overlap but are not nested — this page carries edited prose for entries the register records differently, and the register carries later entries this page has never shown. We could have made the number agree in one line by regenerating this ledger from the register; that would have removed published corrections from a page whose promise is that none are ever removed. Reconciling the two corpora is recorded as D183 and is being done by hand. Three of these correct the same finding three times; the sequence is preserved because it teaches more than the conclusion.

The first deliberation on the record.

On 22 Aug the deliberation engine ran for real for the first time: two frontier models from two providers — claude-sonnet-4-5-20250929 and gpt-4o-mini — answered one synthetic lending question with a written client cap, blind, then saw each other, then revised, under a run-once governed action. It took three attempts, and the first two are kept: attempt one died on an invalid key and two retired model ids and left its empty header row in place; attempt two produced real rounds but lost its third panellist and was refused by its own hard rule — a panel missing a requested participant does not get to call itself a deliberation. Both failed records stay in the database, unedited, next to the one that succeeded.

What held, in the record itself: every blind verdict carries a commit timestamp earlier than its exposure timestamp; the panel genuinely split — one model committed at 98, saw its peer, lowered to 95 and held its dissent; the other adopted its peer's arithmetic wholesale and rose to 100 — and when we then tried to rewrite a committed blind verdict, the database refused us with "blind_response is write-once and cannot change once committed", and an immediate re-read returned the original values. That refusal is application-scope, at that moment, through that path — the scope section below says exactly what it does not prove.

What failed — and an external reviewer said it first. We sent the full record, failures included, to an external model prompted to refute it. It independently reproduced our withheld grading key to the cent and proved the record's adopted final answer carries wrong arithmetic: one plan's repayment overstated by $10.46 a month, the other understated by $120.07, the lifetime-cost gap wrong by roughly $36,000. The recommendation itself — the only plan under the client's written cap — survives on the reviewer's own numbers; the figures do not. It also ruled the ordering and independence claims unproven beyond what the stored rows show, which our scope statement had already admitted. So this record is cited here as evidence of process, never of arithmetic, and only together with its refutation — and the next engine change is the reviewer's own best suggestion: a deterministic calculation gate that refuses to finalise any deliberation whose figures fail reconciliation.

Record delib-20139274-6ffb-4649-969c-8132ac7b4d69 · verified 22 Aug 2026 11:25 UTC by the named owner with the governing action reference · register refs D142–D148 (the near-misses, the logging gaps, the refutation — all filed the same day).

What our guarantees bind — and what they don't yet.

Our evidence labels.