Conformance

Frozen vectors that two verifiers must agree on

Independent verifiability is only real if more than one implementation can check a record and reach the same answer. Provenrail freezes a public suite of conformance vectors, and two separate verifiers, the Python pr verify CLI and the in-browser JavaScript verifier, must produce the recorded verdict on every one. If they ever drifted apart, the test suite fails.

11 frozen vectors 2 independent implementations Python + JavaScript in lockstep Open source under MIT

The suite

Each vector is a fixed bundle with a recorded expectation. A conforming verifier must agree on the verdict, and should surface the defining finding code that explains it.

VectorVerdictWhat it provesDefining code
cleanVerifiesAn untampered, anchored run. Verifies clean.none (clean pass)
tamper_payloadRejectedA record payload edited after signing. The record hash no longer matches.client_hash_mismatch
delete_recordRejectedA record removed mid-stream. The server receipt chain breaks.server_chain_break
reorderRejectedTwo records swapped. Arrival order no longer matches emission order.arrival_reorder
bad_signatureRejectedA record signature corrupted. The device-key signature fails.client_bad_signature
strip_anchorVerifiesValid records with no external anchor. Weaker, but not tampered.no_anchor
tlog_witnessedVerifiesA transparency-log inclusion proof cosigned by an independent witness.tlog_inclusion_witnessed_ok
scitt_validVerifiesA SCITT COSE receipt that verifies against the transparency-service key.scitt_receipt_ok
scitt_forgedRejectedA SCITT receipt whose COSE signature was altered. Hard fail.scitt_receipt_invalid
redacted_disclosedVerifiesA redactable field disclosed with valid openings. Commitments recompute.redaction_summary
redacted_forgedRejectedA redactable field with a forged opening. The commitment does not match.redaction_disclosure_invalid

Why this is the bar

Anyone can claim their records are verifiable. The honest test is whether a second, independent implementation reaches the same conclusion. These vectors cover the full chain: client signatures, the server receipt chain, arrival ordering, external anchors, the witnessed transparency log, SCITT COSE receipts, and verifiable redaction. Both the shipped verifiers run all of them on every change.

Frozen on purpose. The vectors are locked. A change in verification behavior, in either implementation, is caught immediately rather than slipping out quietly. That is what keeps a record verified today still verifiable tomorrow.

Verify it yourself

You do not have to take the table's word for it. Run the verifier against a live record in your browser at provenrail.com/verify, watch it reject a tampered one, or install the CLI and run pr verify locally. The SDKs, the verifier, and the spec are open source under MIT.

← Back to security