A MARSAD evidence pack carries its own proof. This page publishes the proof format and the reference verifier, so an examiner, an auditor, or a sceptical bank can re-check any pack with no MARSAD software, no licence, and for the integrity layers, no key of any kind.
When a MARSAD deployment exports an audit dossier, the zip contains the human-readable sections (PDF), the machine-readable sidecars (JSON), a proof.json covering every hash chain in the platform, a signed manifest, and a copy of the verifier itself. Everything MARSAD asserts about the integrity of that pack can be recomputed by a third party.
That is the design goal: the bank should never have to say "trust the vendor". The examiner holds the pack, the proof and the tool, and the arithmetic either works or it doesn't.
Layers 1 and 2 are the point. A regulator with nothing but a Python interpreter recomputes MARSAD's tamper-evidence independently. Layer 3 adds "who signed it"; layer 4 adds "and that key really is the bank's".
The verifier is one file, and it needs only the Python standard library for layers 1 and 2. Layer 3's Ed25519 check uses the cryptography package when it is available.
# any machine with Python 3.10+, no install required $ python3 verify_dossier.py dossier.zip ok 00-cover.pdf ok 00-cover.json ... one line per file in the pack ... ok proof.json ok chain re-walk: 605 row(s) across 14 chain(s) recompute from genesis ok Ed25519 manifest signature (key_id=marsad-deployment-ed25519) OK -- 35 file(s) + chain re-walk + signature verified
To pin the signing key to a source you obtained out of band:
$ python3 verify_dossier.py dossier.zip --expected-key <hex> $ python3 verify_dossier.py dossier.zip --keys-url https://<bank>/v1/proof/public-keys
Exit code 0 means every check passed. Exit code 1 means at least one failed, and the output names it.
You don't strictly need either download: every dossier embeds its own copy of the verifier as verify-dossier.py, and the proof file is self-describing. They are published here so you can inspect the tool before you trust its verdict, and so anyone can implement an independent verifier from the specification. Both are plain text; read them before you run them.
A passing verification proves the pack you hold is exactly what was sealed, in the order it was sealed, and that nothing in the recorded history was rewritten afterwards. It also proves, via the signature, who sealed it.
It does not prove the recorded assessments were correct. Whether a control really is compliant remains the examiner's judgement. What the proof removes is the possibility that the record moved under their feet.
The format is an open specification. The hash recipe, the canonical encoding, the linkage rules and the signature scheme are all in the spec, and version fields let an implementation refuse a format it doesn't understand. If you build one and find an ambiguity in the spec, we want to hear about it: hello@marsadcomply.com.