Sheet PXM-R-100
Six phases. One trajectory.
Each phase produces enough information to make the next decision. Each phase generates revenue earlier than its replacement would. Failures fail cheaply because nothing downstream depends on them.
Complete / mostly
In progress
Planned
Long horizon
Phases, in detail.
Substrate familiarity. No product yet.
Months −6 to 0 · pre-Phase-1
Get HyperBEAM running locally. Confirm the proof generation pipeline works end-to-end on at least one real predicate. Establish the AO compliance process. Stand up the audit relay tooling. Write the public drawing set so that what's being built is legible to outside readers before it's customer-callable.
What's still in flight
- Ethereum L1 archival reconstruction path (A-120/S.03 · active build; local Erigon is syncing into a Google Drive-backed cold warehouse, A-201/A-205 can select the Erigon proof adapter, and encrypted Arweave proof archive plus AO-assisted compute remain the target architecture)
- x402 facilitator stub on Base testnet
- Remaining Phase 0 work: x402 facilitator integration and the L1 evidence/reconstruction gate — see phase-0 status
A-Series Phase 1 Blueprint covers the build sequence →
Five services live. Per-call settlement.
Months 0 to 12 · the ramp
The five Phase 1 services land at x402-native endpoints with draft pricing. Sync committee verification ships first; slot storage proofs and simulation follow; cross-chain message verification and verified historical state close the catalog. Operations runbook gets exercised. Audit posture accumulates real evidence. Reputation accumulates from the first transaction.
Build sequence
A-202 Sync Committee Verification — first, ~4-6 weeksA-204 Simulation as a Service — second, ~3-5 weeksA-201 Slot Storage Proofs — parallel, ~6-8 weeksA-205 Verified Historical State — parallelA-203 Cross-Chain Message Verification — last, ~6-10 weeks
Phase 01 → Phase 02 gates
- All five services running with measured uptime > 99.5% over 12 months
- Genuine transaction volume (not demo traffic)
- SOC 2 Type II audit in progress
- HIPAA BAA template ready
- First sales hire onboarded and ramped
- Phase 02 capital secured (likely external)
Phase 1 Service Schedule →
B2B expansion. Healthcare and financial services.
Months 12 to 30 · the bridge to enterprise
ZK proofs of computation on private inputs. Healthcare and financial services as anchor verticals. Enterprise B2B contracts at $25k–5M+ annual scale. Compliance infrastructure in place (SOC 2 Type II, HIPAA BAA). First sales hire driving pipeline. Reference customer relationship in one vertical, expansion across the customer's footprint, then second vertical.
What's added
- ZK circuits for medical record schemas (FHIR, HL7)
- ZK circuits for financial transaction formats
- ZK circuits for common compliance policies
- Compliance documentation packages (procurement-ready)
- B2B sales infrastructure (legal entity, MSA, invoicing)
- Customer success and integration engineering
Realistic year-3 ARR
- 10–15 Pilot customers at ~$40k → $400–600k
- 4–8 Production customers at ~$250k → $1.0–2.0M
- 1–3 Enterprise customers at ~$1.5M → $1.5–4.5M
- 0–1 Custom-tier deal > $5M → $0–5M
- Aggregate: $3–8M ARR by month 36 from Phase 1 launch
F-Series Phase 2 Vision Brief →
Inference verification at scale. Existing customers extend.
Months 30 to 48 · the ML expansion
Large-model ZK inference verification. Recursive proving stack at production scale. Integration with the major ML frameworks. Phase 02 customer relationships extend to ML-heavy use cases. New customer acquisition in segments where ML inference verification is the primary need (healthcare AI vendors, fintech firms running ML risk models, content moderation services).
What's added
- Recursive proving for billion-parameter models
- Specialized circuit optimization for ML operations
- PyTorch / TensorFlow / Hugging Face integration adapters
- Inference-specific proving backends (EZKL-class systems)
- Model attestation and lineage primitives
Why later, not now
- Specialized providers (Modulus, EZKL, Giza) have head-start expertise
- Phase 02 customer base is the access path; cold entry is harder
- Recursive proving for ML matures on its own timeline
- Compliance infrastructure from Phase 02 carries forward
Verifiable physical-world data feeds. Industrial scale.
Months 48 to 60 · infrastructure-grade
Verifiable telemetry from sensors, devices, and physical-world systems. SDF-native integration matures. Industrial customer base — supply chain, energy, environmental monitoring, ESG reporting. The substrate decisions in Phase 0 (AO/Arweave audit, SDF compatibility) make Phase 04 a build extension rather than a build rewrite.
Use cases when ready
- Cold chain integrity for pharmaceutical shipments
- Renewable energy production attestations
- Industrial process verification
- Environmental and water quality reporting
- ESG claims with cryptographic substantiation
Why long horizon
- IoT ecosystem is fragmented and slow-moving
- SDF and adjacent standards still consolidating
- Industrial procurement cycles are multi-year
- Bandwidth on Phase 02–03 customer wins is the bottleneck
Quantum-clean proving. The architectural completion.
Months 60+ · ongoing
Migration of the proving stack to post-quantum primitives as NIST guidance firms up and federal mandates apply. The pluggable proving architecture from Phase 0 makes this a per-service migration rather than a platform rewrite. Customers in regulated industries with post-quantum mandates have a verified compute provider that has already completed the migration.
What changes
- Hash-based and lattice-based proving systems become the default
- Existing services migrated one at a time, not all at once
- Customer-specific compliance attestations updated
- Audit posture extends to the migration itself (provable transition)
Why this is structural moat
- Federal post-quantum mandates roll out on a fixed timeline
- Customers downstream of federal vendors face the same requirements
- Platforms ready when the requirement firms up capture customers from those still mid-migration
- The architectural pluggability from Phase 0 is the load-bearing decision
R-200 · How phases connect
Each phase pays the next phase's bills.
Phase 01 revenue funds Phase 02 build. Phase 02 revenue funds Phase 03 build. The architecture in Phase 0 makes Phase 02 cheaper than it would otherwise be; Phase 02 makes Phase 03 cheaper; and so on. The cascade is what makes the long horizon credible — no single phase has to carry capital costs for everything that comes after.
The exception is the Phase 01 → Phase 02 transition. Phase 02's build cost (compliance infrastructure, first sales hire, vertical-specific tooling) is large enough that it likely exceeds Phase 01's surplus. External capital between Phase 01 and Phase 02 launch is the realistic case. Subsequent phases self-fund.
R-300 · The discipline
What the map demands.
- Don't skip phases. Phase 02 without Phase 01's operational track record fails procurement. Phase 03 without Phase 02's customer base is uncompetitive against specialized providers. The order is not arbitrary.
- Don't compress timelines. The 24–30 month bridge from Phase 01 launch to Phase 02 launch is real. Compressing it generally fails because the gates (SOC 2, BAA, sales hire ramp, capital) cannot be parallelized past a certain point.
- Don't expand scope mid-phase. Each phase ships a bounded scope. Adding capabilities mid-phase delays the gate that's needed to start the next phase. Save scope expansion for the next revision of the build map.
- Don't pre-build for later phases. Architectural decisions that keep later phases possible are correct (pluggable proving, audit posture). Building the actual capabilities of later phases before earlier phases ship is premature optimization that delays revenue.
R-400 · What this map does not promise
The honest disclaimers.
The map does not promise the architecture works. Phase 01 operations might reveal a fatal flaw in dispatch latency, gas costs, or a proof system selected. Phase 02 selling might reveal that healthcare or financial services procurement is harder than the realistic case suggests. Phase 03 might reveal that specialized verified-inference players have already locked up the customers Paxiom would target.
What the map does promise: each phase produces enough information to make the next decision honestly. The work compounds rather than starts over. Revenue arrives as early as possible to fund subsequent phases without external capital where possible. Every phase that works funds the next; every phase that fails fails cheaply because nothing downstream depends on it yet.
The platform succeeds or fails on execution against this map, not on the elegance of the map's articulation. The map is the planning tool; the work is what matters.
R-500 · Related documents
Where each phase is documented.
- Project Narrative (B-series) — the trajectory at higher resolution, with the founder context and the thesis behind each phase. Open the Project Narrative.
- Phase 1 Blueprint (A-series) — the detailed specifications for Phase 1 services, build sequence, and risk register. Open the Phase 1 Blueprint.
- Phase 2 Vision Brief (F-series) — the planning document for Phase 2, customer verticals, commercial motion. Open the Phase 2 Vision Brief.
- Operations Runbook (O-series) — the operational substrate that supports every phase. Open the Operations Runbook.
- Technical Architecture (T-series) — the AO dispatcher and proof-routing topology underneath all phases. Open the Technical Architecture.
- Compliance Architecture (CA-series) — what is recorded, where, and how to verify it independently. The audit posture that Phase 2 customers will require, established in Phase 1. Open the Compliance Architecture.