H33 / Session / Public Verifier
One receipt verifies the meeting. Tamper it — REJECT.
Drag any H33 Session .h33pqv.json file below. We’ll check the canonical hash and verify all three post-quantum signature families (ML-DSA-87, SLH-DSA-256s, FALCON). PERMIT or REJECT in two seconds.
Or drop a .h33pqv.json file. Or paste it here:
Drag-and-drop runs entirely in your browser; verification runs on H33’s public demo verifier (Phase A backend at auth.h33.ai). The artifact contents are not stored.
What this means
Receipt narrative
Cryptographic verification details
Why "no login, no account"
If verifying a receipt required an account at H33, the receipt’s independence would be a lie. The verifier is public so the artifact can be checked by buyers, auditors, regulators, and adversaries on equal footing.
Why three signature families
The canonical trust model is a 3-of-3 AND-gate: ML-DSA-87, SLH-DSA-256s, and FALCON must all validate. Three independent post-quantum hardness assumptions (lattice, hash-based, NTRU-lattice) mean a forgery would have to defeat all three at once. The threshold the demo verifier actually applied is shown in the threshold chip above — a lower threshold is a Phase-A demo setting, not the security guarantee, because accepting after any family fails would be a false grant.
Why drag-and-drop matters
This is the proof: any single byte changed after signing is caught by the canonical hash AND rejected by every signature family. Try the tampered sample to see it.
Where this sits: independent Verification
This page is a consumer of Verification — it independently renders the verdict on an H33 Session receipt it did not produce, reproducing the canonical hash and validating the post-quantum signatures. It consumes an artifact; it does not produce the evidence (that is H33-74), does not monitor the estate over time (that is HATS), does not score maturity (that is HICS), and does not govern the decision (that is Agent-008). A VERIFIED verdict means the receipt reproduces and its signatures validate — not that the meeting was secure, correct, or compliant.
FAQ
What does a passing verdict mean — and what does it NOT mean? VERIFIED means the receipt is authentic and unmodified: the canonical hash reproduces and the signatures validate. It does not mean the session was secure, the decision correct or fair, or anything compliant.
Is the verifier independent of H33? The receipt is designed to be checked with no login, no account, and no sales call. This public page posts the artifact to H33’s Phase-A demo verifier at auth.h33.ai; the receipt itself is independent and can also be checked by the offline Portability Verifier with H33 absent.
How is Verification different from HATS, HICS, and Agent-008? Verification renders an independent verdict on an artifact that already exists. HATS records and monitors operational evidence over time; HICS scores maturity; Agent-008 governs the decision. This page only reproduces and validates.
Is the VERIFIED result hardcoded? No. The verdict is computed by the verifier from the artifact you supply — the canonical hash is recomputed and each signature family is checked. Use “Tamper one byte & re-verify” above: any change flips the verdict to REJECTED.
How many signature families must validate? The canonical model is a 3-of-3 AND-gate — ML-DSA-87, SLH-DSA-256s, and FALCON must all validate. The threshold the demo verifier applied is shown in the threshold chip; a lower threshold is a Phase-A demo setting, not the security guarantee, since accepting after a family fails would be a false grant.