EVIDENCE PACK · GOLDEN-PATH-001

What an examiner can check without us.

One payment control, six requests, every decision sealed. This page is built from the pack itself: the verdicts, approvals and limits below are read from the files you can download, not written by hand.

Built from engine commit 8823029. Sample data: fictional accounts, keys minted for this build.

THE CONTROL

One rule, as a policy team would write it.

“No single payment above CAD 5,000,000 may leave without a second signature, and no account may have more than 3 beneficiary changes in a rolling 12-month window.”

C1payment above CAD 5,000,000 without a second signature
C2more than 3 beneficiary changes in the declared window

Quoted as shipped in the pack.

Approved by 2 of 2 designated keys, each dual-signed (Ed25519 + ML-DSA-65) over the exact bytes of the policy and of the compiler that reads it.

treasury-controller29851b207b85110f…
risk-officerfc7e2730563914cd…

A signature binds a key, never a label. The roles are declared; resolve them against your own key registry.

SIX REQUESTS, THREE OUTCOMES

Allowed, blocked, or refused. Never guessed.

Each request was decided before it reached the payment tool, and each decision is an entry in the sealed record.

PROCEEDRuns. No rule is broken.
BLOCKStopped. A rule is broken, and the record names which.
REFUSENot decided. The gate could not evaluate a rule on what it was given, so it declines instead of guessing.

pay-okPROCEED
Amount
CAD 250,000
Second signature
no
Beneficiary changes in window
2 sent · 2 declared
compliant — this action breaks none of the 2 constraints. Scope: this action alone, every attribute bound. NOT a claim that the policy admits no violation.
pay-big-signedPROCEED
Amount
CAD 9,000,000
Second signature
yes
Beneficiary changes in window
2 sent · 2 declared
compliant — this action breaks none of the 2 constraints. Scope: this action alone, every attribute bound. NOT a claim that the policy admits no violation.
pay-big-unsignedBLOCK
Amount
CAD 9,000,000
Second signature
no
Beneficiary changes in window
2 sent · 2 declared
blocked — payment above CAD 5,000,000 without a second signature
ben-4thBLOCK
Amount
CAD 100
Second signature
no
Beneficiary changes in window
4 sent · 4 declared
blocked — more than 3 beneficiary changes in the declared window
ben-unaccountedREFUSE
Amount
CAD 100
Second signature
no
Beneficiary changes in window
4 sent · population not declared
not decided — 1 rule(s) could not be evaluated: more than 3 beneficiary changes in the declared window
ben-unreconciledREFUSE
Amount
CAD 100
Second signature
no
Beneficiary changes in window
4 sent · 3 declared, does not tie out
not decided — 1 rule(s) could not be evaluated: more than 3 beneficiary changes in the declared window

Reached the payment tool: pay-ok, pay-big-signed. The other requests were stopped before it. An exception raised after the money moved is a log entry.

WHAT THE SOLVER SAID ABOUT THE RULE

The first answer is the one to read.

Four questions about the same rule, four different answers. Replaying a decision says nothing about the set of actions a rule admits; these questions do.

can ANY approved payment exceed the ceiling?
Z3, whole numeric range
REFUTED
The rule never imposed an absolute ceiling, only one conditional on the second signature: a signed payment of any size passes.
...without a second signature?
Z3, whole numeric range
PROVEN
Without a second signature, no single payment above the ceiling can be approved, over every amount rather than a sample.
...over a sequence of 200 payments?
Z3, bounded at 200
STRUCTURING
Split into payments that each stay under the ceiling, a sequence moves more than the ceiling without breaking the rule once. As written, the rule does not cap a total.
...the count over a rolling window?
the compiler declines to quantify it
NOT EXERCISED
The rolling-window count cannot be quantified by the compiler, so that clause is decided request by request and never proved.

These four answers come from the solver at build time and are listed in the pack’s README. They are not inside the seal: in the sealed record, each rule is discharged as evaluated-bound, an evaluation of each request, not a theorem.

CHECK THE SEAL, HERE

Load the record. Then load the forgery.

The forged copy changes one field: it claims the blocked CAD 9,000,000 payment carried a second signature, the one edit that would make the block look wrong. Nothing else moves. Watch the verifier name entry seq=3.

This record carries no time anchor, so it proves the bytes have not moved since sealing, not when they were written.

IRONPROOF · SEAL VERIFIERREADY

SEALED DOSSIER

Runs entirely in your browser — pure-JavaScript Ed25519 + ML-DSA-65 (FIPS 204) + SHA3-512, no server and no Ironproof code. The wire format is published, so anyone can write a second verifier: read the spec →

