Documents

Every document, in the order a review reads them.

The protocol and its limits first, then building on it, running it, procurement, and what comes next. Each page is the published text, rendered; the exact markdown sits beside it with its sha256, so what you read is what you can hash.

50 documents5 groupsabout 4 hours in all

1 of 5

The protocol and its limits

What Mirror computes, what it will never do, and where it is blind.

  1. The Mirror Protocol — v1 draftStatus: draft for review. Audience: a bank's cryptography team, its data-protection officer, and its counsel. What this document is for: so those three people can decide…38 min read
  2. The Cannot ListMirror's moat is not what it can see. It is what it is built to be structurally incapable of doing — and every one of those refusals is enforced by a test you can run.5 min read
  3. The Boundary RegisterA living, versioned account of what Mirror cannot do. Most vendors hide their limits behind marketing; publishing them is the stronger position, because it makes the…24 min read
  4. The Typology MapWhich trade-based money-laundering typologies Mirror addresses, by what mechanism, and — stated with the same weight — which it is blind to. A tool that claims to catch…6 min read
  5. Duplicate financing: the fraud one bank cannot seeA borrower takes one bill of lading, one invoice or one warehouse receipt to two lenders and draws against it twice. Each lender's file is complete and clean. The fraud…5 min read
  6. Threat Model & Architecture BriefFor a security or legal team evaluating Mirror. This is the document to hand a reviewer who asks "what could go wrong, and what would an attacker actually get?" It…5 min read
  7. Threat-model review historyThe threat model is SPEC §2.1 (what must remain impossible), with the mathematical triage in MATH.md and the boundary register.2 min read
  8. Mirror — protocol stability policyVersion 1.0 · published 2026-09-28 · applies to protocol mirror/1 (the spec pin carried on /health and in every record).4 min read
  9. The RFC processChanges to the protocol are proposed, published and decided in the open.1 min read

2 of 5

Building on it

The interfaces a bank's engineers integrate against, the on-ramps from tools a bank already runs, and the standard a corridor table follows.

  1. Integration Map: Mirror as connective tissueStatus: architecture note for partners and evaluators. Mirror is a layer, not a silo. It does one thing no tool in a bank's trade stack can do alone — reconcile a trade…3 min read
  2. Connecting a bank's systemsMirror's integration points sit inside the bank, where the data is. None of them sends a raw value anywhere.4 min read
  3. Already running document AI? Feed it straight inMany trade-finance banks already run a document-AI tool that reads invoices, bills of lading and customs declarations and extracts their fields, each with the tool's own…5 min read
  4. API, SDK and SIEM export/openapi.json is OpenAPI 3.1 and is generated, never hand-maintained.4 min read
  5. Mirror for AI agentsBanks are starting to give AI agents work: gathering evidence for a case, checking a trade before an officer looks at it, keeping a file in order. sdk/mirror-mcp.js…3 min read
  6. Webhooks: signed pushes, and exactly what is guaranteedWhen a verdict is signed on a shipment where your leg authenticated, the operator pushes it to your endpoint. When a witness your clears rested on is suspended, you get…2 min read
  7. TerraformThere are two ways, both shipped as source: a module (terraform/, with examples/bank-a) that needs nothing but Terraform and Node, and a compiled provider…2 min read
  8. The production-parity sandboxThe hosted demonstration relaxes things on purpose so a visitor can drive it. An integration built against it would meet production's refusals on the first day of a…1 min read
  9. The Corridor Table StandardStatus: PROPOSED · v0.1 DRAFT · not yet ratified by any standards body. This document is published for comment and as the basis for submission to a trade-finance…5 min read
  10. A corridor's life: from no table to a renewed oneA corridor is two banks, one product on one route, one agreed band table and one shared secret. This page walks the whole life of one, in order, and names the code…9 min read
  11. Ratio corridors: a table nobody has to negotiateA corridor used to start with two banks agreeing a list of price edges for one product, ratifying it, and renegotiating it whenever the market moved. A risk committee…3 min read
  12. Federation: a verdict co-signed by independent operatorsA Mirror verdict used to carry the authority of one operator's key. "Why should I trust that operator?" had one honest answer: you do not have to, if several independent…3 min read
  13. Scaling: what one operator does today, what it costs, and how it would shardMirror has no load numbers for the hosted operator, and this page does not invent any. It states what was measured, on one machine, with the tool that measured it, and…3 min read

