ARBITER / Adaptive Risk Evidence

Retraining alone breaks
the audit trail.

We trained real models on a 30,000-customer credit dataset, retrained them on accumulating data the way a bank does, and recalibrated cutoffs to hold a target decline rate. The 7,500 decisions of the first cohort are attested, then replayed. Then we asked what an auditor would conclude by re-running the current model to reconstruct an earlier decision. The population never changed. The answer still moved.

Fig. 00 — Replication on real lending data

The effect scales with drift, and never disappears

15.5%
95% CI 14.7% – 16.3% · n = 7,500

of reconstructions report an outcome that was never the one taken — with the population held completely constant.

Same customers, same distribution, more training data. The only thing that changed is the model improving, from AUC 0.773 to 0.786. That alone was sufficient.

RegimeAUC v1 → v3Reconstruction accuracyMisreported
Real data — retraining only0.773 → 0.78684.5%15.5%
Real data — with population drift0.651 → 0.75778.7%21.3%
Simulated — high drift0.699 → 0.84874.6%25.4%
With pinned receipts100%0%

The error has a direction. Under population drift, 1,438 of 1,596 disagreements read stricter today than the customer was actually treated — manufacturing the appearance of a decision the bank never made.

Fig. 01 — The companion simulated study

%

of reconstructions report an outcome that was never the one taken.

Measured over attested decisions. The bank did nothing wrong: the model improved, the risk team recalibrated to hold its target decline rate, and the operating point moved underneath every historical decision.

Model AUC, v1 → v3, on an unseen quarter
Decline ↔ allow reversals, the maximally wrong case
Decline cutoff moved, v1 → v3
Receipts replaying exactly, all vintages

The improvement is the cause, not a coincidence. A better model scores the same applicant differently, and a recalibrated cutoff sits somewhere new. The more diligently a risk team maintains its model, the less able the institution becomes to explain any single decision it already made.

Fig. 02 — Four real cases from that run

Same applicants. Same facts. Different answers.

Drawn from the measured decisions above: the first instance of each transition type. Scores are the models' actual outputs.

DecisionThen — score / cutoffDecidedToday — score / cutoffReported

Model at decision:  ·  today:

Fig. 03 — The evidence

Each decision re-derives from its own receipt

Three independent checks per receipt, all running locally in this page: the Ed25519 signature over the verdict, the SHA-256 receipt hash re-derived from the pinned inputs, and the hash-chain link to the previous receipt. There are no network calls on this page.

Fig. 04 — What this is

An evidence layer, not another model

  • Runs read-only beside the risk pipeline. It never declines, blocks, or freezes, and is never the decision-of-record.
  • Attestation plus a durable write-once commit costs 0.519 ms at p99, fsync included.
  • Write-once is enforced by the database engine: an UPDATE or DELETE against the receipts table aborts.
  • Retrospective query returns every decision for a customer and window in 0.099 ms, as a self-contained bundle that verifies offline.

What we do not claim

  • We do not run your model. Arbiter cannot compute what a retrained model would score today; you supply that. We hold the exact recovery of what was decided then.
  • Replay is bit-exact over pinned, exact-valued inputs. Re-deriving a score from raw inputs through a non-deterministic model is a different and unsolved problem.
  • No production deployment, customers, or revenue. The engine is working, tested software: 438 tests, including property-based tests, cross-implementation parity, and fault injection showing lending continues if attestation fails.

Fig. 05 — Selective disclosure

Prove one decision out of 100,000. Reveal nothing else.

A supervisor asks about one customer. Handing over a chain means handing over the neighbours — disclosing other customers to answer a question about one. Instead, every receipt is committed to a Merkle root that can be published outside the bank; an inclusion proof then shows a single decision belongs to that committed set, using only log₂(n) sibling hashes.

Decisions in the anchored set
Size of the full store
Disclosed to prove one of them
Fraction of the store revealed
Anchored root
Anchored at
Position
Audit path
Receipt signatureEd25519
Inclusion in anchored set

The audit path is 17 hashes. Nothing in this bundle names, or is derived from, any other customer — which is what lets a bank answer a supervisor under data-minimisation obligations. The root is small enough to anchor outside the bank, so the commitment survives even loss of the store itself.