EN

DOSSIER DE PREUVE · GOLDEN-PATH-001

Ce qu’un examinateur peut vérifier sans nous.

Une règle de paiement, six demandes, chaque décision scellée. Cette page est construite à partir du dossier lui-même : les verdicts, les approbations et les limites ci-dessous sont lus dans les fichiers téléchargeables, pas écrits à la main.

Construit depuis le commit moteur 8823029. Données d’exemple : comptes fictifs, clés générées pour cette construction.

LA RÈGLE

Une règle, écrite comme l’écrirait une équipe de conformité.

“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

Cité tel que livré dans le dossier (en anglais).

Approuvée par 2 clés désignées sur 2, chacune en double signature (Ed25519 + ML-DSA-65) sur les octets exacts de la politique et du compilateur qui la lit.

  • treasury-controller29851b207b85110f…
  • risk-officerfc7e2730563914cd…

Une signature lie une clé, jamais une étiquette. Les rôles sont déclarés : rapprochez-les de votre propre registre de clés.

SIX DEMANDES, TROIS ISSUES

Autorisé, bloqué ou refusé. Jamais deviné.

Chaque demande a été décidée avant d’atteindre l’outil de paiement, et chaque décision est une entrée du dossier scellé.

  • PROCEEDS’exécute. Aucune règle n’est enfreinte.
  • BLOCKArrêtée. Une règle est enfreinte, et le dossier dit laquelle.
  • REFUSENon décidée. La barrière n’a pas pu évaluer une règle avec ce qu’on lui a fourni : elle décline au lieu de deviner.
  • pay-okPROCEED
    Montant
    250 000 $ CA
    Deuxième signature
    non
    Changements de bénéficiaire dans la fenêtre
    2 envoyés · 2 déclarés

    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
    Montant
    9 000 000 $ CA
    Deuxième signature
    oui
    Changements de bénéficiaire dans la fenêtre
    2 envoyés · 2 déclarés

    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
    Montant
    9 000 000 $ CA
    Deuxième signature
    non
    Changements de bénéficiaire dans la fenêtre
    2 envoyés · 2 déclarés

    blocked — payment above CAD 5,000,000 without a second signature

  • ben-4thBLOCK
    Montant
    100 $ CA
    Deuxième signature
    non
    Changements de bénéficiaire dans la fenêtre
    4 envoyés · 4 déclarés

    blocked — more than 3 beneficiary changes in the declared window

  • ben-unaccountedREFUSE
    Montant
    100 $ CA
    Deuxième signature
    non
    Changements de bénéficiaire dans la fenêtre
    4 envoyés · population non déclarée

    not decided — 1 rule(s) could not be evaluated: more than 3 beneficiary changes in the declared window

  • ben-unreconciledREFUSE
    Montant
    100 $ CA
    Deuxième signature
    non
    Changements de bénéficiaire dans la fenêtre
    4 envoyés · 3 déclarés, ne concorde pas

    not decided — 1 rule(s) could not be evaluated: more than 3 beneficiary changes in the declared window

Ont atteint l’outil de paiement : pay-ok, pay-big-signed. Les autres demandes ont été arrêtées avant. Une exception levée après le départ de l’argent n’est qu’une ligne de journal.

CE QUE LE SOLVEUR A DIT DE LA RÈGLE

La première réponse est celle à lire.

Quatre questions sur la même règle, quatre réponses différentes. Rejouer une décision ne dit rien de l’ensemble des actions qu’une règle admet ; ces questions, si.

  1. can ANY approved payment exceed the ceiling?

    Z3, whole numeric range

    REFUTED

    La règle n’a jamais imposé de plafond absolu, seulement un plafond conditionnel à la deuxième signature : un paiement signé de n’importe quel montant passe.

  2. ...without a second signature?

    Z3, whole numeric range

    PROVEN

    Sans deuxième signature, aucun paiement unique au-dessus du plafond ne peut être approuvé, sur tous les montants et non sur un échantillon.

  3. ...over a sequence of 200 payments?

    Z3, bounded at 200

    STRUCTURING

    Fractionnée en paiements qui restent chacun sous le plafond, une séquence déplace plus que le plafond sans enfreindre la règle une seule fois. Telle qu’écrite, la règle ne plafonne pas un total.

  4. ...the count over a rolling window?

    the compiler declines to quantify it

    NOT EXERCISED

    Le compte sur fenêtre glissante ne peut pas être quantifié par le compilateur : cette clause est décidée demande par demande, jamais prouvée.

Ces quatre réponses viennent du solveur au moment de la construction et figurent dans le README du dossier. Elles ne sont pas sous le sceau : dans le dossier scellé, chaque règle est traitée comme evaluated-bound, une évaluation de chaque demande, pas un théorème.

VÉRIFIEZ LE SCEAU, ICI

Chargez le dossier. Puis chargez le faux.

La copie falsifiée change un seul champ : elle prétend que le paiement bloqué de 9 000 000 $ CA portait une deuxième signature, la seule retouche qui ferait paraître le blocage injustifié. Rien d’autre ne bouge. Regardez le vérificateur nommer l’entrée seq=3.

Ce dossier ne porte aucun ancrage temporel : il prouve que les octets n’ont pas bougé depuis le scellement, pas quand ils ont été écrits.

IRONPROOF · VÉRIFICATEUR DE SCEAUPRÊT

Tourne entièrement dans votre navigateur — Ed25519 + ML-DSA-65 (FIPS 204) + SHA3-512 en JavaScript pur, sans serveur et sans code Ironproof. Le format est publié, donc n’importe qui peut écrire un second vérificateur : lire la spécification →

TROIS CONTRÔLES, AUCUN COMPTE IRONPROOF

Tout ce que nous avons conclu, re-dérivé sans notre code.

  1. 1

    Le dossier a-t-il bougé depuis sa construction ?

    Chaque fichier haché dans MANIFEST.sha3. Cela attrape l’accident, pas un adversaire, qui pourrait le régénérer.

    Dans le dossier

  2. 2

    Le dossier scellé a-t-il bougé depuis son scellement ?

    Signatures Ed25519 et ML-DSA-65 sur une chaîne SHA3-512, les deux devant passer. C’est le contrôle qu’un adversaire ne peut pas falsifier.

    Sur cette page

  3. 3

    Chaque verdict découle-t-il de ses propres entrées scellées ?

    Une seconde implémentation, écrite à partir de la spécification publiée des verdicts et non de notre code, re-dérive chaque décision.

    Dans le dossier

Le dossier exécute les trois avec Node 24 et rien d’autre : ni Python, ni réseau, ni paquet Ironproof.

LES CHOIX FAITS POUR LE CLIENT

La règle était en prose. Ces choix sont les nôtres.

Chacun change un verdict, et aucun n’appartient au client. Ils sont livrés dans le dossier : un désaccord se voit au lieu de dormir dans un 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

Cité tel que livré dans le dossier (en anglais).

CE QUE CE DOSSIER N’ÉTABLIT PAS

À lire avant de citer quoi que ce soit ci-dessus.

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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.

Cité tel que livré dans le dossier (en anglais).

Lire LIMITS.md en entier →

FICHIERS DE CETTE PAGE

verify.sh, MANIFEST.sha3, la spécification des verdicts et le second vérificateur sont dans le dossier complet, remis dans le cadre d’un pilote. La spécification du sceau est publique. SPEC_CANON.md

Le même dossier, pour une de vos règles.

Un pilote commence par un type d’action et se termine par ceci : un dossier scellé que votre comité de risque vérifie sans nous.

DÉMARRER UN PILOTEVÉRIFIER UN DOSSIER