3 of 5

Running it

Keys, access, recovery and failure, for the team that operates a member's side - or the whole operator, inside its own perimeter.

  1. Custody: the keys stay in your HSMMirror never needs a key in a file.4 min read
  2. Rotating a corridor secretTwo banks share one corridor secret. Every salt either of them derives comes from it, so a rotation is the one key operation they must do together. Mirror makes it a…3 min read
  3. Access control: keys, scopes and SSOA caller proves possession of a ratified member key (/auth/challenge, then /auth/session) and gets a session of at most an hour. Membership is re-checked on every…2 min read
  4. Running the bander highly availableThe bander has no state that matters between runs: it reads a file, derives salts, bands, commits, signs and writes a batch. That makes high availability simple, and it…2 min read
  5. Running the operator air-gappedA bank, a group of banks or a supervisor can run the Mirror operator entirely inside its own perimeter: no cloud account, no database service, no outbound network. State…5 min read
  6. Clock disciplineThe design keeps every safety property off the wall clock. Verdicts do not depend on it; key rotation does not depend on it. What remains are freshness windows, where a…2 min read
  7. Degradation runbookEach failure, what Mirror does by itself, and what you do. The rule behind every row: Mirror degrades toward not clearing and toward telling you, never toward a silent…2 min read
  8. Recovery time and recovery pointserver/recovery-drill.test.js proves that the verdict log rebuilds from the members' copies alone to the same root, with every copy verified before re-admission, so a…2 min read
  9. Transparency-log operations policyThe verdict log is shaped like Certificate Transparency: every signed verdict is a leaf, and the operator signs tree heads. This policy says who runs it, what it…2 min read
  10. Major-incident reporting supportWhen a financial entity classifies an ICT-related incident as major under DORA, it reports in three stages against hard deadlines, and its ICT third-party providers are…2 min read

4 of 5

Procurement and compliance

The evidence a vendor review, a data-protection officer and counsel ask for.

  1. Due diligence: the 61 gatesEvery gate a bank's procurement asks about, assessed against what is actually in the code and on the operator on 2026-09-29. Done names the file, route or test that…9 min read
  2. The model-risk pack: nothing learned, everything re-runnableBefore 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…5 min read
  3. Release provenance and reproducible builds/provenance.intoto.json is an in-toto Statement v1 with an SLSA provenance v1 predicate, in a DSSE envelope.4 min read
  4. How Mirror is built: the secure development practice, as it actually isThis statement describes what is done today, including where it falls short. It is not a certification. A bank should read it next to the threat-model review history and…2 min read
  5. FIPS 140: Mirror's positionMirror ships no FIPS 140-validated cryptographic module and claims no validation. This page says which algorithms Mirror uses, which module performs them in each place…2 min read
  6. Data residencyThe operator processes and stores everything it receives in the EU, and says so in a signed record you can check. What it receives is commitments, signatures and…2 min read
  7. Sub-processorsEvery third party that processes anything for the Mirror operator or this site, what it processes, and where. Changes are published here at least 30 days before a new…2 min read
  8. Data protection impact assessment: the parts Mirror can pre-fillA DPIA is the controller's. This page pre-fills the facts about Mirror that a bank's DPO would otherwise have to extract. Each fact is marked as either enforced in code…3 min read
  9. Retention schedule, and how erasure is resolvedDraft for counsel. The periods below are Mirror's proposed defaults for what the operator holds. Each member bank's own record-keeping obligations govern what it keeps…2 min read
  10. Contract schedules: draft clauses for counselStatus: drafts for a bank's counsel. No bank has agreed these terms. They are written so each promise matches what the product actually does, and each clause names the…3 min read
  11. Mirror under the EU AML package and FATF Recommendation 16: a position paper for counselStatus: a position for a bank's counsel to test, not legal advice. Every legal reference below is "as we read it". Confirm it against the current text.3 min read
  12. Where Mirror sits in a financial-crime programmeA generic map to the usual parts of an AML/CFT programme. A bank maps it onto its own programme; that per-bank mapping is the bank's work. This page says, for each part…2 min read
  13. For a supervisor: one hand-over document/cannot (signed at GET /cannot) lists 39 refusals. Each names the code that enforces it and the test that pins it. None can be removed or weakened within a major version…2 min read