The Clear File · what an examiner receives

The file an examiner opens with the network unplugged.

A Clear File is the examiner pack as one HTML document: the signed verdicts, the signed registry they were judged under, the openings that show which price table was used, and the operator's own verification code, inlined. Open it offline and every signature is re-checked on the examiner's machine. This worked example holds one clear and one flag, signed on the spot by a demonstration key - not the live operator's.

2 verdicts1 clear1 flag4 published keys0 network calls

What is inside

Two shipments, three banks' signatures on each, one verdict apiece.

Both shipments are hs8541 solar inverters, judged under the same ratified table. On the first, the invoice, customs and payment legs land in one price band. On the second, the invoice prices the crate in a different band from the other two.

SHIP-1001 · hs8541 solar inverterscleared

Reconciled

All 3 legs committed consistent band labels under the agreed corridor. Cleared on the committed labels - this record is the defensible reason; that each label is the band of its true value is checked at audit, by opening.

customsinvoicepayment3 of 3 legs signed by their bank
SHIP-1002 · hs8541 solar invertersnot cleared

Divergent

2 leg pair(s) price into inconsistent bands - a possible mispricing. Route to review before any clearing or payment.

customs ↔ invoiceinvoice ↔ payment
customsinvoicepayment3 of 3 legs signed by their bank

Why it is evidence

Every claim in the file carries its own proof.

Who signed the verdicts

The operator's key mir-7a9558abb08621d2, one of 4 keys the pack publishes. A verdict whose kid is not published is not evidence of anything.

Who signed the inputs

Each leg is signed by the bank that produced it, and the verifier re-runs the join over those signed legs rather than believing the operator's label: invoice mir-19bcc713de6f3baa, customs mir-688d9d9477df1e65, payment mir-f52346a55b42ceae.

The table it was judged under

A signed registry snapshot: quorum 2 of 2 members, 1 corridor ratified. The openings prove each verdict's corridor commitment is that table - and nothing else.

How to verify it

Five steps, and none of them calls us.

The file does all five on open. The JSON lets an examiner do them with their own tools, years later.

  1. Open the accompanying .html file in any browser, offline. It re-checks every signature below on your machine.
  2. Or check it yourself: each verdict is ES256 (ECDSA P-256) over the record as canonical JSON - the same JSON with every object's keys sorted alphabetically.
  3. Match each proof.kid to a key in operator_jwks. A verdict whose kid is not published here is not evidence of anything.
  4. An opening proves the verdict's opaque corridor_commitment equals sha256(salt + '|c|' + 'c:' + sha256(sorted_edges_joined_by_commas)). That is how you confirm which price table a trade was judged under.
  5. Nothing here calls Mirror. If any step needed our servers, this would be a claim rather than evidence.

What it does not prove

A record of what was decided - not a verdict on the trade.

A Mirror examiner pack. It proves what was decided, by which key, and under which agreed price table - it does not prove the underlying trade data was true, which remains the reporting institutions' responsibility. Verdicts are structural signals reconciled from salted commitments; NOT a zero-knowledge proof and NOT secure multiparty computation. A divergence is a reason to look, never proof of laundering; a clear is a defensible record, never a guarantee of innocence.

The example was generated by node server/pack.js --demo-assets site on 2026-10-06, with a fresh demonstration key; the generator refuses to build a pack that is not one clear and one flag. · /clear-file-example.json sha256 42ace0f3fa57c913…