Check a Checkii evidence bundle. No account, nothing uploaded.

Drop the three files from an issued report bundle (and its transparency-log entry, when you have it), one sealed export, or a sealed governed-OSINT transcript. Your browser checks the Ed25519 signature against the key Checkii publishes, then checks the exact bytes of the report and its findings snapshot, the sealed document, or the transcript's hash chain, against the signed digests. The files never leave your machine. This page makes one request beyond its own files, for the published key registry, and none at all when you pin a key yourself. It loads no web fonts and no third-party scripts.

The bundle

A sealed export

A Cyber Resilience Act readiness pack, a time-to-verified-fix export or a release receipt is one JSON file: the document and, beside it, a seal whose statement names the document's digest and the digests of every part, signed with the same report-signing key. A release receipt records what ran against a build and what it reported; it is not a certification, and the page does not call it one. Drop the whole file, or the seal object alone. The pin above applies here too.

A governed-OSINT transcript

When a job ran with OSINT authority, every lookup and fetch the worker relayed through the broker was recorded before the engine could use the answer, hash-chained, and sealed on acceptance as a DSSE envelope over an in-toto statement. Drop the job's transcript download (the envelope, the statement and the event rows) or the envelope alone. With the rows, the page recomputes the chain exactly as the platform did and must reach the sealed head; without them it shows the head for you to compare. A transcript key is published under its own purpose, and its identifier is the SHA-256 of its public key, so a pin for a transcript uses that digest as the identifier.

What a result means

Verified means: the issuance statement was signed by a key the registry (or your pin) trusts, and the report and snapshot you hold are byte for byte the ones that statement names. The bundle has not been altered since Checkii issued it.

It does not mean that the people named in the statement are who they say, that a scan ran, that findings are accurate or complete, or that a target is secure. Those are established by the engagement's retained execution evidence, not by this signature.

A bundle can be not verified for a dull reason: a text editor converted line endings, a mail client appended a newline, or a file was re-saved. Ask the issuer for the original export. The check is deliberately exact.

How it is checked

The page runs the same seven checks as the standalone verify.py: the bundle parses, with duplicate keys and non-integer numbers refused so the two verifiers can never disagree; the algorithm is Ed25519; the statement holds exactly the fourteen v1 fields, each of its expected type, with status ISSUED; the key is trusted; the signature verifies over the canonical statement; report.md and snapshot.json hash to the signed digests. The source is one file with no dependencies, and the test suite runs it against tampered copies of the published sample on every change.

For a sealed export the checks are: the file parses, with duplicate keys refused and non-integer numbers kept exactly as written; the statement is a schema this page knows, with lowercase SHA-256 digests throughout; the key is trusted; the signature verifies over the canonical statement; and, when the document travelled with the seal, it hashes to the signed digest. A seal verified without its document proves only that the statement was signed; the page shows the digest for you to compare against the document you hold.

For a governed-OSINT transcript the checks are: the file parses, with duplicate keys refused; the envelope is DSSE v1 with the in-toto payload type and one signature per key; the payload is the canonical in-toto statement for one scan attempt with the sixteen-field transcript predicate and consistent counts; when the download travelled with it, its statement, key identifier and public key agree with the envelope; the key is trusted for transcripts and hashes to the envelope's key identifier; the signature verifies over the DSSE pre-authentication encoding; and, when the event rows travelled with it, each row belongs to the sealed attempt and worker, hashes to its recorded digest, the chain reaches the sealed head and event-list digest, and the rows' lookup, fetch and refusal totals equal the predicate's. The subject digest names the accepted assessment result; the page shows it and does not fetch anything.

A transparency-log entry may travel with any of the three: transparency.json beside a bundle, or transparency beside a seal or a transcript. It is the record Checkii obtained from the public Sigstore Rekor log before releasing the statement. The page checks it without contacting anyone: the entry names the digest the page has already verified and carries a second signature over the same bytes by the signing key's published companion (an ECDSA P-256 key listed in the registry under transparency-signature with signs_for naming the signing key; the public log can verify a signature only over a digest, which a plain Ed25519 signature does not allow), which the page verifies; its leaf hash is the entry identifier; the inclusion proof reaches the checkpoint root; and the checkpoint is signed by the log key published in the registry under transparency-log, which must agree with the copy pinned in this page. A supplied entry that fails any of these fails the verdict. A missing entry never fails the signature checks; it is reported against the signing key's logged_from date, before which no entry is expected. After a verified entry you may ask the page to check the log online; that one request goes to the log, not to checkii.ai, and the page says so before it is sent.

Key registry: /.well-known/checkii-signing-keys.json. A key listed as current signs hosted reports from its published date; a retired key verifies only reports issued between its published and retired dates; a revoked key verifies nothing; the sample key verifies only the one demonstration bundle the registry binds it to; a key published for transcripts verifies transcripts only, and one published for reports never verifies a transcript; a key published as a transparency log signs checkpoints only; a key published as a transparency signature signs log entries only, for the one key its signs_for names. Corrections to info@checkii.ai.