The PMU does what we say — every claim, every evidence path

A receipt. For each load-bearing claim in the PMU story (current implementation AND future-implementation), this page names: what we claim, at what altitude, at what status, with what evidence, reproducible how. Six altitudes — substrate physics up through commercial — plus a future- implementation column for the post-funding research bets we're explicit about not yet having delivered. The point: every line in the leave-behind, the demo script, the pricing doc, the moat, the deployment manifest traces back to a row in this table. Pick any sentence we publish about the chip and you can find the cell it derives from.

§0 How to read this

Status legend: PROVED — measured / tested, reproducible · DEMONSTRATED — empirically shown on this host with caveats · BY CONSTRUCTION — argued from structural properties of the system · FUTURE — milestoned research bet, not yet delivered · DEFERRED — intentionally postponed (post-pilot data, etc.).

§1 Substrate altitude — silicon physics on this laptop

§2 Algorithm altitude — row-walk, transpose-spawn, superposition

§3 Architecture altitude — composite, structural claims

§4 Outreach altitude — what the buyer reads

§5 Commercial altitude — pricing, margin, TAM, ask

§6 Future altitude — milestoned research bets (explicit, not asserted)

§7 Strategic use — how this proof propagates

The receipt above is the single source of truth. Every claim made elsewhere in the PMU artifact set traces back to a row above. The propagation pattern:

