Verify evidence without Stratl

Every claim in these docs rests on this page. If Stratl could not be checked by an outsider, its records would be one more log. So the verifier is free, it runs on your machine, it needs no account and it makes no network calls, and it reports each check on its own so a partial failure looks like exactly that.

Two ways to run it

In the browser. Open the portal’s Verify page. Fetch a bundle from the workspace by decision id, or drop a bundle zip from anywhere onto the page. The same verifier code that ships as a command-line tool runs inside your browser; the bundle never leaves your machine.

On the command line. Install stratl (a single binary built from the backend repository’s cli/ folder) and run it against a bundle zip, an unzipped bundle folder, or a bare record:

stratl verify DEC-01J8ZK3Q9W7X2P4M6N8R0T1V3Y.stratl.zip

The output lists each check with PASS or FAIL, and the command’s exit status is zero only when every check that could run passed.

The twelve checks

Check	What it proves	If it fails
Record parses (SRF 0.1)	The file is a well-formed decision record	The bundle is corrupt or not a Stratl bundle
Record hash matches (RFC 8785 + SHA-256)	The record’s content is exactly what was hashed when it was written	The record was edited after signing
Public key present	The bundle carries the key needed to check the signature	An incomplete bundle
Key id matches the RFC 7638 thumbprint	The key in the bundle is the key the record names	Someone substituted a key
Signature valid (ES256 over canonical bytes)	The holder of that key produced this record	Forged or altered record
Chain link present	The record has a position and a link to its predecessor	A record outside any stream
Manifest file hashes match	Every file in the bundle is the file the manifest describes	A file in the bundle was changed
Checkpoint parses	The checkpoint statement is well-formed	Corrupt checkpoint
Checkpoint signature valid	The custodian signed the checkpoint	Forged checkpoint
Record included in checkpoint root (RFC 6962)	This record was in the set the checkpoint sealed	The record was added after the fact
RFC 3161 timestamp imprint matches	An outside authority dated this exact checkpoint	No independent time, or a mismatched token
Artifacts match their fingerprints	Each original in the bundle is the content the record refers to	An original was swapped

A check that cannot run is reported as skipped, never as passed. A bundle exported before its checkpoint existed will show the checkpoint checks skipped; export it again after the next checkpoint (hourly, or sooner from the Custody page) to include them.

What verification does not prove

It proves integrity and provenance: this record, signed by this key, complete in this chain, existing by this time, referring to this content. It does not prove the decision was right, the policy was lawful, or the approver was competent. Those are judgements; the verifier gives them something solid to stand on.

Verifying a subject pack or a period pack

Both carry manifest.json and manifest.sig.json. Recompute each file’s fingerprint against the manifest, then verify the signature with keys/public.jwk using any ES256 implementation. A subject pack also contains one bundle per record, each verifiable with stratl verify as above. Evidence outputs in detail.

Public keys without an account

Every bundle carries the public key it needs. Independently of any bundle, GET /v1/keys/{key_id} on the Stratl API returns any key by id with no authentication, and records may name that URL in custody.key_id_url. A verifier therefore never has to trust the Stratl API: it can fetch the key from it, or from the bundle, or from the customer’s own bucket, and compare.