Drop a receipt. Watch the substrate verify itself.
Each artifact below is a complete .h33pqv.json receipt demonstrating one substrate behavior — a PERMIT verdict with all three trust bindings held, a REJECT verdict with the failing binding cited. Download, inspect, or drop into the browser verifier to confirm the standard.
What these are. These are frozen reference receipts of the Q-Sign substrate — the authority substrate Agent-008 governs agents with. Unlike a live receipt from your own runtime, these are fixed exemplars anyone can re-verify offline. They are for confirming the spec and your implementation — not a claim about any live customer system.
Example receipts
Q-Sign PERMIT — staging test_run
example-permit-2026Q2-001.h33pqv.jsonA two-hop lineage from a human board principal through a deploy agent to a leaf test-runner agent. The leaf invokes a staging:test-read action against the auth-microservice. All three trust bindings hold: lineage path verified, instruction tag matches, HATS Permit emitted. The NAP record names Eric Beans as the root principal and renders the full descent to the leaf.
Q-Sign REJECT — scope-expansion attempt
example-reject-2026Q2-001.h33pqv.jsonSame two-hop lineage as the PERMIT example, but the leaf agent attempts a production:write action while only authorized for staging:test-read. The authority binding fails the scope-subset check (Q-Sign §5.2). The gate emits REJECT before the action runs; the receipt cites the failed binding and identifies the lineage edge that capped scope. Downstream bindings are not evaluated.
Verification instructions
- Click
Download .h33pqv.jsonon any artifact above. The file lands in your browser downloads with the same canonical bytes the substrate emitted. - Open the public verifier in a new tab. The verifier is a static page; nothing leaves your browser.
- Drag the downloaded
.h33pqv.jsononto the verifier's drop zone. The verifier is designed to parse the envelope, walk the lineage path, and check all three signature families (ML-DSA-87·SLH-DSA-256s·FALCON-1024) against the public Q-Keys referenced in the NAP record. H33 is designed to bind evidence using three independent post-quantum signature families: ML-DSA, FALCON and SLH-DSA. Full three-family production verification remains pending completion and independent qualification of the FALCON repair. - Watch the verdict render in approximately two seconds. PERMIT artifacts show three green checks (one per family) and a summary of the three trust bindings. REJECT artifacts show the failing binding in red and identify which lineage edge or instruction tag triggered the rejection.
- (Optional) Modify a single byte of the downloaded file with any text editor and re-drop. The verifier rejects under all three families — that is the substrate's tamper guarantee. See /h33-session/ for the canonical live-break demonstration.
Schema references
.h33pqv.json v1
The portable artifact format every Q-Sign envelope is wrapped in. Triple-family signatures, NAP record, trust-binding results.
View receipt spec ›BAAE format
Bound Authority Action Envelope — the structured object the substrate signs and the gate evaluates.
Whitepaper §7 ›Lineage DAG edge
The signed delegation edge connecting parent → child with scope, time bounds, and revocation handle.
Whitepaper §5 ›RFC 8785 JCS
Deterministic JSON canonicalization. All envelope hashing happens over the RFC 8785 canonical byte stream of the envelope minus the signatures block.
Whitepaper §8 ›Chaos + conformance outputs
H33-Chaos · Q-Sign suite
54 adversarial replay scenarios against the Q-Sign substrate — tamper, expire, mis-scope, repudiate, swap. Every scenario deterministically rejects.
Browse the chaos harness ›Conformance Suite
The vectors and harness an implementer must pass to claim Q-Sign conformance. Per-component positive and negative cases plus cross-component composition.
Conformance suite ›Agent conformance vectors v1
Agent-substrate conformance vectors covering the five Q-Sign components plus the BAAE envelope contract.
Open vector set ›Browser replay determinism test
In-browser harness that reproduces the deterministic replay of a recorded BAAE. Confirms canonical-byte equivalence across implementations.
Run the determinism test ›Frequently asked
What are the Q-Sign reference artifacts?
Frozen example .h33pqv.json receipts of the Q-Sign substrate — one PERMIT with all three trust bindings held and one REJECT citing the failed binding — plus schemas and chaos/conformance outputs an implementer verifies against.
How do they work?
Download a receipt and drop it into the public verifier: the verifier is designed to check all three post-quantum signature families (ML-DSA-87, SLH-DSA-256s, FALCON-1024) and replay the lineage chain deterministically. Tamper one byte and the verdict flips.
When should I use them?
When you are implementing or evaluating Q-Sign and need known-good and known-bad receipts to confirm your verifier behaves per spec, or when you want to see exactly what a PERMIT and a REJECT contain before wiring it into your own system.
What don’t they do?
They are fixed exemplars, not live evidence: they make no claim about any customer’s running system. They demonstrate the substrate; they do not govern an agent (Agent-008 governs) or render an independent verdict on your artifacts (the Verification layer does).
How is a reference artifact different from a live receipt?
A live receipt is emitted by a running gate for a real action at a real time. A reference artifact is a frozen, published example with the same structure, provided so anyone can re-verify the standard offline without access to a live system.