• Spec docs — every load-bearing assertion in pmu-counter-module-shortlex-spec.md + pmu-ballistic-walk-spec-2026-05-23.html + pmu-cloud-bridge-spec-2026-05-22.html cites a claim ID from this doc (e.g., "per §6/M-D1 the post-pointer-chase daemon variant achieves …").
• Code — every test header (tests/pmu-simulator/*.test.mjs) names the claim ID it validates (e.g., ballistic-walk-N.test.mjs validates B6). When a test regresses, the failing claim ID surfaces to the proof receipt's status column.
• Web — the public-facing chip pages (thetadriven.com/pmu, /insurability, the blog posts that cite the Skybridge demo) link to the proof receipt as the "every claim, every evidence path" reference. The receipt is the citation target.
• Leave-behind + demo script + pricing + moat + manifest — each claim made in the customer-facing docs gets a small superscript reference to the proof ID (e.g., "the cache notarizes^D8"). The underwriter can re-derive any number by clicking through to the receipt.

What "all altitudes, all claims" means operationally

Every horizontal slice of the company — substrate physics, algorithm, architecture, outreach, commercial, future research — has a row. Every vertical slice — a specific underwriter conversation, a specific patent claim, a specific code path — cites at least one row. The proof receipt is the bidirectional index that prevents claim-drift between artifacts: if pricing §X claims a margin that the inner-monologue receipt didn't validate, the citation chain catches it.

§8 What Linux would actually add (honest accounting)

The proof receipt above runs entirely on Apple M-series (arm64). A natural follow-up: "would Linux validation strengthen any of this?" Walking the receipt claim-by-claim:

Where Linux GENUINELY adds (and when)

• M-D1 (direct PMU counter access) — Linux's perf_event_open exposes RDPMC, cache events, TLB misses, branch mispredicts directly to unprivileged userspace (with perf_event_paranoid ≤ 1). This IS the M-D research bet's natural surface: collapse the per-call daemon overhead by reading counters directly instead of running a pointer-chase. Apple Silicon's AMX counter access is more restricted; Linux is the easier first target. Timeline: M-D1, mo 9 (Feb 2027) per pricing §5.3.
• eBPF per-syscall attribution (spec §5b) — the original PMU spec wanted per-syscall attribution via DTrace; DTrace is gone on macOS post-Big Sur but eBPF on Linux is more powerful than DTrace ever was. Closes spec §5b without needing the deferred-compromise. Timeline: post-pilot, when the first production deployer is Linux.
• Production deployer reality — the May 29 demo runs on Mac because the underwriter is reading the demo, not running it. Actual deployers run production on Linux servers; a Linux daemon binary is required BEFORE the first paid conversion converts the pilot. Timeline: mo 4–6 of pilot (operational, not research).
• PRO-7 Asahi cross-platform calibration — Asahi Linux on Apple Silicon gives "Linux validation" without leaving the M-series hardware family. Useful as the scientific-rigor confidence-builder for the patent CIP supplement — flips to PRO-1 priority if F2 (patent CIP) becomes the forcing function instead of F1 (May 29 underwriter). Otherwise deferred. Timeline: conditional on F2.

The honest sentence for the underwriter / technical inspector

"The chip-thesis is hardware-agnostic by construction (C4/C5 in the receipt). We measured it on the dev host (Apple M- series) because the demo is the deliverable, not the substrate; the algorithm runs unchanged on Intel / AMD / ARM Linux. Cross-platform calibration is a defensible follow-on (PRO-7), and the M-D research bet's natural surface is Linux's perf_event_open for direct PMU counter access — both timelines in the funding ask."

Equivalently: Linux adds rhetorical weight and unlocks the M-D research path, but no claim in this receipt currently depends on a Linux measurement to hold. The technical inspector who asks "does this work on Intel?" gets the by-construction answer + the PRO-7 commitment + the M-D timeline. The underwriter who asks "will it run on our production servers?" gets the mo-4 operational commitment in the pilot timeline.

§9 What this proof does NOT do

• Does NOT promise the Future claims (§6) are delivered — they are explicitly milestoned post-funding. Calling them "FUTURE" is the honest framing; calling them "PROVED" would be the thing the inner-monologue gate would catch and reject.
• Does NOT cover claims in the v20 patent that depend on cross- deployment data (C2 / D7 / CB-1 cluster). Those are DEFERRED with named scope-fences in the deployment manifest.
• Does NOT replace the inner-monologue gate (gdd-monologue-pmu-financial-story.md). The monologue is the audience-stress-test; this receipt is the evidence index. Both gates are required for "the financial story holds at > 95% triple-%."

§10 What the proof means — client needs, expansion math, reach

§§1-8 establish that the PMU works. §10 names which clients need what, what the proof rows let each client priceably do, and crucially what we can reach for once the insurability beachhead holds. Insurance is the first product, not the ceiling. The chip- substrate is a visa — the right-to-act in a verified context — and the same proof rows that anchor an insurance premium anchor every adjacent visa product. The Six Needs canonical order (hooks/pre-commit, thetacog-spec): Connection → Contribution → Growth → Uncertainty → Certainty → Significance — melds into the three cardinals as the structural map below, but the operational read is per-client and per-product:

§10.1 Client needs — who buys, what they need, what the proof unlocks

§10.2 The visa model — insurance is the floor, not the ceiling

The proof rows that anchor a 25 bps insurance premium anchor a much larger reach. The same substrate certifies the deployer's right-to-act in multiple overlay markets; each takes its own premium against the same attested exposure:

§10.3 Expansion math — $125k is the floor of one product

Walking the same deployer (mid-market, ~$500M/yr attested exposure) through the visa-overlay stack as it lights up:

The $125k premium I quoted in the leave-behind (at a $100M-exposure deployer, the smaller end of mid-market) was the single-product insurance-overlay floor for a single deployer. The visa-stack reach for the same deployer is ~$400k-700k/yr at maturity; for a major-underwriter book the same multiplier yields ~$46-83M/yr from that one underwriter relationship. The chip- substrate is a 3-7× pricing lever once the adjacent overlay markets ratify the attestation format.

§10.4 What the doc PROVES we can reach for — honest accounting

§10.5 Six Needs read — structural map (the §10 closer in canonical form)

The Six Needs framework gives the structural map of WHY each client need couples to a priced surface. Kept here as the structural-pattern reference; the per-client and per-product reach above is the operational read.

§10.6 The six needs against the six altitudes

Each need is read in three registers: human (what the need asks for), value/finance (what the platform charges or saves for it), and strategic-business (which moat layer it strengthens). Receipt-row IDs hyperlink to the source evidence.

§10.7 How the needs map to altitudes (the cross-section)

Reading the receipt by altitude, the six needs appear at every layer in different intensities:

§10.8 What the proof means in one paragraph

Companions: docs/architecture/pmu-proof-shape-2026-05-23.html (the original 22-claim matrix this receipt extends) · docs/architecture/pmu-skybridge-robustness-2026-05-23.html · docs/architecture/gdd-monologue-pmu-financial-story.md · scripts/gdd/goals/pmu-may29-underwriter-demo.md. Citation format for other docs: a superscript claim-ID linking to this receipt's anchor (e.g., <sup><a href="pmu-provability-2026-05-23.html#D8">D8</a></sup>).