Each card below downloads a real .h33pqv.json attack artifact.
Drop any of them into the verifier on the right and watch the H33 substrate
produce a structured REJECTED outcome with a named reason — in your
browser, with no H33 infrastructure in the loop.
Drop-test verification is a supporting expression of Verification, the discipline that renders the independent verdict. Verification is the act of re-checking an artifact offline — trusting no one — and returning valid or invalid. Each artifact here is designed to be re-checked; the REJECTED outcome you get back is a negative verdict rendered on that artifact, with a named, re-checkable reason.
Why this exists: a rejection is only trustworthy if you can reproduce it yourself. So the substrate does not merely block attacks — it renders a verdict any reviewer can re-derive. Verification does not produce the artifact (that is H33-74), does not record or monitor it (HATS), does not govern the decision (Agent-008), and does not score maturity (HICS).
When to use this: use it when you need to independently confirm — without trusting H33 — that the substrate re-derives a REJECTED verdict on a forged, replayed, stolen-key, revoked-authority, mutated-scope, or tampered-registry artifact, so you can reproduce the rejection yourself against the auditor's registry snapshot.
Run this attack on any card. OR click Download and drop the file into the verifier on the right.qsign-nap-verify --registry <jsonl> on a workstation with the substrate crates installed.Attacker mints a JSON that looks like a real verification receipt from Compliance Desk Zeta, but cannot produce real triple-family signatures.
Signatures verify — the bytes are genuine. But the receipt cites a stale registry tip from last quarter; the auditor's replica has moved on.
phishy-verifier-phi reported the compromise and posted a Revoked record. The attacker keeps issuing receipts under the leaked key after that timestamp.
rogue-bank-rho's registration was Revoked at 2026-05-23. Issuing a new artifact under that principal after that timestamp does not restore authority.
Operator alters the policy text after a denial to claim the threshold was $2M, not $500K, all along. The signed committed_scope_hash no longer matches.
Attacker intercepts a registry replica in transit and inserts a record granting themselves Active issuer status. The hash chain breaks at the splice.
This is a drop-test layer. The artifacts are real .h33pqv.json files
with the structure the substrate produces; the rejections you see in the verifier
panel are the same structured reasons the production Rust verifier emits. But
not every check that runs in a production audit pipeline runs in your browser.
Here's exactly what is and isn't live:
| Check | In-browser | Production verifier | Notes |
|---|---|---|---|
| Schema parse + URN validation | LIVE | LIVE | Same JSON, same URN grammar (qsign-fed-id) |
| Registry tip-hash freshness | LIVE | LIVE | String comparison against the snapshot's tip.last_record_hash |
| Principal status at timestamp | LIVE | LIVE | Same record_at() semantics, replayed in JS |
| Registry hash-chain integrity (prev_record_hash walk) | LIVE | LIVE | String comparison along the JSONL chain |
| Scope-envelope hash recomputation | LIVE | LIVE | Browser uses SHA-384 (WebCrypto); production uses SHA3-384. Both are 384-bit; structural detection is identical. |
| All-zero signature heuristic | LIVE | N/A | Production runs the real verify; this browser shortcut catches the obvious forge without crypto. |
| Triple-family PQ signature verification (ML-DSA-87 + SLH-DSA-256s + FALCON-1024, 3-of-3 — all must validate) | SIMULATED | LIVE | The full PQ verify needs the production crates. Pipe the same artifact through qsign-nap-verify --registry for the live check. |
| Canonical JCS encoding equivalence | SIMULATED | LIVE | The browser uses a stable key-sorted JSON; production uses serde_jcs (RFC 8785). Differences would only matter for unicode edge cases not present in these artifacts. |
Every artifact carries a _demo block that names exactly which check the in-browser
verifier runs and which check the production verifier runs. Read it inside the JSON to confirm.
An independent verdict on the artifact you drop in. It re-checks the artifact's structure, registry status, and hash-chain integrity offline in your browser and returns REJECTED (a negative verdict) with a named reason, or INCONCLUSIVE where the in-browser layer cannot decide. It does not trust H33 to tell you the answer — you re-derive it.
It means the artifact failed to reproduce and validate against the auditor's registry snapshot: a signature is forged, a key was revoked, a scope hash was mutated, or a registry chain broke. It does not mean the system that emitted it is secure, correct, or compliant, and a single rejection is not a claim that the substrate is unbreakable. It is one verdict on one artifact.
H33-74 produces the signed artifact; Verification renders the verdict on it. This drop-test page is a Verification surface — it consumes an artifact and re-checks it. It does not govern the underlying decision (Agent-008), record or monitor it (HATS), or score maturity (HICS).
Partly. The structural checks are live and identical; the full triple-family PQ signature verification and canonical JCS encoding are simulated in-browser and must be run through the production qsign-nap-verify for the complete verdict — see the “Simulated vs. live” table above. The in-browser layer is honest about which checks it renders.