What the snapshot contains
The unsigned private export has five fixed files: evidence-pack.json for normalized assets, confidence, risk, coverage and separately labeled manual planning; observations.json for retained public-source endpoint evidence and scanner versions; history.json for bounded recent audit, drift and verification records; manifest.json for the capture boundary and exact total/included/omitted counts; and SHA256SUMS for exact-byte hashes. The separate signed format adds signature.json and a versioned signed manifest without changing the captured evidence payload.
The database is read using one read-only repeatable-read transaction, so its queries see a stable committed view. This is a consistency property, not proof that source declarations are true. The export rejects workspaces above 500 normalized assets or 5000 retained source records; it may include only the latest 1000 public observation records and explicitly counts omissions. PostgreSQL explains repeatable-read snapshots.
Check exact bytes offline
Download the unsigned archive and its standalone Python verifier. Run python3 verify-discovery-snapshot.py cipher-discovery-snapshot-unsigned.zip on a trusted computer. It reads the ZIP without extracting files or using the network, rejects unexpected entries, and compares each member with its SHA-256 in the manifest and checksum file. RFC 6234 specifies SHA-256.
A successful result says INTEGRITY_MATCH_UNSIGNED. An altered payload or manifest fails the check. An attacker who can replace both the archive and its sums can produce a different archive that also passes. Do not use this result as a digital signature, trusted timestamp, compliance certificate or evidence of organizational quantum safety.
Check a producer signature against your own trust pin
The signed export uses Ed25519 over the exact manifest bytes; the manifest binds the other files by SHA-256. Download the standalone Go verifier and public-key registry, then obtain the registry SHA-256 digest through a separately trusted channel. Run go run verify-signed-snapshot.go -archive cipher-discovery-snapshot-signed.zip -registry snapshot-trust-v1.json -registry-sha256 PIN_FROM_INDEPENDENT_CHANNEL with Go 1.26 or newer. A key embedded in the ZIP or a registry downloaded from this same website does not establish trust by itself. The verifier rejects a revoked key and does not call a retired key trusted without an independent timestamp.
SIGNATURE_VALID_TRUSTED_KEY means the bytes match a signature under a key in the independently pinned, active registry. It does not prove that observations are correct, the scan covered everything, the server clock was accurate or the signer was uncompromised. Ed25519 is classical and is not a post-quantum signature. RFC 8032 describes Ed25519; NIST FIPS 204 defines ML-DSA, which is not used for this archive.
What still requires investigation
A public TLS scan inspects only the hostname and service explicitly selected. Imported CBOM entries and browser-local repository metadata are source declarations, not independent observations of deployment. Manual owners, deadlines and ticket links are not scanner findings. Unknown and unscanned cryptography remains unknown; there is no complete-coverage claim or published detector accuracy figure without a measured, versioned fixture corpus.
Read more about inventory boundaries, source evidence and migration verification, or open the private workspace.