Every clearance decision MURAQIB makes is sealed into a tamper-evident record. Each entry is cryptographically linked to the one before it, and the sequence is periodically countersigned with a key held offline — outside the production environment entirely.
This page publishes the public half of that key, and the tool anyone can use to check the record for themselves. No account. No installation. No need to trust us.
Published here, on a domain OQIRON controls, deliberately separate from any evidence file we send you. A key that travels inside the file it validates proves only that whoever built the file held the matching private key — not who they were. Obtaining it from here instead is what makes the check meaningful.
The verifier is a single file of standard Python. It reads no network, touches no database, and imports nothing beyond the language itself — so it runs on a locked-down machine where installing software is not permitted.
Download muraqib_verify.py from the public repository. It is open source under the MIT licence — read it, modify it, or write your own from the published specification.
OQIRON, or the institution being examined, supplies the bundle: a single self-describing file containing the sealed record and its countersignatures.
Supplying the key yourself is the stronger form of the check. The tool will tell you which form you used.
Requires Python 3.8 or later, which ships with macOS and most Linux systems. The tool exits with a distinct code for each outcome, so it can be run unattended as part of an audit pipeline.
A verification tool that hides its own boundaries is not a verification tool. These are the limits of what this one can establish.
Whoever assembles a bundle may withhold the contents of any entry, supplying only its fingerprint. The verifier cannot distinguish an entry withheld for confidentiality from one withheld because its contents are unfavourable.
What withholding does not permit is substitution. The fingerprint published for a withheld entry is a binding commitment to its original contents. A different version cannot later be produced that matches it — so if the true entry ever surfaces, from a subpoena, a counterparty, or another copy, any substitution becomes evident. The recipient of a bundle should decide independently which entries must be disclosed in full, and treat every withheld entry as unexamined.
Records are countersigned in batches, so the most recent entries are normally linked but not yet signed. That is the ordinary state of a record still being added to, and the verifier reports the count plainly rather than treating it as a fault.
Removing the most recent countersignature from a bundle would enlarge that unsigned portion. The verifier raises a prominent warning when it exceeds a tenth of the record — but a recipient should confirm the date of the latest countersignature from a source other than the bundle itself.
This is a record-integrity tool. It establishes that a sequence of decisions existed in a particular order at the moment it was signed, and has not been altered since. Whether each decision was correct is a separate question, answered by examining the decisions themselves — which is what full disclosure of an entry is for.
The verifier and the full bundle specification are published so that a third party can reimplement the check independently. A verifier nobody is permitted to inspect is a verifier nobody should rely on.