A real authority decision. Cryptographically anchored. Independently reconstructable.
On June 2, 2026 at 00:28:40 UTC, H33 produced its first real anchored authority decision for a real customer. The bundle is retrievable. The receipt is anchored. The chain that produced it is open to inspection.
Step through the exact chain that produced this bundle — identity → authority → replay → receipt → anchor → bundle — with real values displayed at every stage.
Three claims, all reconstructable from public artifacts.
01
Identity can be mapped to authority.
02
Authority can be replayed from canonical history.
03
Evidence can be independently reconstructed.
Reading any H33 proof · the six questions
Same six answers. Different scope. The reader recognizes the machine.
1What happened?
A real customer (princ_customer_9) signed in, presented an Auth1 Bearer, requested an export_content_bundle decision through the V101 endpoint, and received an H33-74-anchored content bundle.
2Who had authority?
princ_customer_9 (Eric Beans, customer_id=9), via auth_44962d9b-…_v101_export against pol_v101_exporter_v1, rooted at princ_root_v101_44962d9b-….
3How was authority reconstructed?
replay_until(events, T, tenant=tenant_v101_44962d9b-…, root=princ_root_v101_44962d9b-…) against the canonical event log, signed with production three-PQ keys.
4What state was produced?
Authority state_id = 96a29047…be4a, verdict Valid, one active grant authorizing export_content_bundle, zero excluded authorities.
5What artifact was returned?
Bundle d9adcfb0-e0bc-426b-8725-fc12d555692b — embedded 74-byte H33-74 receipt over the IssuedReceipt commitment, anchored on h33-substrate-v1. Publicly fetchable.
6How can a third party verify it?
GET app.v101.ai/v101/bundle/d9adcfb0-… · auth.h33.ai/.well-known/jwks.json for the Bearer-validating keyset · scif-backend @ 99756176c for the reproducible chain.
01What was proven
A customer signed in. They asked for an export. H33 looked up their authority, reconstructed it from the canonical event log, confirmed a real policy backed it, issued a decision receipt, anchored that receipt cryptographically, and returned the result. Every arrow above is real. No synthetic identities. No test credentials. No mocked authority. No simulated replay.
Determination
H33-CANONICAL-AUTH-v1: proven in operation for one customer, one bundle. The next customer earns the same yardstick. The next surface earns it again. That discipline is the proof.
02Direct evidence
Every value below is checkable. The bundle URL returns the full JSON. The anchor field encodes a 74-byte H33-74 receipt that anyone with the public keys can verify. The chain of identifiers ties back to the original signed events in the canonical log.
First 32 bytes (64 hex) = the receipt's SHA3-256 commitment. Next 42 bytes = the H33-74 CompactReceipt — a fixed-width binding of the commitment to three post-quantum signatures (ML-DSA-65, FALCON-512, SLH-DSA-SHA2-128f) plus a verified-at timestamp and algorithm flag. Anyone holding the three public keys can recompute the verification hash and confirm authenticity without consulting any external chain.
03The chain that produced it
Six stages. Every stage runs against deployed production infrastructure. No stage can be skipped, faked, or replayed in isolation — the receipt's source_jti ties it to the exact Bearer, the Bearer's claims tie back to Auth1's signing key, the authority grant traces back to a signed canonical event, and the anchor encodes the receipt's commitment in a way only the production PQ keys can sign.
1
Identity
Customer signed in to auth.h33.ai via the production OTP flow. Auth1 minted a fresh EdDSA Bearer with sub=princ_customer_9, iss=https://auth.h33.ai, aud=substrate-receipts, signed by kid-eddsa-prod-active-2026-06-01-d31134fbc177.
2
Authority lookup
V101 forwarded the Bearer to api.h33.ai/api/v1/h33-auth/v101-bundle-issue. JwksValidator verified the signature against the deployed JWKS. The subject was canonicalized to princ_customer_9.
3
Replay
The canonical event log was replayed forward to now. The grant auth_44962d9b-…_v101_export — signed by the tenant root, granting export_content_bundle to princ_customer_9 — resolved as active.
4
Policy evaluation
The grant's policy_basis = pol_v101_exporter_v1 was looked up. The policy explicitly grants the requested capability. The decision: allowed.
5
Anchor
The receipt was canonicalized, SHA3-256 hashed, and anchored via H33SubstrateAnchorSink — producing a 74-byte H33-74 receipt over the commitment using the production three-PQ signer (ML-DSA-65 + FALCON-512 + SLH-DSA-SHA2-128f). Chain identifier: h33-substrate-v1.
6
Bundle
V101 embedded the anchored receipt into the customer's content bundle, persisted it, and returned d9adcfb0-e0bc-426b-8725-fc12d555692b — publicly retrievable right now.
04Why this is different
Most platforms record an authority decision. H33 reconstructs it. The receipt does not say "trust us, we logged this" — the receipt is a fixed-width binding of the decision's content (the commitment), the production identity (the principal), the underlying authority grant (the authority_id), and the policy that justified it (the policy_basis). The anchor is not a trust marker. The anchor IS the proof, signed by three independent post-quantum families that would each have to break simultaneously for the receipt to be forged.
Anyone with the public keys — published in the JWKS at auth.h33.ai/.well-known/jwks.json for the Bearer side, and the three substrate public keys (whose fingerprints are recorded in the operator's secret store and reproducible from the keypairs themselves) for the anchor side — can verify the chain without contacting H33. That's the meaning of independently reconstructable.
05Trust statement
Strict wording
This is the first operational proof of the H33-CANONICAL-AUTH-v1 chain. It is not "shipped." It is not "production-ready at scale." It is not "deployed for all customers." Every next customer earns the same proof. Every next surface earns it again. Every claim of production readiness gets measured against this exact yardstick: real identity, real authority, real replay, real receipt, real anchor, real artifact. Same chain. Every time.
Deployed via systemd cachee-auth on i-0f64d17ee49b88a6f. JWKS live at auth.h33.ai/.well-known/jwks.json; active kid kid-eddsa-prod-active-2026-06-01-d31134fbc177.
H33 — api.h33.ai (scif-backend)
SHA
Subject
99756176c
fix(canonical-auth): background JWKS refresh in build_production_validator (deployed)
ea0f4e9dc
fix(canonical-auth): block_in_place in PostgresEventLogSource::events_for
Deployed image: h33-rust:canonical-auth-99756176 on i-099b8356ab956a480. Anchor backend h33-substrate-v1. All six H33_SUBSTRATE_*_B64 env vars populated from AWS Secrets Manager h33/production/canonical-event-signer.
V101 — app.v101.ai
SHA
Subject
68034b1
V101 Content Bundle endpoint with CANONICAL_AUTH_REQUIRED=true, ANCHOR_HOST=https://api.h33.ai (deployed)
08Known limitations
These are the explicit constraints under which v1.0 was earned. They are not flaws — they are the boundary of what this proof claims.
Single customer. Only princ_customer_9 (eb@h33.ai, customer_id=9) was used. The chain is not yet proven for any other principal.
Single bundle. Bundle d9adcfb0-… is the only artifact produced through the full chain. Volume behavior is not yet observed.
No scale validation. No load testing, no concurrency testing, no throughput claims. Single-request demonstration.
No failover validation. No disaster-recovery drill. No cross-region failover. No database-failover test. No JWKS-source-unreachable test. Recovery characteristics are not yet measured.
source_jti replay behavior observed. The same Bearer (jti jti-1780359511-cf79e5f189cb41fd) produced two receipts in this proof cycle — once from the H33-side smoke test, once from the V101-side bundle issuance. The receipts have distinct commitment_hex, distinct submitted_at_ms, distinct tx_reference, but the same source_jti. Pending policy decision: declare idempotent OR enforce single-use at the receipt-issuance layer.
H33 Open Standards — HATS, HICS, CRV, OIS, Q-Key, and the H33-CANONICAL-AUTH-v1 specification.
The bundle itself — GET app.v101.ai/v101/bundle/d9adcfb0-…, public read.
Auth1 JWKS — the public keys that minted and signed the Bearer.
10Readiness determination
H33-CANONICAL-AUTH-v1: PROVEN IN OPERATION for one customer, one bundle.
What this proof unlocks: distribution. Conversations with prospects, auditors, insurers, and regulators can now move from "we are building this" to "we ran this; here is the artifact." The framework is reusable: every next customer milestone follows the same nine-section proof format at /proofs/<proof-id>/.
What this proof does not unlock: any claim of scale, multi-tenant production readiness, disaster-recovery readiness, or operational proof on any surface beyond V101. Each requires its own published proof, earned by the same yardstick.
11Version
Field
Value
Report version
v1.0 (Final)
Frozen
2026-06-02
Supersedes
None
Superseded by
None
Future operational proofs are published at /proofs/<proof-id>/ using the structure defined in /proofs/proof-template/. This v1.0 is the reference implementation of that structure.
Issued by H33, Inc. · Eric Beans, CEO · 2026-06-02