Before a bank runs an analytics tool in production, its model-risk function asks whether the tool is a model and, if it is, how it was validated and how it will be monitored. For a tool whose answers come from a trained model, that review is usually the longest step. The parameters were learned from data the bank cannot re-run, the behaviour is known by sampling it, and the outputs can change when the vendor ships a new version.
Mirror's answers come from a deterministic rule with no learned parameters, and every answer is signed and can be re-checked by anyone, offline. This page lists the evidence a validator asks for, the command that reproduces each piece, and what the pack does not cover.
Whether Mirror is a "model" is your model-risk function's decision, not ours. SR 11-7 in the United States and the PRA's SS1/23 in the United Kingdom leave classification to the bank's own policy. The pack is built so that either answer is cheap to support: as a tool, with the evidence below; or as a model, with the same evidence used for validation.
The validator's questions, and where each answer is#
| Question | Evidence | Re-run it yourself |
|---|---|---|
| What are the parameters, and where did they come from? | The parameter inventory in the validation dossier: every threshold and constant, classed as party-supplied (the corridor tables), policy (tunable, with its default) or structural (fixed by the mechanism). The learned parameters are counted over that list, not typed in: zero. | curl -s -X POST https://mirror-operator.vasileburuian94.workers.dev/dossier -H "Content-Type: application/json" -d "{}" |
| What was it trained on? | Nothing. The dossier counts training-data sources over the same inventory: zero. | The same call |
| Can you reproduce a decision from two years ago, exactly? | The dossier runs the real kernel on the same inputs repeatedly and compares the outputs byte for byte. Every verdict is signed, and /verify re-runs the reconciliation over the signed inputs and requires the same answer. | POST /verify with the record; or offline with the kit's verifier |
| Show me the whole behaviour, not a demo. | The dossier enumerates the decision table for the corridor: every combination of bands across the required legs, plus the structural rows (a missing leg, an unbandable leg, two tables). The verdict-rule certificate checks the kernel against the three-state rule in every one of 48,384 configurations, with 0 counterexamples. That is bounded model checking, not a proof, and the certificate says so. | /verdict-certificate.json; node server/pin-verdict-rule.js re-runs it |
| Is the code that ran the code that was reviewed? | Signed release provenance (in-toto and SLSA v1, in a DSSE envelope), and a rebuild that compares ten artefacts with what was signed, reproduced on Windows and on Ubuntu. | node server/reproduce.js; results in provenance |
| Is the test suite the whole suite, or a chosen subset? | /conformance-suite.json pins the sha256 of every test file the runner executes. | node kernel/test.js |
| Would another implementation give the same answers? | Conformance vectors reproduced by an implementation written from the specification text alone, and SDK vectors held by five SDKs. | node conformance/reference-impl.test.js |
| What can it never do? | The signed refusal list: no score, no ranking, no filing decision, no raw value at the operator, no custody of money. Each refusal names the code and the test that enforce it, and the list is change-controlled. | GET /cannot; the cannot list |
| How does it do against known answers? | A synthetic corridor with planted anomalies, including anomalies Mirror cannot see by design (mispricing inside one band, the same false number on both sides). The report counts what was caught and what was missed against the full planted set, not only the part Mirror can express. | POST /autopsy |
| Where is it blind? | The boundary register, and the signed geometry certificate of each ratified table: the widest mispricing a reconciled reading can still hide under it. | GET /corridor/certificate?product=..&version=.. |
Monitoring when nothing is learned#
Ongoing monitoring of a trained model watches its inputs and outputs for drift, because the model's behaviour can move. Mirror's rule cannot move between releases: the verdict-rule certificate is pinned to the kernel's sha256, and a new kernel means a new release with new provenance. What does age is the corridor table the two banks ratified, as the market moves away from it. That is monitored directly:
- Drift.
POST /corridor/drift(member route) measures, from the operator's own signed verdicts, how a ratified table's readings are shifting over time. Counts, never a value. - End dates. A table ratified with
valid_untilstops judging on that date; renewal is a new version, ratified again (a corridor's life). - Undetermined readings, by reason. A rising share of one reason (a missing leg, a different table, no independent witness) is the operational signal, and each reading carries its reason.
Against a learned model, task by task#
This is not a claim that AI tools are unsafe: a learned model can be validated, and banks do it every day. It is a statement of how the work differs.
| Validation task | For a learned model | For Mirror |
|---|---|---|
| Conceptual soundness | Review the features, the training data and its labels, the algorithm and its fit | Read one rule: the three-state rule, and the band arithmetic, exact decimal with no floating point |
| Outcomes analysis | Back-test against labelled history, with sampling error | Enumerate the decision table, and run the planted-anomaly corridor with its full denominator |
| Ongoing monitoring | Input and output drift, re-training triggers, performance decay | The table's drift and its end date; the rule itself does not change between releases |
| Change management | Re-validate after re-training or a vendor model update | A new kernel changes its sha256, its certificate and its provenance; nothing changes silently |
| Vendor transparency | Often limited by the vendor's intellectual property | Specification, source, vectors and suite are published, and every answer verifies offline |
What the pack does not cover#
- It is not a validation sign-off. Only your own independent validation function can validate. This is evidence for that work.
- It does not show that a corridor table is right. Wrong tables give wrong bands, and nothing in the mechanism can tell a wrong price table from a right one. The tables are the two banks' judgement, ratified and versioned.
- It makes no claim about detection rates on real laundering. The planted-anomaly corridor is synthetic, and the counts it reports are about that corridor alone.
- No independent reviewer has been engaged. The review brief names seven claims and what would falsify each.
- No supervisor has reviewed this page. The framework names say what shape the evidence takes; they imply no endorsement.