IMMO.QUICK · PUBLIC EVIDENCE VERIFIER
One record. A clear view of the evidence.
Examine signature, issuer, action and prerequisites separately. See what the evidence establishes and what remains open.
Your input stays in your browser. The verifier does not transmit or store it.
This public verifier examines existing evidence. Institutional issuance, signing, integrations and protected execution are outside the free offering. You can still download the JSON result report.
Request institutional accessEVIDENCE AND CONTEXT
What would you like to verify?
Distinguishes portable Serverless™ P-256 proofs, legacy hybrid receipts, HMAC receipts, Core™ CIPP envelopes, Core™ screening receipts, GG0 CDS™ receipts and Negative Assurance™ material exports. Not every recognised format is fully verifiable.
Set expected action, trust material and reference time
For CDS™, supply full texts as {"source_texts":{"raw_input":"…","screened_text":"…"}}. Text is not automatically transformed. Negative Assurance™: load the stored export containing run and material as the main file. Everything stays local.
Only explicitly supplied fields are compared. Without an expected action, the verifier cannot confirm that the evidence matches your transaction.
For canonical P-256 proofs: a keys list with issuer, public_key_hex (SPKI) and optional key_id/status. For portable signed_payload signatures: public JWK/JWKS or a keys list with issuer and jwk. Establish provenance yourself. Never enter an HMAC secret or private key.
The report states the reference time. It is not independent time assurance. A historical evaluation time does not establish current state.
Try examples and compare
The first five examples are synthetic and use a separate test key. They demonstrate the verifier, not actual system execution. Two further examples are existing published receipts from the Evidence Library.
What this version can verify
Canonical portable P-256 proofs: recompute the signed field hash, verify the signature, compare the issuer to supplied trust material, and compare the validity window and expected action. Portable signed_payload blocks: verify the exact signed text; outer fields remain unverified.
Legacy hybrid receipts: verify Ed25519 and the binding of the signature values. ML-DSA and full content canonicalisation remain open here. HMAC: no public authenticity verification. Core™ CIPP: examine a recognised legacy envelope checksum without confirming full nested content binding, Core™ signatures or assurance. No TEE or enclave attestation verification.
No live revocation, execution permission, independent establishment of actual effect, or legal advice. A report_digest does not prevent complete recomputation by a third party and is not a signature of the report.
Core™ test-mode receipts and GG0 CDS™ receipts: recompute supported checksums. Matching checksums establish mathematical consistency, not publicly authenticated origin. Excerpts do not replace full source texts. Execution is outside the scope of these screening receipts.
Additional consistency checks cover supported versions, required references, key status and key validity windows, real calendar dates and bound execution timestamps. CDS™: finding, coverage and segmentation counts plus supplied full texts. Negative Assurance™: leaf hashes, event and class roots, snapshot and profile bindings, neighbour paths, counterevents and declared coverage. CertifiedReceipt and TZero exports: linkage within the supplied chain segment. These checks do not replace original capture evidence or public signatures.
Verification runs in isolation with a 15-second deadline. An interruption or technical failure produces no confirmation. The complete JSON report retains individual checks; repetitive checks are grouped for readability.
Verifier · Request institutional access