The canonical shape of an H33 operational proof.

Every published proof at /proofs/<proof-id>/ follows this structure: nine sections, three claims, brutally honest limitations, public artifacts that an independent party can fetch. The shape is the credibility. A proof that hides limitations is not a proof; a proof that buries the artifacts is a marketing page.

00aThe six questions (the reader's index)

Every proof page MUST answer these six questions, in this order, in a panel placed right after the hero / claims band. If a reader walks away with just these six answers, the proof has done its job — they recognize the machine, not the page.

1. What happened? One sentence in plain language. No internal jargon. A regulator should be able to repeat it back.
2. Who had authority? Name the principal, the authority_id, the policy basis, and the root. Every link traceable.
3. How was authority reconstructed? Name the function (replay_until), the input (events at T), the binding (tenant + root). No "the system checked."
4. What state was produced? The state_id, the verdict, the active-grant count, the excluded-authority count. Numbers, not adjectives.
5. What artifact was returned? Name and link the object the caller received. URL, identifier, or downloadable file. If "none" — say "none and here's why."
6. How can a third party verify it? The exact harness path + commit SHA + inputs. Anyone with this list should be able to reconstruct the proof without H33's help.

00bThe authority arc (the shape every proof traces)

Every proof — V101 export, transfer approval, AI decision, regulator replay, multi-tenant isolation — traces the same arc. If a new proof doesn't fit this arc, the proof is probably not yet about authority.

1. A principal is given authority. Through a signed canonical event. The grant is rooted in a tenant_root.
2. A policy constrains that authority. Capability, scope, expiry, conditions — all signed, all replayable.
3. The principal performs an action. Could be a human, a service, or an AI. The action itself is not the proof — the authorization is.
4. A decision receipt is issued. Naming the actor, the authority, the policy, the moment.
5. The authority chain is replayed. replay_until reconstructs the state at T; byte-identical, deterministic.
6. A third party reconstructs why the action was permitted. Without trusting H33. From signed events alone.

00How to publish a new proof

1. Pick a proof-id: short, kebab-case, describes the operational milestone. Example: first-tokenized-transfer, first-regulator-replay, first-ai-governance-decision.
2. Create /proofs/<proof-id>/ with three files: index.html (customer-facing page), REPORT.md (canonical markdown), report.pdf (rendered from the markdown via weasyprint or pandoc).
3. Use this template's section order. Don't skip sections — if a section is N/A, write "N/A — [why]" so the reader sees the reasoning.
4. Hold the strict wording: "proven in operation" for the scope covered. Never "shipped," never "production-ready at scale," never "deployed for all customers."
5. Add the new proof to /proofs/index.html as a card.

01Problem

Write 2–3 sentences in customer language. No internal jargon. Imagine a CFO, CISO, or regulator reading it for the first time. The reader should be able to repeat the problem back in their own words after one read.

Example: "Can a customer's authority to take a regulated action be reconstructed at any later time from independently verifiable evidence, without trusting the platform that recorded it?"

02Environment

List the deployed surfaces involved, the runtime versions, and the credentials used. Everything in this section should be checkable by an external auditor with read-only access.

• API surface: host + endpoint + deployed commit SHA
• Auth surface: auth host + deployed commit SHA + active kid
• Storage / event log: DB or store + relevant table
• Secrets used: name + version, never values
• Client / caller: V101 / partner / SDK + version

03Identity

The canonical principal that authorized the operation. Show the JWT claims (or equivalent credential payload). Never paste the secret-side material; show only what the receiver could see and verify.

sub  = princ_customer_<id>
iss  = https://auth.h33.ai
aud  = <audience matching the receipt-issuing service>
kid  = <active EdDSA / RS256 / ES256 kid>
jti  = <unique replay-protection id>
iat  = <unix seconds>
exp  = <unix seconds>

Verification path: any independent party with JWKS at the published URL can recompute the signing input and verify the signature.

04Authority

Trace the principal → authority_id → grant → policy chain. Every link must reference a signed canonical event. No "the system says it's allowed" — show the events.

• authority_id: auth_…
• Source grant event: signed; 148-hex signature
• granted_by / granted_to / policy_basis
• Source policy_register event: signed; 148-hex signature

05Replay

Document the replay input (event log, replay-until timestamp) and the snapshot output. The reader should be able to recompute the snapshot from the same inputs and get bit-identical results.

• Input: events_for(tenant_id) at t = <unix_ms>
• Snapshot verdict: Valid
• Active grants: list each entry: authority_id, granted_to, granted_by
• Determinism note: same events + same t → bit-identical state_id across implementations

06Receipt

The Issued Receipt is a fixed data structure that binds: the decision, the authority that backed it, the policy that justified it, the principal that exercised it, the audience it is scoped to, the issuance time, and the bearer's jti.

• decision: customer-facing description of what was authorized
• authority_principal · authority_id · policy_basis
• audience · issued_at_ms · source_jti

07Anchor

Document the commitment (SHA3-256 of canonical-JSON of the IssuedReceipt), the anchor chain identifier, and the 148-hex tx_reference.

• chain: h33-substrate-v1 / polygon-zkevm-cardona / …
• commitment_hex: 64 hex = SHA3-256(canonical_JSON(receipt))
• tx_reference: 148 hex = 32-byte commitment ‖ 42-byte CompactReceipt (or chain-specific tx hash)
• submitted_at_ms

Verification path: anyone with the three substrate public keys (or the relevant chain explorer) can confirm the anchor binds the commitment to the production signing material.

08Result

The caller receives a concrete object. Show its identifier and link it directly. No "the customer can access it through their portal" — the URL goes here.

• bundle_id / transfer_id / decision_id
• Retrievable at: GET <public or customer-scoped URL>
• Persisted by: V101 / customer service / H33 storage

09Evidence

List the public artifacts. Acid test: someone with only this list should be able to verify the chain themselves.

• JWKS URL
• Bundle / artifact URL
• Standards reference: https://h33.ai/standards/
• Substrate public key fingerprints (SHA3-256 first 16 hex)
• Markdown source of the report
• Downloadable PDF

10Three claims (the 10-second read)

Three bullets, customer language, top of the page. Most readers will read only this.

1. [Claim 1] — usually a single sentence about identity
2. [Claim 2] — usually a single sentence about authority
3. [Claim 3] — usually a single sentence about evidence

For the V101 first proof these read: "Identity can be mapped to authority. Authority can be replayed from canonical history. Evidence can be independently reconstructed."

11Known limitations

List every gap, every shortcut, every "this works but isn't ideal." A proof that hides limitations is not a proof. Limitations stay visible. They're how the next proof gets earned.

12Readiness determination

"PROVEN IN OPERATION" for an explicit scope. 2-3 sentences on what this proof unlocks and what it does NOT unlock.

This is a template. The current reference implementation is /proofs/v101-first-operational-proof/.