H33 PQ-Video · Product Preview

Q: Is a receipt accepted if two of the three signature families verify?

No. Verification is an AND of all three families: ML-DSA and FALCON/FN-DSA and SLH-DSA must all validate. A 2-of-3 outcome is treated as a false grant and the receipt is refused. There is no majority or threshold acceptance across the crypto families.

Q: Are the signatures on this preview real?

No. This is a product preview running a local runtime with mock signatures and illustrative sample data, with no production data or live keys. 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. Verification status is at h33.ai/verify/.

Product Preview · local runtime · mock signatures · no production data Verify a receipt →

A new app shell is ready.Reload to activate the cached update.

6 participants· 3 humans · 2 agents · 1 service·

Firewall·7 admit·1 refuse

Human

Sarah ChenVerified Human

Host · Root

cap unboundedcat {*}

chain: root

Human

Marcus ItoVerified Human

CFO

cap $25Mcat {wire, contract}

chain: root → Sarah

Human

Lin PatelUnverified

General Counsel

cat {review, sign-off}

chain: root → Sarah → legal.v3

AI Agent

Compliance AgentVerified Agent

AI · Std

cap $0cat {read, flag}

chain: root → Sarah → policy.v8

AI Agent

Procurement AgentVerified Agent

AI · Custom

cap $50Kcat {vendor.contract}

chain: root → Marcus

Service

Note-takerVerified Service

Internal

cat {transcribe}

chain: root → Sarah → svc.note

Authority Map · live

6 active · 1 refused

HumanAIServiceRefused

Live action stream · 14 events

Meeting actions created · 0

No actions yet. Approve a pending request to create one.

Replay 14:02:18 PT · NOW

13:10 · Genesis13:3013:5014:02 · NOW

Pause All Authority2-of-3 · host kill switch

7 admit· 1 refuse· 14 attested· 0 actions· 0 executions

Authority Detail

—

Authority Flow · delegation path to root

Session signing key · triple-PQ

Admission · Agent Firewall

Actions this session

PQ-Video · Product Preview · v3

What PQ-Video produces

The PQ-Video Meeting Receipt is a portable evidence object — a .h33pqv.json credential built on the H33-74 primitive that anchors what a session witnessed (participants, decisions, authority grants, executions) (independent re-verification not yet available for production receipts).

Why this exists. A recording proves a meeting happened; it does not prove who had authority to decide or that the record was not altered afterward. PQ-Video emits a signed evidence primitive at the moment of the event, so the proof travels with the artifact — attachable to email, JIRA, or a contract — and survives even if the originating grants are later revoked.

Use it when

a decision made in a session must be provable to a third party later;
you need evidence that outlives the meeting and any live registry;
an auditor, counterparty, or insurer must re-verify a claim offline.

Do not use it for

continuous monitoring of a running system — that is HATS;
rendering the pass/fail verdict on a receipt — that is Verification;
governing the decision an agent makes under authority — that is Agent-008.

Concept boundaries

H33-74 produces the portable evidence; it does not record or continuously monitor operations — that is HATS.

H33-74 produces the evidence; the independent verdict on it is rendered by Verification, and the decision made under it is governed by Agent-008.

The signing primitives (ML-DSA / FIPS 204, ML-KEM / FIPS 203, SLH-DSA / FIPS 205) are external NIST/FIPS standards that H33-74 uses to produce the evidence — H33-74 does not own or invent the primitive. A receipt is accepted only when all three signature families (ML-DSA and FALCON/FN-DSA and SLH-DSA) validate — a 2-of-3 result is a false grant and is refused.

Does PQ-Video own the ML-DSA / ML-KEM algorithms?

No. ML-DSA (FIPS 204), ML-KEM (FIPS 203) and SLH-DSA (FIPS 205) are external NIST post-quantum standards. PQ-Video and the H33-74 primitive implement, use, and verify against them to produce the receipt; H33 does not own, invent, or "prove" the underlying standard.

Is a receipt accepted if two of the three signature families verify?

No. Verification is an AND of all three families: ML-DSA and FALCON/FN-DSA and SLH-DSA must all validate. A 2-of-3 outcome is treated as a false grant and the receipt is refused — there is no majority or threshold acceptance across the crypto families.

How is this different from HATS, Verification, and Agent-008?

PQ-Video (on H33-74) produces the portable evidence at the moment of the event. HATS records and continuously monitors operations over time. Verification renders the independent pass/fail verdict on a receipt. Agent-008 governs the decision an agent makes under the authority the receipt carries. One evidence primitive, four distinct roles.

Are the signatures on this preview real?

No. This is a product preview running a local runtime with mock signatures and illustrative sample data — no production data or live keys. It shows the shape of the real evidence object. 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. Verification status is at /verify/.