The page underwriters, adjusters, and counsel can read in a single sitting. Each scenario starts with a real-world dispute and ends with evidence a third party can verify on their own workstation — without trusting H33.
A regional manufacturer files a $4.2M ransomware claim. The cyber policy requires multi-factor authentication on all admin sessions. Carrier's coverage counsel asks: was MFA actually enforced at the time of intrusion, or was the control documented but not running? Without a millisecond-level answer, the carrier can deny under the standard MFA exclusion.
2026-04-17T03:14:22Z — the timestamp of the privileged session that pushed the ransomware payload.mfa_challenged, mfa_succeeded, auth_method, and a committed_policy_hash binding the MFA policy in effect at that millisecond.03:14:22Z resolves to: mfa_succeeded = true, auth_method = totp+webauthn, session granted. Attacker then stole the session token via cross-site request from a compromised laptop — covered under the social-engineering rider.audit-attestation: AttestationOutcome::Valid. Carrier counsel verifies on their own workstation; same outcome.committed_policy_hashA SaaS company files a $7.8M reliance-loss claim after a breach attributable to a vendor whose SOC 2 audit attested to "controls observed in operation" during the prior quarter. Three months later, forensics reveal the controls were configured but never actually running. The insured wants the carrier to indemnify, then subrogate. The vendor argues the audit was thorough.
control-execution receipt every time a control fires. Aggregated across the audit observation window, the vendor's environment produced zero receipts for the attested controls. The audit was performed against documentation, not running systems.0 control-execution receipts for controls AC-2, AC-6, SI-4. A live environment with those controls running produces tens of thousands.audit-attestation over the empty-corpus claim: corpus_size = 0, signed and time-stamped. The phantom-audit assertion is now itself a verifiable artifact.A financial services firm files a $12.0M claim following an insider-incident. The carrier reviews the insured's policy and asks whether the version produced in discovery is the version that was actually in effect at the time of the incident — or whether it was edited afterward to retroactively support the claim. $9M of the claim hinges on policy authenticity.
policy_v3.4.7, produced in discovery, is identical to the policy in effect at 2026-03-09T18:21:00Z — the moment the disputed decisions were made.committed_policy_hash bound at the moment of decision. Recomputing the canonical hash of policy_v3.4.7 in discovery yields the same hash the receipts pin. Policy authenticity verified.03-09T18:21Z carry committed_policy_hash = 4f8a2c91…b3e7. Each receipt is triple-family signed by the substrate at decision time.policy_v3.4.7 as produced in discovery → 4f8a2c91…b3e7. Match. Had the policy been edited post-incident, the recomputed hash would differ in the first changed byte.policy_version_hash_matches_decision_receipts = true. Carrier verifies on its own workstation.
A treasury services firm files a $2.3M wire-fraud claim. The
compromised agent had a $50,000 authorization ceiling. The
attacker attempted to wire out $2,300,000. The substrate
rejected the request. The wire still cleared — through a
downstream payment processor that wasn't reading H33 decisions. The
carrier asks: who is on the hook?
Negative Authority Proof shows the substrate denied the $2.3M transaction in real time. scope_check = Denied, attempted_amount = 2,300,000, denial_threshold_amount = 50,000. Downstream channel ignored the denial.incident_T+0.114s: artifact_binding_hash, committed_scope_hash, scope_check = Denied, denial_axis = DecisionAmount. Triple-family signed.substrate_denied = true, downstream_consumed_denial = false. The dispute becomes about integration depth, not about authorization.Following a $5.1M post-incident remediation claim, forensics surface a signing key the insured insists was "provisioned and registered" weeks before the incident — a key with anomalous activity. If true: covered. If false: the insured is claiming for a control that did not exist. The carrier asks H33 when the key actually entered the substrate.
2026-03-01 (insured's claim) or 2026-04-22 (post-incident). Determines whether the key was "in operation" at incident time.registered_at_unix_ms is signed at append time and bound to the registry tip at that moment. Walking the chain locates the registration at 2026-04-22T11:09:14Z — 26 days after the incident. Backdating impossible.KeyRegistryRecord for the key. registered_at_unix_ms = 1777678154000. prev_record_hash chains to record #N−1 whose own timestamp is post-incident. Mutating the timestamp breaks every subsequent record's hash.backdating_attempted = true.Each scenario above runs through the same three-artifact pipeline. There is no proprietary claims engine, no per-customer plumbing, no carrier-specific integration.
1. Receipt. The substrate produced a structured artifact at the moment the decision was made: an authentication receipt, a control-execution receipt, a Negative Authority Proof, a registry append, or a verification receipt. The receipt is signed once, by the substrate, against an immutable policy hash.
2. Replay. The decision is re-derivable. Given the receipt, the inputs, and the policy hash, anyone can reproduce the same outcome on their own machine. If the replay diverges from the receipt, the receipt is invalid. If the replay matches, the decision is independently verifiable.
3. Auditor output. A separate principal — the auditor — countersigns the
receipt and the replay outcome. The auditor cannot fabricate a receipt; they can
only attest to what the substrate already produced. The signed attestation is
itself a portable .h33pqv.json artifact a carrier, broker, or counsel can
drop into a verifier.
The carrier never trusts H33. The insured never trusts H33. Both verify the same artifact against the same registry replica and reach the same outcome.
The scenarios on this page are illustrative: the dispute shapes, the receipt structures, the chain-of-evidence steps, and the outcome semantics are all real and match the production substrate. The dollar figures, party names, and timestamps are composite — drawn from anonymized claim patterns, not from any single named customer matter.
Here's exactly what is and isn't live in production today:
| Component | Status | Source | Notes |
|---|---|---|---|
| Authentication receipts | LIVE | Cachee-Auth (Rust) | Production at auth.h33.ai; structured receipt for every authentication event. |
| Negative Authority Proofs | LIVE | qsign-nap | Production crate; .h33pqv.json emitted on every substrate denial. |
| Federation key registry | LIVE | qsign-fed-registry | Append-only, hash-chained; 11/11 tests; review bundle frozen at qsign-federation/v0.6-review-bundle. |
| Verification receipts + audit attestations | LIVE | qsign-fed-receipts | 7/7 tests; multi-org demo runs end-to-end. |
| HATS Phase 6 gate + receipts | LIVE | hats-demo | 92/92 tests; PERMIT and REJECT vectors emit verifiable artifacts. |
| Triple-family PQ signatures (ML-DSA-87 + SLH-DSA-256s + FALCON-1024 at 2-of-3) | LIVE | h33-root::sig | PQ-only invariant; no classical fallback. |
| Drag-and-drop verifier (in-browser) | LIVE | /demo/nap-v0.2/ · /attack-center/artifacts/ | Structural checks live in browser; full PQ verify via CLI. |
| Claim narratives + dollar figures on this page | ILLUSTRATIVE | Composite | Modeled on anonymized real-world claim patterns. No single customer matter is depicted. |
| Carrier / broker workflow integration | PILOT | Direct engagement | Productized carrier UX (claim intake → receipt corpus → attestation) is the active sales motion; this page is the buyer-facing surface for those conversations. |
| Downstream-consumer enforcement (cf. Scope Escalation) | CUSTOMER-SIDE | n/a | The substrate emits denials; downstream integration is the customer's payment processor / system of record. Sprint 4 (HATS production rollout) closes this on the H33 side. |
For a live walk-through tailored to a specific carrier or broker scenario, see the Attack Center drop-test artifacts and the Authority Center page.