// verify
Verify a record.
Without trusting me.
Every instrument produces a record in the same envelope, and every record ships with a way to check it that does not involve me. Distrust is the intended first response. The material below is what you need to act on it.
// § 01 · the common envelope
One envelope. Instrument-specific payloads.
A Gate record and a Model Evidence record answer different questions, so forcing both through one flat schema would mean a field set that is mostly empty and mostly meaningless. Instead the envelope carries what is true of every result, and the instrument payload carries the rest.
env
arcifact-report/1
Instrument and version, profile, subject, source bindings by digest, the claims and their verdicts, the declared envelope with what was out of scope, assumptions marked verified or not, provenance, issue and expiry, revocation, signature and seal.
01
gate-ci/1
The gate and how it aggregates, its enforcement status, covered jobs, uncovered jobs with gap type and severity, exact ordering counts where enumerable, a counterexample and the remediation.
02
model-evidence/1
Banks with digests and item counts, the fabrication rate, stance decomposition, the thresholds registered before the run, and whether strict scoring was used.
A verifier that does not recognise an instrument still validates the envelope and says plainly that it did not interpret the payload, rather than passing it silently.
// § 02 · check it
Four verdicts, deliberately distinct.
The distinction that matters most is between a record being self-consistent and a record being authentic. Most of the value is in refusing to collapse them.
A
VALID
Issued profile. Every check passed, including a signature verified against a key you obtained out of band, an expiry that has not passed and a revocation pointer.
B
SELF_CONSISTENT_REPORT
Internally consistent and bound to the sources you supplied. This is not a claim of authenticity or issuance, and the verifier says so on the same line.
C
INCOMPLETE
Nothing contradicts the record, but a check could not be performed here. It names which one, so you can decide whether it matters.
D
INVALID
A check failed. It names which. Editing a payload, re-sealing it, pointing it at different bytes or claiming a profile the record does not meet all land here.
// § 03 · trust material
Everything you need to check me, in one place.
Issuer public keys are published here and must be taken from here or another channel you trust, never from inside a record. A key carried by the document it signs proves nothing. The revocation ledger is signed and carries its own next-update time, so a stale ledger is detectable rather than silently trusted.
// § 04 · the commitment log
What was fixed before the run.
A sealed record proves it has not been altered. It cannot show that a threshold was set before the run, or that a held-out bank existed before evaluation. Those are properties of the process, not of a document. Saying otherwise would be the kind of unearned claim this whole site argues against.
So there is an append-only log. Each entry commits to a fact before the thing it constrains happens, and carries the hash of the entry before it. Edit any past entry, recompute its hash, remove one, or append after signing, and the chain or the signature breaks. The verifier below detects all four.
A
It begins when it begins
The log proves nothing about anything before its first entry. No past result is strengthened by it, and no claim on this site says otherwise.
B
The clock is not mine to trust
A timestamp inside the log is my assertion. What makes it hard to backdate is that each head hash is committed to a public git repository, and GitHub records when it received that push. That receipt is not mine to set.
C
Check it without me
Run the verifier for the chain and the signature, then date any head against the RFC 3161 timestamp tokens over it. Two independent authorities sign that the head existed at a stated time, and both verify offline from the token files. No Arcifact key is involved: the signatures are the authorities' own, and nothing about the check depends on a hosting provider or on a timestamp Arcifact could choose.
// § 05 · published records
Model Evidence runs are published with their manifests and bank digests on the evidence page. Gate findings are disclosed privately to the repository owner and are published only with their written approval, so the absence of public Gate records here is deliberate rather than an oversight.
Proof, in one place.
The sample
package · sixteen files, a real record, a self-contained
verifier
The public analyser ·
any public repository, no installation, no account
The same analysis as
SARIF · the format your security tooling already imports
Our own SBOM · what the analyser is made of,
derived from what runs rather than from a pin file
Nine undocumented GitHub Actions behaviours · each verified, with receipts
The same register, machine readable · re-runs its assertions when you request it
Certificates · how a record is bound
to a commit and a key
arcifact-kit
· the verifiers, public, so checking us needs nothing of ours
Every one of those can be run without asking us and without trusting us. That is the point of the list: a claim you have to take on faith is not proof, whatever it is labelled.
These come from Gate.
Everything on this page is about checking a record you already have. The thing that produces one is Arcifact Gate: it reads a repository's declared workflow and reports what a green required check actually establishes, with a counterexample where one exists.
Any public repository, no installation, no account.