THREE CHECKS, NO IRONPROOF ACCOUNT

Everything we concluded, re-derived without our code.

1
Has the pack moved since it was built?
Every file hashed in MANIFEST.sha3. This catches accident, not an adversary, who could regenerate it.
In the pack
2
Has the sealed record moved since it was sealed?
Ed25519 and ML-DSA-65 signatures over a SHA3-512 chain, both of which must pass. This is the check an adversary cannot forge.
On this page
3
Does each verdict follow from its own sealed inputs?
A second implementation, written from the published verdict specification rather than from our code, re-derives every decision.
In the pack

The pack runs all three with Node 24 and nothing else: no Python, no network, no Ironproof package.

DECISIONS WE MADE ON YOUR BEHALF

The rule was prose. These choices are ours.

Every one of them changes a verdict, and none of them is the customer’s. They ship in the pack, so a disagreement is visible instead of buried in a commit.

'above 5,000,000' -- inclusive or exclusive?
WE DECIDEDEXCLUSIVE: 5,000,000.00 exactly passes without a second signature
a one-word reading. lab/bank_policy found the same seam in a real policy: 'exceeding 10,000' and '$10,000 or more' differ by one payment
the window: which rows are in it?
WE DECIDEDthe CALLER declares the population; the gate RECONCILES and refuses when it does not tie out
we do not derive the window and we never will -- it lives in a system we do not read. An unaccounted aggregate REFUSES rather than decides
'3 changes' -- does a reversal count? a spelling fix?
WE DECIDEDevery row tagged kind=beneficiary_change counts, reversals included
the narrower readings need a field nobody sends us
12 months from when -- the request, or settlement?
WE DECIDEDthe window is whatever the caller declares; we do not compute dates
same seam as row 2. The clock is theirs

Quoted as shipped in the pack.

WHAT THIS DOES NOT ESTABLISH

Read this before quoting anything above.

1
The manifest proves integrity against accident, not against an adversary.
Anyone who can edit a file in this pack can regenerate MANIFEST.sha3. What it catches is transport damage and a file edited by someone who forgot the manifest. The SEAL inside dossier.json is the part an adversary cannot forge -- check 2 and check 3 in verify.sh are the ones that carry weight.
2
unsat is bounded by the domain it was proved over.
The ceiling result holds for the flags and ranges declared in the trace inside the dossier, and says nothing outside them.
3
The sequence result is bounded at k.
It settles sequences of exactly that many actions. A ceiling that survives k and falls at k+1 is a normal shape, not a pathology. Run the k you intend to claim.
4
The window clause is DECIDED, never proved.
The rolling-window count is evaluated against a population the caller declares. We reconcile that population -- ids, and the keys the rule filters on -- and REFUSE when it does not tie out. We do not derive the window, and we never will: it lives in a system we do not read.
5
A valid approval proves that N authorised KEYS signed those bytes.
It does not prove a human read them, and approver_id is a declared label the signature does not certify.
6
The gate stops a caller, not hostile code in the same process.
Code already running there could call the tool directly -- but it could equally open a socket, so the gate was never the constraint in that scenario. This is not sandbox-grade isolation and must not be sold as such.
7
The encoding is our reading of the rule.
Two readers encode one sentence two ways, and no solver decides between them. The decisions we made on the customer's behalf are listed in the control's own output; that list is part of the deliverable, not a footnote.
8
The seal proves the document has not moved since it was sealed.
It does not prove the document was true when it was written.
9
Rebuilding this pack does NOT reproduce it byte for byte, and that is by design.
Each build stamps collected_at and mints FRESH approver keys, so dossier.json, README.md and therefore MANIFEST.sha3 differ between two builds of the SAME commit -- 48 fields move, in cascade, from those two sources. Measured on 2026-09-20 by building the same commit twice. So: verify the pack you were given against itself (./verify.sh, which recomputes every digest from the bytes next to it). Do NOT compare your manifest to ours and read a difference as tampering -- it is not evidence of anything. What a rebuild reproduces is the VERDICT and the reasoning, never the bytes. A reviewer who compares the wrong thing gets a red that accuses us of forgery, and a seal would only lend that accusation authority.

Quoted as shipped in the pack.

Read LIMITS.md in full →

FILES ON THIS PAGE

verify.sh, MANIFEST.sha3, the verdict specification and the second verifier ship in the full pack, handed over in a pilot. The seal specification is public. SPEC_CANON.md

The same pack, for one of your controls.

A pilot starts with one action type and ends with this: a sealed record your risk committee checks without us.

START A PILOT VERIFY ANY DOSSIER