What the receipt costs to produce · what the underwriter pays

The chip-thesis numbers measured on M-series silicon (pmu-onchip, today): one 12×12 verification walk completes in 155.6 ns; a single XOR+popcount gate runs in 0.54 ns; the daemon's per-commit attestation parses + writes a JSON record in ~30 ms total (dominated by Node startup, not by measurement). At those numbers the marginal cost per receipt is fundamentally bound by ops + storage, not by compute. Pricing should reflect that asymmetry.

§1 Cost per receipt — the chip is effectively free

One receipt = one per-commit measurement + one drift-delta computation against the host's σ-baseline. Concretely:

At 100,000 receipts/month across a fleet of deployers, that's ~$11 in compute. Receipts are not where the cost lives. The cost lives in the relationship: the case-study authoring, the threshold-naming workshop, the actuarial review, the renewal conversation with the deployer when the first claim trips a flagged zone.

§2 Pricing model — insurance-shaped, three components

Per-receipt-only pricing answered the wrong question. "What's the % gross margin" is meaningless if the % is taken on the wrong base. Insurance has a canonical three-component structure (access fee + per-unit-of-exposure + risk- weighted premium); PMU pricing adopts the same shape. A deployer pays the sum of the three components below; each has its own margin profile.

What a typical deployer pays — monthly all-in

The premium becomes the dominant line at every non-toy deployer size. The chip's pricing matches the chip's value: more underwritten exposure per attestation → more revenue. Receipts and base rate keep the lights on; premium is where the business lives.

§3 Gross margin by component

Component-level margins are the only honest answer to "what's the gross margin." Each pricing component covers different costs and has a different marginal profile:

The blended margin at a typical mid-market deployer (~$16k/mo all-in) is ~78%: the premium dominates the revenue mix and pulls the average down from the per-inference 99%. That's correct — the premium IS the insurance value, and insurance values have actuarial reserves carved out of the gross.

The platform's actual cost base is people (relationship management, actuarial review, support, case-study co-authoring) — bounded by deployer count plus underwriter count, not by receipt count. The PER-INFERENCE component scales effortlessly; the PREMIUM component scales with the value the chip is actually attesting; the BASE RATE keeps the lights on.

§4 What the May-29 underwriter sees in the term sheet

For the first underwriter, the term sheet reads:

• Pilot: 6 months, 3 deployers. All three components waived during pilot (no base, no per-inference, no premium) — the pilot pays nothing.
• What we ask in return: read the stream weekly, name a drift threshold by month 2, co-author one case study by month 4, commit to renewal if first claim against a flagged zone is paid.
• Post-pilot (if trigger fires): tier-3 ENTERPRISE rates kick in — $500/deployer/mo base + $0.002/receipt per inference + 25 bps of attested exposure. For an underwriter with 100 deployers running $5B/yr aggregate exposure across them, that's approximately $0.6M/yr base + ~$3M/yr per-inference + ~$12.5M/yr premium = ~$16M/yr from this one underwriter relationship at maturity.
• Equity / IP carve-out: none required from the underwriter in pilot; the value exchange is schema co-authorship for waived fees.

The pilot is structured to make the underwriter the author of the receipt format, not just a customer of it. That authorship IS the moat's network effect; waiving all three pricing components in the pilot is what locks it in.

§5 TAM / SOM / burn — order-of-magnitude estimate

Estimates, not commitments — the dimensions are sized by the operator's own back-of-envelope; specific dollar figures will move ±5× under any real GTM modeling, but the magnitude is what matters for the May-29 conversation.

§5.1 Addressable market — who buys the receipt

Three concentric circles with timeframes and inter-circle paths named. Deployer-count derivations are cited (or marked "back-of- envelope from $X"); revenue uses the tier-3 rate card above:

Path between circles (the 10× gap is bridged, not jumped)

• Inner → Middle (yr 3 → yr 6, 10× expansion): first underwriter relationship scales horizontally. One Munich Re or Marsh book at 100+ deployers in their portfolio unlocks the next 10 underwriters; each underwriter is a force multiplier across their own book. Network-effect moat (Layer 3) compounds.
• Middle → Outer (yr 6 → yr 10, 10× expansion): compliance mandate (EU AI Act Article 14 deliverability chain, US sector-specific equivalents) makes PMU-style attestation the audit-trail floor for AI-using regulated industries. The pricing scales with attested exposure, which is much larger in regulated industries than in early-adopter SaaS.

How scale-invariance grows TAM (the lattice depth lever)

Each cell of the 12×12 lattice expands recursively into its own 12-axis sub-lattice (scale-invariance — see pmu-priorities-thinking-2026-05-23.html §0). A deployer needing compliance-taxonomy depth N=144 cells pays the same per- deployer pricing; a deployer at N=20,000 cells (3-level recursion) attests against a richer taxonomy and pays the same per-deployer base + per-inference, but their attested exposure typically grows with depth (more granular categories → more priced surface area → more premium dollars). Scale-invariance is a TAM-growth mechanism, not just an algorithm property.

§5.2 Underwriter-side TAM — different unit, same math

The other side of the market is the underwriting carriers themselves — each one is a multi-deployer customer at tier-3 enterprise. Approximate counts:

• ~40 specialty AI/cyber/E&O underwriting books globally with meaningful AI-policy exposure (Munich Re's Hartford AIG, Beazley, Coalition, Armilla, Vouch, etc.).
• Each could anchor 50-500 deployers depending on their book size.
• At 20 underwriters with average 100 deployers each at $42k/yr: $84M ARR.

The two sides converge: a single underwriter relationship that scales from 3 pilot deployers (the manifest's §1) to 100 deployed-against-policy deployers in 3-5 years is the path to the inner-circle SOM.

§5.3 Burn — what funds the path to the first $1M ARR

FTE ramp by month + line-item breakdown so the burn is auditable, not asserted:

M-D research bet — $640k itemized

The M-D bet is direct PMU counter access (RDPMC / perf_event / Apple AMX-aware counters) to detect sub-3σ workload distinctions the current pointer-chase-based daemon misses. SDK tooling is free; the $640k is for FTE + hardware:

Funding ask = $1.5M with milestoned next-round trigger

§5.4 Amortization caveat (technical inspector note)

The per-receipt cost extrapolated above to N=256 (and the implicit scale-invariance claim that pricing remains sub-cent at all N) assumes the daemon's per-call overhead (Node startup, JSON write, hook invocation) amortizes linearly with the gate- cycle count. This holds for the current pointer-chase-based daemon at all N we've measured (12, 32, 64); it's a deliberate scope assumption for the cloud-extrapolation table above and not yet validated at N ≥ 256 on hardware. The M-D research bet (direct PMU counter access) collapses the per-call overhead to ~zero, at which point the amortization assumption becomes trivially true.

§5.5 What the underwriter sees in §5

This section is for the budget writer's term sheet, not the underwriter's pitch deck. The underwriter cares about §1-§4 (their cost, their margin, the renewal terms). The budget writer cares about §5 (the TAM, the burn, the path to a serious revenue line). Both are audiences for this doc; the §5 numbers are estimates with stated ±5× uncertainty bands rather than promises.

Companions: docs/architecture/pmu-proof-shape-2026-05-23.html (A1, A3 cited above) · docs/strategy/pmu-moat-2026-05-23.html (Layer 3 network effect referenced) · scripts/gdd/goals/pmu-may29-underwriter-demo.md (long-form /goal). Stability report (A5): .thetacog/pmu/stability/2026-05-23T21-17-24.json.