PQ-Verified Artifact v1 — one package, one verifier command, one outcome.
The customer-facing format for H33-PQ Verified. The pillars are for auditors. The artifact is for customers.
Why this exists
The PQ-Verified Artifact v1 is a single self-contained JSON file in which PQ-Verified recognizes and asserts that a subject conforms to the post-quantum requirements — carrying the artifact manifest, five inline pillar attestations, and triple-family PQ signatures over the manifest.
Customers don't ask for five separate bundles. They ask: "Give me the proof package." This artifact is that package. One drag-and-drop. One verifier command. One verdict. It exists because a conformance claim needs to be portable — carried in one file that anyone can recognize offline — instead of scattered across bundles and living on trust.
Concept boundaries
This format is where PQ-Verified recognizes and asserts conformance. It stays inside that lane:
- The artifact records that PQ-Verified recognizes conformance; it does not render the independent verdict — that is Verification, where a third party re-checks this same artifact offline, trusting no one. The embedded verifier_command and verifier_url exist so anyone can produce that independent verdict.
- It records recognized conformance; it does not score software or controls maturity against a rubric — that is HICS.
- The evidence inlined in each attestation is produced by H33-74, the portable 74-byte PQ evidence primitive; the artifact carries and recognizes that evidence, it does not produce it.
When to use it: whenever a subject needs a portable, single-file assertion that it conforms to the PQ requirements — demos, releases, customer self-attestations, regulatory submissions, audit evidence. When not to: when you need an independent verdict you can cite (re-run the verifier yourself — Verification), a maturity grade (HICS), or the underlying PQ evidence itself (H33-74).
Structure
File format
| Property | Value |
|---|---|
| Schema ID | h33-pq-verified-artifact/v1 |
| File extension | .h33pqv.json |
| Encoding | UTF-8 JSON, pretty-printed (2-space indent) |
| Typical size | ~30–50 KB self-attestation; varies with subject |
| Canonicalization | Object keys sorted lexicographically; minimized for hashing |
| Hash algorithm | SHA3-384 throughout (96 hex chars) |
| Signatures | Triple-family PQ: ML-DSA-87 · SLH-DSA-256s · FALCON-1024 (base64). All three must validate (3-of-3 AND-gate). FALCON = FN-DSA / FIPS 206 draft; ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) are finalized. Parameter levels are per-binding: this self-attestation binds at NIST Level 5; PQ-Verified recognizes the full ladder (ML-DSA-44/65/87 · SLH-DSA-128f/192f/256s · FALCON-512/768/1024, NIST Levels 1/3/5). |
What gets verified
| Check | How |
|---|---|
| Schema version | Must equal h33-pq-verified-artifact/v1 |
| Top-level fields | 11 required: schema_version, artifact_id, cycle_id, issued_at, issuer, subject, attestations, manifest_hash, signatures, verifier_command, publishing_rule |
| Each embedded attestation | Verified against its own pillar schema (required fields, publishing_rule const, fingerprint regex, result enum) |
| attestation_hashes | Recomputed canonical SHA3-384 over each attestation; mismatch → FAILED |
| manifest_hash | Recomputed canonical SHA3-384 over (cycle, issuer, subject, hashes); mismatch → FAILED |
| Signatures | PRESENT (all 3 PQ sigs valid — the 3-of-3 AND-gate is satisfied) · PENDING_CEREMONY (3× PENDING markers) · PARTIAL (fewer than 3 valid → FAILED) · MISSING (→ FAILED). Anything short of 3-of-3 is FAILED, never conformant. |
| Cycle consistency | Every embedded attestation's cycle_id matches the artifact's |
Verdicts
| Verdict | Meaning |
|---|---|
| VERIFIED | All structural + hash + signature checks pass. All three signature families (ML-DSA, SLH-DSA, FALCON) present and validating — the 3-of-3 AND-gate. |
| VERIFIED_PENDING_SIGNATURES | Structure and hashes valid. Signatures pending (pre-ceremony state). Treat as "the math is right, but the production keys haven't signed yet." |
| FAILED | Any check failed. The why list enumerates exactly what. |
Verify any artifact
Drag-and-drop (zero install):
https://h33.ai/pq-verified/verify/ — runs entirely in your browser. Files never leave the page.
CLI:
Exit code 0 = VERIFIED · 1 = FAILED · 2 = ERROR. Output is structured JSON.
Schema
pq-verified-artifact-v1.schema.json · JSON Schema draft-07.
Where to use it
| Surface | Outcome |
|---|---|
| Every H33 demo (Solana Privacy · Zcash · HATS · Agent Zero · Governance Replay · Commerce) | Ends with "Download PQ-Verified Artifact" CTA |
| Every H33 release | Bundled alongside the release manifest |
| Every customer self-attestation | Customer publishes their .h33pqv.json at their own attestation URL |
| Regulatory submissions | Attach the artifact to the submission package |
| Audit evidence | Auditor receives ONE file instead of a folder of bundles |
Frequently asked
What is a PQ-Verified Artifact v1?
A single self-contained JSON file in which PQ-Verified recognizes and asserts that a subject conforms to the post-quantum requirements. It carries the manifest, five inline pillar attestations, SHA3-384 hashes, and triple-family PQ signatures — one drag-and-drop, one verifier command, one verdict.
Does the artifact itself constitute the independent verdict?
No. The artifact records that PQ-Verified recognizes conformance; it does not render the independent verdict. That is Verification — a third party re-checks this same artifact offline, trusting no one. The embedded verifier_command and verifier_url exist so anyone can produce that verdict for themselves.
Is this a maturity score for my product?
No. The artifact records recognized conformance; it does not score software or controls maturity against a rubric — that is HICS. VERIFIED means "this subject asserts PQ conformance," not "this subject is mature."
Where does the evidence in the attestations come from?
The portable evidence inlined in each attestation is produced by H33-74, the 74-byte post-quantum evidence primitive. The artifact carries and recognizes that evidence; it does not produce it.
What signatures make an artifact VERIFIED?
All three PQ signature families must validate — the 3-of-3 AND-gate: ML-DSA-87 (FIPS 204, finalized), SLH-DSA-256s (FIPS 205, finalized), and FALCON-1024 / FN-DSA (FIPS 206, draft). Anything short of all three is FAILED, never conformant; two of three is a false grant. H33 verifies against these NIST standards rather than owning them.