Product Preview · local runtime · mock signatures · no production dataVerify a receipt →
A new app shell is ready.Reload to activate the cached update.
H3
H33 · PQ-Video
Q3 Board Review·Host Sarah Chen·14:02:18 PT·Genesis 9a3f…b21c
SC
You · Host
6 participants·3 humans · 2 agents · 1 service·
Firewall·7 admit·1 refuse
Standard catalog
R
Research Agent
read, search, summarize · {read}
⏎
L
Legal Agent
draft, review · {review, draft}
C
Compliance Agent
in session · {read, flag}
P
Procurement Agent
in session · {vendor.contract}
N
Note Agent (extra)
service · {transcribe}
+
Custom agent…
configure delegation manually
Pending agent action requests1
R
Host task · Research Agent
runtime: deterministic local retrieval over a vendor corpus · emits a real AgentAction object into the meeting · substrate swap-in arrives with scif-backend
Human
SC
Sarah ChenVerified Human
Host · Root
cap unboundedcat {*}
chain: root
Human
MI
Marcus ItoVerified Human
CFO
cap $25Mcat {wire, contract}
chain: root → Sarah
Human
LP
Lin PatelUnverified
General Counsel
cat {review, sign-off}
chain: root → Sarah → legal.v3
AI Agent
C
Compliance AgentVerified Agent
AI · Std
cap $0cat {read, flag}
chain: root → Sarah → policy.v8
AI Agent
P
Procurement AgentVerified Agent
AI · Custom
cap $50Kcat {vendor.contract}
chain: root → Marcus
Service
N
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.
verifier_url:https://h33.ai/verify/ verification: offline against the H33 substrate public-key bundle · no live H33 access required independence: cryptographic_not_transactional · valid as evidence even if originating grants are later revoked
AuthorityGrants Created · what this receipt witnessed
EMPTY
No persistent authority issued from this meeting yet.
Open the Grants registry from the topbar and issue an AuthorityGrant. The receipt witnesses it, the credential carries the snapshot.
—
Snapshots Delivered · bounded context for late-joining agents
QUEUED
No late-joining agents in the room yet.
Inviting an agent mid-session triggers Agent Firewall admission + signed MeetingStateSnapshot delivery. Every action that agent emits cites the snapshot_id for provenance.
—
Executions · primary outcomes of approved decisions
QUEUED
Approve a runtime request to populate this section.
Each approved AgentAction fans out through registered Executors and produces signed ExecutionArtifacts bound to this receipt.
—
Meeting Summary · derived view over the execution graph
Decisions0
No verdicts yet.
Actions Created0
No actions yet.
Executions Started0
No executions yet.
Open Follow-ups0
Nothing pending.
note: these four panels are a pure projection of
AGENT_RUNTIME.{actions, verdicts, executions}
· no separate ontology, no parallel source of truth
Reusable authority objects · survive past meeting end · evidence trail tied to originating receipt
Quick-issue templates · host action
Authority Grant Registry · current state
EMPTY
No grants issued yet.
Issue a grant from the templates above to populate the registry. Each grant persists past meeting end and survives until expired or revoked.
—
Future Meeting Resolution Preview · persistent authority across sessions
"If a meeting started in N days, who would have what authority?"
Issue at least one grant, then click Resolve to see who would have authority in a future session.
Cross-Session Resolution Test · Grant × Credential dual-track
"In Session B, can this actor use this authority?"
Simulates a future meeting (Session B) where an actor attempts a specific action.
Resolution walks both tracks side-by-side: authority_source (Registry · current truth)
and authority_evidence (Credential · historical proof). The two can disagree — that is the point of separating them.
Pick an actor + action + days-from-now, then click Resolve. The result shows both Registry (current) and Credential (historical) outcomes, plus the dual-track verdict.
PQ-Video · Product Preview · v3
PQ-Video · Local Persistence
Saved State
All state below lives in this browser's localStorage. Clearing it does not touch any server.
Saved sessions · 0
No saved sessions yet. The current session auto-saves whenever a grant is issued or a credential is downloaded.
Recent credentials · 0
No credentials downloaded yet. Open the Receipt modal and download a .h33pqv.json to populate this list.
Reset
Clear all saved sessions and credential history.localStorage entries with the pqv: prefix are removed. Cached service-worker shell stays.
What PQ-Video produces
The PQ-Video Meeting Receipt is a portable, offline-verifiable evidence object — a .h33pqv.json credential built on the H33-74 primitive that anchors what a session witnessed (participants, decisions, authority grants, executions) so it can be re-verified later by anyone holding the H33 public-key bundle, without trusting H33 and without a live connection.
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; production receipts are signed with the triple-PQ substrate and verifiable at /verify/.