A planning brief for what comes after Phase 1. Paxiom's second commercial phase is verified computation on data that can't leave the customer's perimeter — medical records, financial transactions, proprietary state. Same proof primitive as Phase 1, applied to a class of customer who cannot use Phase 1.
A vision brief is the document type before a blueprint. It establishes the territory, the customer, the architectural enablers, the commercial motion. It does not specify build sequence, deployment topology, or pricing tiers with the precision a blueprint requires. Those come later.
A planning document for Phase 2 of the Paxiom build. Phase 2 is private data compute — ZK proofs of computation performed on inputs that cannot leave the customer's perimeter for regulatory or commercial reasons. The verticals that anchor it are healthcare and financial services. The customers are mid-size and enterprise B2B. The commercial motion is sales-led with long procurement cycles and sticky integrations.
Phase 2 is not yet under construction. The substrate decisions in Phase 1 — HyperBEAM compute, AO/Arweave audit, Load Network evidence storage, Ethereum L1 witness verification, the proving stack — were made with Phase 2 in mind, and Phase 2 builds on that substrate rather than replacing it. But the specific Phase 2 work — ZK circuits for medical record schemas, compliance documentation packages, B2B sales infrastructure — has not begun. The realistic Phase 2 launch window is 12 to 18 months after Phase 1 services land at credible scale.
Not a build spec. Detailed service specifications, build sequence, risk register, and deployment topology will appear in a Phase 2 Blueprint analogous to the A-series Phase 1 Blueprint when the time comes to build.
Not a pitch deck. The audience is the founder, future advisors, and the future Paxiom team. The document is for thinking through Phase 2 honestly rather than selling it. Where there is genuine uncertainty — and there is plenty — that is what gets written.
Not a fundraising document. Phase 2 may eventually require external capital; if so, fundraising materials will derive from this brief but will not replace it. The brief stays focused on what the platform should build and why, not what the funding round should look like.
Same construction-document register as the rest of the drawing set. Sheets are numbered. Cross-references go to specific sheets. Mathematical notation uses the same set-theoretic conventions as the Project Narrative's B-500 series, with italicized "read this as" translations following each formal statement.
Forward-looking claims are identified explicitly. Where a number, timeline, or customer specifics appear, they are estimates from the current understanding of the territory. Phase 2 reality will likely deviate from these estimates in directions that cannot be predicted from the current vantage point.
Phase 1 serves agents transacting over public chain state. Phase 2 serves customers who cannot use Phase 1 because their state is not public, cannot become public, and cannot leave their perimeter.
The structural property of Phase 1 is that everything it operates on is public. Ethereum chain state is public by construction. Cross-chain messages are public. Block headers, contract storage, transaction history — all visible to anyone with an Arweave gateway and time. The customers Phase 1 serves are operating against that public substrate.
Consider a hospital that wants to use a third-party AI service to flag patients at risk for a specific condition. The hospital has the patient records. The AI service has the model. The useful computation requires combining them. Sharing patient records with the AI service is a HIPAA violation. Building the model in-house is beyond the hospital's expertise. The useful computation does not happen, and the patients who would have benefited do not benefit.
Consider a hedge fund that needs to demonstrate its trading algorithm satisfies a specific regulatory constraint without exposing the algorithm to the regulator. The fund cannot show the code or the trades. The regulator cannot accept "trust us" as compliance evidence. The verification gap means either the fund operates with regulatory uncertainty, or the regulator forces disclosure that compromises the fund's competitive position. Both outcomes are bad for both parties.
Consider a contract manufacturer producing components for multiple competing customers, each requiring proof that their data is not commingled with the others'. The manufacturer cannot show one customer's data to another customer's auditor. The auditors cannot accept attestations that don't carry cryptographic guarantees. The manufacturer either operates without the audit attestations the customers need or builds parallel verification systems for each customer at significant cost.
These customers exist in large numbers. They are not edge cases. Healthcare, financial services, manufacturing, government, defense, insurance, telecom, education — every regulated industry has versions of the same structural problem. Their state is not public, cannot become public, and cannot leave their perimeter. They cannot use Phase 1 because Phase 1 only proves things about state that's already publicly observable.
Phase 2 extends the proof primitive to private inputs. The customer's data stays in the customer's perimeter. The platform supplies a verification primitive that the customer can run inside their perimeter, producing a ZK proof attesting that "this computation was performed correctly on inputs satisfying the policy" — without the platform ever seeing the data.
For the hospital scenario: the platform ships a ZK circuit representing an audited diagnostic model. The hospital runs the circuit on patient records (which never leave the hospital), produces flagged-patient outputs, and provides cryptographic proof that the outputs came from the audited model on valid HIPAA-permitted inputs. The hospital learns who's at risk. The platform learns nothing about the patients. The audit trail proves the audited model was used correctly. The third-party AI capability that HIPAA prevented is now available without HIPAA being violated.
For the hedge fund scenario: the fund computes ZK proofs that "all transactions in period P satisfy regulatory policy R" without revealing the transactions or the algorithm. The regulator verifies the proof and gains compliance assurance without seeing the trades. The fund's competitive position is preserved. The regulator's oversight is satisfied. Both outcomes are good for both parties.
For the manufacturer scenario: each customer's data is processed in a separate verification context with cryptographic isolation. Auditors verify the isolation through the proof system. The manufacturer maintains one production environment instead of building parallel ones for each customer.
Three preconditions have been met that weren't met three years ago.
The cryptographic primitives are mature enough. ZK systems for arbitrary computation became practical at production scale around 2023-2024. Proving costs have continued to drop. The specific work Phase 2 requires — ZK circuits for medical record schemas, financial transaction formats, common compliance policies — is now an applied engineering problem rather than a fundamental research problem.
The regulatory frameworks are tightening. HIPAA enforcement intensified in 2024-2025 with the OCR's audit program and breach notification penalties. Sarbanes-Oxley compliance for AI-mediated decisions is being clarified. GDPR enforcement has reached the point where multi-billion-dollar fines are routine. The cost of non-compliance has crossed the threshold where customers will pay meaningfully for verification infrastructure that solves the problem structurally.
The compute substrate exists. Phase 1's HyperBEAM/AO/Arweave/Load Network architecture provides the audit posture, deterministic compute, and permanent storage that Phase 2 customers need from a vendor. Building Phase 2 on a different substrate would require rebuilding the audit infrastructure, which is exactly what Phase 1 establishes.
The customers regulated industries cannot afford to leave unserved are exactly the customers Phase 1 cannot serve, and exactly the customers whose procurement processes reward the kind of substrate Phase 1 establishes. Phase 2 is the commercial expression of the architectural choices that look like overinvestment in Phase 1 and pay off as moat in Phase 2.
Phase 2 customers do not buy verified computation as a curiosity. They buy it because a specific business problem has reached a specific threshold of cost. Naming the threshold is what makes the customer pull legible.
The bottleneck for healthcare AI deployment is not model quality. Models that beat human performance on specific diagnostic tasks have existed since 2020. The bottleneck is HIPAA. Hospitals cannot share patient records with model vendors. Vendors cannot easily ship models into hospitals' environments because deployment, support, and updating require ongoing access. The compromise — anonymized data, federated learning, on-prem deployment with limited support — produces worse models, slower update cycles, and weaker outcomes than the unbottled alternative would.
The cost of this bottleneck, measured in foregone clinical value, is substantial and growing. Healthcare AI vendors who can offer "we never see your data and yet you get the latest model" through ZK-based deployment win against vendors who require data sharing or on-prem installs. The threshold has been crossed where the engineering cost of building the ZK pathway is less than the lost-deal cost of not having it.
Banks, broker-dealers, hedge funds, asset managers — every entity in financial services produces regulatory reports continuously. The reports certify that activity satisfies specific policies (capital adequacy, suitability, AML, market abuse rules, fiduciary obligations). The certifications are made by humans reviewing samples and signing attestations.
The structural weaknesses of human-attested compliance are well-documented and increasingly costly. Sample-based review misses systematic violations. Attestations carry personal liability that pushes risk-averse behavior. The cost of compliance staff has grown 8-12% annually for a decade. Multiple major firms have paid nine-figure fines for compliance failures that a continuous proof-based system would have caught.
Verified computation on private transaction data produces a different model. Continuous proofs that policy P is satisfied across all transactions in period N. The proof either verifies or it does not. If it verifies, the firm has cryptographic evidence of compliance. If it does not, the firm has cryptographic evidence of which transactions failed which policy and can remediate. The regulator, given access to verify the proofs, has continuous assurance rather than periodic attestations.
Many valuable computations require data from multiple organizations that cannot share data with each other. Two banks suspecting joint fraud schemes cannot share customer information. Multiple hospitals tracking outbreak patterns cannot share patient records. Competing manufacturers detecting supply chain anomalies cannot share procurement data. The valuable joint computation does not happen because the participants cannot trust each other with raw data.
Verified computation on private inputs makes joint computation possible. Each participant runs the agreed-upon circuit on their own data, contributes the verified output to the joint result, and proves the contribution was correctly derived without exposing the underlying inputs. The joint computation completes. None of the participants learn anything about the others' data beyond what the agreed-upon output reveals.
This pattern — sometimes called multi-party computation or federated computation — is well-understood theoretically and increasingly practical. The blocker has historically been verification: how does each participant trust the others to run the circuit honestly. Verifiable computation through ZK proofs solves the verification problem cleanly.
GDPR, CCPA, and emerging data sovereignty frameworks impose obligations to track how customer data is used and to demonstrate that uses were consented to. The compliance overhead is substantial. Most organizations meet it through documentation systems that record what was supposed to happen, not what actually happened.
The gap between "supposed to happen" and "actually happened" is the audit risk. A verified computation pathway closes the gap structurally: the computation either ran on consented data with the audited transformation, or the proof doesn't verify. The audit becomes a check of cryptographic evidence rather than a check of self-reported documentation.
Phase 2 is not a new cryptographic primitive. It is the same ZK structure from the Project Narrative's B-500 series, applied to a relation R where the witness is private data and the public statement is the property being proven about that data.
Phase 1 services prove statements about public chain state. The witness in those proofs is the Merkle path through the state trie that demonstrates inclusion of a value. The public input is the value, the contract address, the slot, and the block. The relation R encodes "this value is what's stored at this slot in this contract at this block."
Read this as: the prover takes a public input that anyone can independently verify against chain consensus, plus a witness (the Merkle path) that proves the public input is consistent with the canonical state, and produces a proof. The verifier confirms the proof against the public input alone — no private data is involved because none of the inputs are private.
Phase 2 services prove statements about computations performed on private data. The witness is the private data itself, plus whatever auxiliary information is needed to demonstrate the computation was performed correctly. The public input is the property being attested — typically an output, a policy compliance assertion, or a statistical summary.
Read this as: the prover takes a public input describing what's being attested (which model, which policy, what output), plus a witness containing the actual private data and the trace of how the computation produced the output, and generates a proof. The verifier checks the proof against the public input. The verifier learns that some valid private input produced the claimed output through the audited model — and learns nothing about the private input itself.
The same structural properties from B-500 carry forward. Completeness: honest proofs of true statements always verify. Soundness: false statements cannot produce verifying proofs. Zero-knowledge: the verifier learns nothing about the witness.
The third property is what makes Phase 2 work commercially. The hospital's patients are protected because the verifier (auditor, regulator, downstream consumer) learns nothing about them from the proof. The hedge fund's transactions are protected because the verifier learns nothing about them from the proof. The manufacturer's customer data is protected because the verifier learns nothing about it from the proof. The math doesn't care what's being protected — the structure works for any computation that can be expressed as a relation R efficient to verify but private in its inputs.
Phase 2's most demanding workloads — ML model inference on private data — produce relations R with hundreds of millions to billions of constraints. Direct proof generation at that scale is impractical. The recursive proving structure from B-510 becomes essential.
Read this as: instead of generating one massive proof for the entire ML inference, the prover decomposes the inference into per-layer proofs (each layer of the neural network is its own proof), then composes them recursively into a single proof π' whose statement is "all the layer proofs verify and the layer outputs chain correctly." The recursive proof is much smaller than the sum of layer proofs and verifies in roughly the same time as a single proof. This is what makes ML inference at production scale economically viable.
Polyhedra Expander, identified in B-510 as Phase 1's recursive proving target, is also the right substrate for Phase 2. The architectural decision to build with recursion in mind from Phase 1 is what makes Phase 2's ML-scale workloads feasible without an architectural rewrite.
Healthcare is one of the two anchor verticals for Phase 2. The structural fit is unusually clean: HIPAA's data-handling provisions don't apply to data that never moves, and ZK-based architectures are the cleanest way to perform useful third-party computation without moving the data.
U.S. healthcare spending is roughly $4.5 trillion annually. Healthcare IT is roughly 6-8% of that — call it $300 billion. Healthcare AI specifically is a fast-growing slice, estimated at $20-30 billion currently and projected to reach $150-200 billion by 2030. The growth bottleneck is not technology, it is data access. Models that work on training data fail in deployment because deployment-stage data access is constrained by HIPAA in ways the training stage was not.
The customer base segments into three tiers worth distinguishing.
Companies building AI products for healthcare. Komodo Health, Tempus, Owkin, Path AI, Aidoc, Viz.ai, dozens of smaller specialized firms. Their commercial bottleneck is the deployment contract — the hospital's procurement and security review processes. A vendor that can offer "we never see your data and yet you get the latest model" through ZK-based deployment moves through procurement faster than vendors who require data sharing or on-prem installs.
The Phase 2 commercial relationship: the AI vendor licenses Paxiom's verification infrastructure as part of their deployment stack. The AI vendor sells their model to hospitals; Paxiom is the substrate that makes the deployment HIPAA-clean. Pricing is per-deployment or per-inference, with volume discounts negotiated in the AI vendor contract.
Large hospital networks (HCA Healthcare, Mayo Clinic, Cleveland Clinic, UCSF, Kaiser Permanente), payers (UnitedHealth, Anthem, Aetna), and integrated delivery networks. These are the entities deploying healthcare AI internally and externally. They have data, they have IT staff, they have compliance teams, and they have procurement budgets.
The Phase 2 commercial relationship: direct enterprise contracts. The health system uses Paxiom's verification infrastructure for internal AI projects (their own data scientists running models on their own data), for external vendor evaluations (verifying the vendor's claimed model performance on their data), and for cross-system collaboration (joint research initiatives with other systems where data sharing is constrained). Pricing is annual contracts, $100k-500k for mid-size systems, $500k-2M for large systems.
Pharmaceutical companies running real-world evidence studies. Medical device manufacturers tracking post-market surveillance. Public health agencies coordinating across jurisdictions. Clinical research organizations running multi-site trials. Each has specific use cases where verified computation on private data unlocks something the alternative does not.
The Phase 2 commercial relationship: project-based contracts or specialized subscriptions. Smaller average deal size than Tier 2 ($25k-150k/year typical) but higher count of customers and faster procurement.
Healthcare procurement is slow. The honest expectation: 9-18 month sales cycles for Tier 2, 3-6 months for Tier 1, 6-12 months for Tier 3. Pilots before contracts. Security reviews that take weeks. Legal redlines on contracts that take more weeks. Every gate is a real gate.
The mitigation is not speed; it is patience plus pipeline depth. Paxiom should not depend on any single Tier 2 deal closing on any specific timeline. Phase 2 economics work with 8-15 customers across tiers in the first 18 months of Phase 2 selling, not with two whales who become the entire revenue base.
The first major Tier 2 customer is the unlock for the second through tenth. Healthcare procurement is a network industry — the same compliance officers, the same procurement consultants, the same security reviewers, the same conferences. A single named reference customer (especially a known-brand academic medical center or large national system) does more for sales velocity than any amount of marketing spend.
The first reference customer is therefore an asymmetric investment. Concessions on price, contract terms, support depth, and feature roadmap that wouldn't be sustainable for the tenth customer are sustainable and correct for the first. The reference value of the first customer pays back through the next several years of customer acquisition.
The other anchor vertical. The structural fit is different from healthcare but equally clean: financial regulators want continuous evidence of compliance, financial firms want competitive privacy preserved, and ZK proofs satisfy both.
U.S. financial services compliance spend is roughly $50 billion annually across banks, broker-dealers, asset managers, insurers, and fintechs. The spend has grown 8-12% per year for over a decade and shows no sign of slowing. The growth driver is not new regulation per se but the increasing complexity and granularity of existing regulation.
The Phase 2 opportunity is not to displace existing compliance spend. It is to provide a new category of compliance infrastructure that converts attestation-based reporting into proof-based reporting. The customers who buy this are not buying it because it's cheaper — initially it is more expensive than the manual process. They buy it because it reduces risk in ways the manual process cannot.
Specialized firms with substantial regulatory exposure relative to their headcount. Citadel, Two Sigma, Renaissance, DE Shaw at the top end; thousands of smaller firms below. Their compliance need is specific: prove that algorithmic trading satisfies regulatory constraints (best execution, market manipulation rules, position limits, suitability) without exposing the algorithm.
The Phase 2 commercial relationship: subscription-based access to compliance proof generation. The firm runs the proofs internally on their own data; Paxiom supplies the verification infrastructure and the audited circuit library. Pricing is annual, $200k-2M depending on firm size and compliance scope.
Larger institutions with broader compliance scope. Banks (regional through national), broker-dealers, custody banks, prime brokers. Their compliance need spans more regulations (AML, KYC, suitability, capital, fiduciary, disclosure) and applies across more business lines.
The Phase 2 commercial relationship: enterprise contracts with multiple business units. The bank uses Paxiom's verification infrastructure for AML transaction monitoring, suitability verification for advisory relationships, capital adequacy reporting, fraud pattern detection across customer cohorts, and inter-bank verification for joint operations. Pricing is annual enterprise contracts, $1-10M for mid-size banks, $10-50M for major banks.
Large pools of regulatory complexity in different shapes. Asset managers (BlackRock, Vanguard, Fidelity, plus thousands of mid-size firms) have suitability, fiduciary, and disclosure obligations. Insurers have actuarial reserve, claims handling, and consumer protection obligations. Both verticals have multi-decade trends toward more granular regulatory oversight.
The Phase 2 commercial relationship: similar shape to Tier 2 but different specifics. Multi-year contracts, multiple business units, integration with existing compliance technology stacks.
Financial firms' technical evaluation is more sophisticated than healthcare's. The buyers in financial services include people who can read cryptographic primitives directly, understand the differences between proving systems, and probe the security model with depth that most healthcare buyers cannot match.
This cuts both ways. The Paxiom architecture's actual depth — substrate decisions, post-quantum trajectory, audit posture — matters more in financial services because financial buyers can evaluate it directly. The buyers reward genuine architectural quality with faster procurement and better contract terms. They also punish architectural shortcuts with rejection.
The mitigation is to be ready for the technical depth of evaluation. Documentation that a working cryptographer can verify rather than marketing copy. Reference implementations that financial engineering teams can run. Performance benchmarks that hold up to scrutiny. The construction-document register Paxiom is using is exactly the right register for these buyers.
Procurement cycles in financial services are typically faster than healthcare for similarly-sized deals. The buyers have more authority to make decisions on shorter timelines. The compliance reviews are more rigorous but more predictable.
This means Phase 2 selling can probably lead with financial services and follow with healthcare. The earlier financial wins establish track record that helps healthcare procurement; healthcare's slower cycles benefit from accumulated evidence that financial services can produce sooner.
Healthcare and financial services are the anchor verticals because their regulatory pressure and procurement budgets are largest. Several adjacent categories matter less in Phase 2 but more in Phase 3-4 and are worth flagging now so the architecture stays compatible.
Federal agencies, defense contractors, intelligence community vendors, and state/local governments handle classified and sensitive data with strict compliance overlays (FedRAMP, FISMA, ITAR, CMMC, FERPA in education contexts). The structural fit for ZK-based verification is good. The procurement reality is brutal — multi-year cycles, security clearances, contracting overhead that often exceeds the value of the contract for smaller vendors.
Phase 2 strategy: do not actively pursue federal contracting in Phase 2. The bandwidth cost dominates the revenue benefit at the company's stage. Phase 3-4 is when government contracting becomes worth pursuing through partnership channels (federal contractors who incorporate Paxiom into their stacks) rather than direct sales.
Insurers have actuarial models, claims handling decisions, and underwriting algorithms that face increasing regulatory scrutiny. Privacy obligations under state laws and emerging federal frameworks add to the compliance overhead. Verifiable computation on customer data — for fraud detection, claims adjudication, premium calculation, reinsurance verification — has clean fit.
Phase 2 strategy: insurance is treated similarly to healthcare in approach. The procurement cycles are slower than financial services but the deal sizes and customer stickiness are real. A single major insurer relationship, if won, justifies the investment.
Telecom operators handle metadata about every call, message, and data session. Network operators handle traffic patterns. Infrastructure operators handle operational telemetry. All of these contain sensitive information that the operators want to use commercially (analytics, capacity planning, network optimization) but cannot expose without privacy or competitive harm.
Phase 2 strategy: not actively pursued in Phase 2. The use cases are real but the procurement cycles are slow and the customers are fewer. Phase 4 is the natural home for telecom and infrastructure verticals.
Companies face increasing pressure to report on environmental, social, and governance metrics with verifiable evidence. Greenwashing scandals have raised the cost of unverified claims. Major asset managers have committed to investing only in companies with credible ESG verification. Verifiable computation on operational data — emissions, supply chain practices, labor conditions — has direct fit.
Phase 2 strategy: not pursued directly. The category is interesting but the buyers are not yet sophisticated enough about cryptographic verification to drive procurement. Phase 4-5 work.
Universities and research institutions handle student data (FERPA), human subjects research data (IRB protocols), and shared research datasets that cannot be commingled across institutions. Multi-institution research collaborations face many of the same data-sharing constraints as healthcare and financial services.
Phase 2 strategy: not pursued for revenue. The budgets are smaller than commercial verticals. The strategic value is reference and credibility — partnering with one or two prominent research institutions on a high-visibility verification project produces credibility downstream that pure commercial relationships cannot. Phase 2 may include opportunistic education partnerships if the right ones present themselves.
Phase 2 focuses on the two verticals where the customer pull is strongest and the procurement is most economically viable. Healthcare and financial services. The other verticals are real opportunities but they belong to Phase 3-4 selling, not Phase 2 launch. Trying to address all of them simultaneously dilutes the focused execution that Phase 2 requires.
The substrate decisions in Phase 1 — the ones that look like overinvestment when Phase 1 is the only thing being built — are exactly what Phase 2 customers' procurement processes evaluate.
Phase 2 does not require building a new substrate. It requires building Phase-2-specific tooling on top of the substrate Phase 1 establishes. Several Phase 1 architectural choices are load-bearing for Phase 2 in ways that won't be obvious until the first major Phase 2 procurement evaluation.
Phase 1 writes every service transaction to AO/Arweave permanently. The audit posture is structural rather than retrofit. Phase 2 customers — particularly in regulated industries — have audit retention requirements that span years to decades. HIPAA requires six years; SEC requires three to seven; SOX requires seven; NARA standards for federal contractors can require permanent retention.
A vendor whose audit trail is structurally permanent has a procurement-friendly answer to retention requirements. A vendor whose audit trail is retention-policy-dependent has to demonstrate the retention policy works as designed and prove it has worked historically. The first answer is much shorter and much more credible. Phase 1's substrate decision pays off here.
Phase 1's HyperBEAM device model produces deterministic computation that can be replayed and verified independently. The same inputs produce the same outputs byte-for-byte. This property matters enormously for Phase 2 because regulated customers need to be able to reproduce computations during audits. A non-deterministic compute layer cannot be reproduced; a deterministic one can.
The deterministic property also enables the trust-attested computation patterns that some Phase 2 customers will require. TEE-attested execution combined with deterministic compute means the customer can verify two independent properties: that the computation ran in trusted hardware (TEE attestation) and that the computation produced the correct output for the inputs (determinism + ZK proof). Either property alone is weaker than both together.
Phase 1's public-chain inputs are verified rather than merely fetched. Live witnesses can come from an archive node, but they are checked against sync-committee-trusted Ethereum headers, and the proof packets/evidence trail are written to Load Network/Arweave for replay. The trust assumption moves from "the RPC provider is honest" to "the verifier accepts only data consistent with Ethereum consensus and the permanent evidence trail."
For Phase 2, the equivalent property is that any data the platform pulls from public sources during private-data computation comes through verifiable channels. This matters for compliance computations that combine private customer data with public reference data (interest rates, regulatory thresholds, market prices). The reference data must be verified not just self-attested. Phase 1's discipline carries forward as "no unverifiable claims," not as a purity test about which transport supplied the data.
Phase 1's identity primitive — signed responses with a published key, forward-compatible with ERC-8004 — provides the substrate for the more sophisticated identity binding that Phase 2 customers will require. Phase 2 will likely add specific KYA primitives for healthcare (provider identity verification, patient consent attestation) and financial services (firm identity, regulatory entity attestation). These additions build on the Phase 1 primitive rather than replacing it.
Phase 1's architectural commitment to keep the proving system pluggable means Phase 2 can use whatever proving system is most efficient for ML-scale workloads without an architectural rewrite. The Phase 1 services use SP1, RISC Zero, and Polyhedra Expander as appropriate. Phase 2 may add EZKL or similar specialized ML-proving systems. The platform's service layer doesn't change; the proving backend swaps per service.
This is a non-obvious benefit. The temptation in early-stage architecture is to commit to one proving system and optimize for it. Doing so makes Phase 1 simpler but makes Phase 2 harder, sometimes prohibitively so. Phase 1's pluggability pays off when Phase 2 demands different proving characteristics that the original choice doesn't satisfy.
The least technical and most important Phase 1 contribution to Phase 2 is operational track record. Phase 2 customers do not buy from vendors with zero operational history regardless of architectural quality. The 12-18 months of Phase 1 operations that precede Phase 2 selling are the primary credibility input to every Phase 2 procurement evaluation.
This is the most-easy-to-undervalue Phase 1 deliverable. Every uneventful day of Phase 1 operations adds to the track record that Phase 2 selling depends on. A spectacular Phase 1 incident — even one that is technically well-handled — sets the Phase 2 timeline back by months. Operational discipline in Phase 1 is the highest-leverage investment in Phase 2 success.
Procurement evaluations in regulated industries have specific compliance gates. None are insurmountable; all take real time and money to clear. The work to clear them is part of Phase 2 build cost rather than something the platform can shortcut.
The standard auditing framework for B2B SaaS in any regulated context. SOC 2 Type II requires demonstrating that defined controls operate effectively over a period of time (typically 6-12 months). Without SOC 2 Type II, the platform fails procurement at most Tier 2 customers and many Tier 1.
The work involves selecting an auditor (Big 4 firms, dedicated SOC firms like Schellman or Coalfire), defining the control framework (Trust Service Criteria for Security at minimum, often Confidentiality and Availability as well), implementing the controls in the platform's operations (the O-series Operations Runbook is most of the work), running the controls for the audit window, and undergoing the audit itself.
Realistic timeline: 9-15 months from start to a clean Type II report. Cost: $50-200k for the audit plus internal staff time for control implementation. The audit becomes annually recurring once established.
Recommendation: begin SOC 2 Type II preparation in Phase 1, late stage. The control framework is mostly already in place via the operations runbook discipline; the formal audit work is selecting an auditor, scoping the audit, and running through one full cycle. Achieving Type II readiness coincident with Phase 2 launch is realistic if started 12-15 months in advance.
Required for any healthcare customer engagement where Paxiom touches Protected Health Information (PHI), even if the touch is "verifying without seeing." HIPAA's definition of "use" of PHI is broad enough to require a BAA in most realistic Phase 2 healthcare engagements.
The BAA itself is a contractual document with relatively standard terms. The harder work is achieving the operational posture that allows Paxiom to sign a BAA credibly. Encryption requirements, access controls, audit logging, breach notification procedures, employee training, business continuity planning. Many of these overlap with SOC 2 controls but a few are HIPAA-specific.
Realistic timeline: 3-6 months from starting BAA preparation to BAA-signing-ready. Cost: $20-50k for legal review and policy drafting plus internal staff time.
Recommendation: begin BAA preparation 6 months before the first healthcare prospect. The work cannot be rushed when a customer asks; it must already be done.
Healthcare-specific certification framework that some larger health systems require above and beyond HIPAA BAA. More rigorous than SOC 2 in healthcare-specific dimensions. Not strictly required for healthcare engagement but makes procurement smoother at certain customers.
Realistic timeline: 12-18 months. Cost: $100-300k. Recommendation: defer to Phase 2 mid-stage based on whether specific customer demand justifies the investment. Do not commit to HITRUST in Phase 2 launch budget.
Different framework than healthcare. The relevant standards are SOC 2 (already covered), ISO 27001 (similar scope to SOC 2 but international), and specific regulatory frameworks like NYDFS Cybersecurity Regulation for New York-regulated entities, FINRA WSP requirements for broker-dealer customers, and FedRAMP for federal financial customers.
Recommendation: start with SOC 2 (covers most ground), add ISO 27001 if European customers materialize, defer the more specific regulatory frameworks to direct customer demand. Don't preemptively pursue NYDFS or FedRAMP without a specific customer requirement.
Required by most enterprise procurement processes. Annual third-party penetration test, ideally by a firm the customer recognizes (Bishop Fox, NCC Group, Trail of Bits for crypto-specific work, smaller firms for general application security). Findings remediation. Re-testing of remediated findings. Security questionnaire responses for procurement.
Cost: $30-80k per annual test cycle. Recommendation: budget for an annual pentest beginning Phase 1 mid-stage so the first Type II audit and the first major Phase 2 procurement both have current pentest results to reference.
Compliance infrastructure for Phase 2 launch is a real budget item. Realistic range: $150-400k in Year 1 of preparation, $100-250k annually thereafter for maintenance audits, plus internal staff time. The investment is non-negotiable for Phase 2 customer access; without it, the platform's commercial reach is capped at customers who don't require it, which is mostly customers Phase 1 already reaches.
Phase 1 is product-led: agents discover the platform through metadata in registries and transact through x402 without human involvement on either side. Phase 2 is sales-led: humans talk to humans, contracts get redlined, procurement processes take months, and integrations are bespoke. The motion is fundamentally different.
Phase 2 sales is conventional B2B enterprise selling, with the specific shape that regulated industries demand.
Lead generation comes from referrals, conference presence, technical content, and direct outbound to specific named accounts. The quality of Paxiom's documentation set — particularly the Project Narrative and the Phase 2 Vision Brief — matters here because regulated industry buyers research vendors before they accept calls, and the documentation either passes the research filter or it doesn't.
Discovery conversations focus on the customer's specific compliance pain. Each Phase 2 customer has a particular reason they're considering verified compute infrastructure: an audit finding, a new regulation, a vendor evaluation that flagged a gap, a competitive pressure to deploy AI capabilities the privacy posture currently prevents. The discovery work is identifying which specific pain anchors the deal.
Solution shaping is technical-led but commercial-influenced. The Paxiom team needs to demonstrate that the platform's capabilities map to the customer's specific use case, often involving custom proof-of-concept work. The procurement process simultaneously evaluates contract terms, security posture, support commitments, and pricing.
Procurement and contracting is lawyer-heavy and slow. Master services agreements take 4-12 weeks to negotiate. SOWs for specific engagements take additional weeks. Security questionnaires require dedicated response time. Integration timelines are negotiated alongside contract terms.
Implementation and go-live is typically 60-180 days from contract signature, longer for larger customers. Many Phase 2 deals will have phased rollouts: pilot deployment, expanded deployment, full production.
From first conversation to contract signature: typically 6-12 months for Tier 1, 9-18 months for Tier 2, varies widely for Tier 3. The cycle time cannot be compressed by working harder; it is gated by procurement processes that are external to the platform's control.
The commercial implication is that Phase 2 revenue ramp is back-loaded. The first six months of Phase 2 selling produces almost no revenue. Months 7-12 produces the first contracts but at small dollar amounts due to pilot pricing. Year 2 of Phase 2 selling is when the contracts signed in Year 1 expand to production scope.
The founder cannot do all of Phase 2 selling solo and also build the platform. The first sales hire is a real Phase 2 prerequisite, with specific characteristics worth being explicit about.
Profile: enterprise sales background in regulated industries (healthcare or financial services specifically), 7-15 years of experience, comfortable with technical depth but not a technical specialist, network in target customer accounts, comfortable with long sales cycles, willing to operate with the founder rather than independently. Compensation likely $200-350k OTE structure depending on geography and seniority. Hire timing: 6-9 months before first major Phase 2 customer prospect should be realistic, which means 6-9 months before Phase 2 launch.
The first sales hire is high-leverage and high-risk. Wrong hire wastes 12-18 months and burns the candidate pool. Right hire transforms Phase 2 economics. The founder's instinct to do this hire personally rather than delegate is correct.
Direct sales is the primary motion. Channel sales (through systems integrators, consultancies, larger vendors who incorporate Paxiom into their stack) is a secondary motion that may emerge organically but should not be planned for in Phase 2.
Specific partnership opportunities to watch: the Big Four consulting firms (Accenture, Deloitte, EY, KPMG) all have practices that consult to healthcare and financial services on technology adoption. They are typically late to recommend new categories but become important once a category is established. Phase 2 should not pursue these partnerships actively but should be ready when one of them initiates the conversation, which probably happens in Year 2-3 of Phase 2.
Conventional B2B marketing for regulated industries: thought leadership content, conference presence, customer reference programs, analyst relations. The construction-document register and the public drawing set are the foundational thought leadership artifacts; Phase 2 marketing builds on them with vertical-specific case studies, white papers on specific compliance use cases, and conference talks at relevant events (HIMSS for healthcare, RSA for financial services, several others).
The marketing budget is real but smaller than the sales budget. Phase 2 marketing investment likely $50-150k in Year 1 of selling, growing in subsequent years. The leverage points are reference customer case studies and analyst relations rather than broad-funnel lead generation.
Phase 1 pricing is per-call x402 economics measured in cents to dollars. Phase 2 pricing is enterprise B2B economics measured in tens to hundreds of thousands of dollars per customer per year. The pricing model is structurally different.
Phase 2 prices in three tiers, with custom enterprise pricing above the published tiers. The tiers are named for clarity; the actual customer experience is bespoke for any deal above the Pilot tier.
| Tier | Customer Profile | Annual | Setup | Includes |
|---|---|---|---|---|
| Pilot | Tier 3 customers; project-based engagements; reference deployments | $25-75k | Waived | Single use case, one circuit, basic support, 6-12 month term |
| Production | Tier 2 mid-market; healthcare AI vendors; mid-size financial firms | $100-500k | $25-75k | Multiple use cases, custom circuits, named support, BAA, annual SOC 2 evidence, 12-36 month term |
| Enterprise | Tier 2 large; major banks; large health systems; payers | $500k-5M | $100-300k | Multiple business units, custom integration, dedicated support engineering, SLA, full compliance package, 24-60 month term |
| Custom | Tier 2 strategic; Tier 3 government; multi-region or multi-entity engagements | $5M+ | Custom | Negotiated scope; may include exclusivity terms, custom development, on-prem components, multi-year roadmap commitments |
Several factors push pricing up the tier structure for any specific customer.
Number of distinct use cases. Each use case typically requires its own ZK circuit, its own integration work, and its own ongoing support. A customer with three use cases pays more than a customer with one, not just because they consume more service but because the platform's costs to serve them are genuinely higher.
Regulatory scope. A customer requiring HIPAA BAA pays more than a customer requiring only a standard MSA. A customer requiring HITRUST or FedRAMP pays more again. Each layer of regulatory specificity requires platform-side investment that customers in lower-regulatory tiers don't need.
Integration depth. A customer where the platform integrates with multiple internal systems (electronic health records, trading systems, compliance management platforms) pays more than a customer with simpler integration. Integration depth correlates with switching cost; customers expect to pay for the deeper integration.
Volume of computations. Per-call pricing within enterprise contracts is often included as bands rather than charged separately, but customers with very high computation volumes pay more for the band that covers their volume.
Support level. Standard support included with Production tier; named support engineering with Enterprise tier; dedicated support team with Custom tier. The differentiation reflects real cost-to-serve.
A realistic Phase 2 customer mix at month 24 of Phase 2 (so ~36 months from Phase 1 launch):
Aggregate realistic case at 36 months from Phase 1 launch: $3-8M ARR, with Year 3 of Phase 2 (~48 months from Phase 1 launch) potentially reaching $8-20M ARR depending on how Year 1 contracts expand and how the customer count grows.
These are realistic-case numbers. Best case is meaningfully higher if multiple Custom-tier deals close. Worst case is meaningfully lower if procurement cycles slip or competitive losses concentrate in early target accounts.
The aggregate Year 1 of Phase 2 selling probably produces $500k-2M in revenue. That's not a lot relative to the cost of Phase 2 build (compliance infrastructure, first sales hire, product development for vertical-specific tooling — easily $1.5-3M for the first year). Phase 2 Year 1 may run cash-flow negative.
The economics work because Year 2 onwards expands sharply. Customers signed in Year 1 expand scope in Year 2 and 3. New customer acquisition compounds the existing base. Reference customer effects accelerate sales velocity. By Year 3 of Phase 2 selling, the run rate covers Phase 2 operating costs with meaningful margin and contributes to overall company economics.
The capital implication is that Phase 2 likely requires either external capital between Phase 1 and Phase 2 launch, or sufficient Phase 1 surplus to fund the Phase 2 ramp from internal cash. The honest expectation is the former is more likely than the latter for a single founder.
Phase 2 has more failure modes than Phase 1. The customer base is harder to reach, the build is more demanding, the capital requirements are higher, and the competitive landscape is denser. Naming the specific risks is the first step to defending against them.
Phase 2's most demanding workloads — ML inference verification — push recursive proving to scales that haven't been demonstrated at production volumes. Current state-of-the-art recursive proving systems handle inference verification on smaller models (parameter counts in millions to low hundreds of millions). Production healthcare AI models often exceed a billion parameters. Proving inference verification at that scale economically is an open engineering problem.
Mitigation: Phase 2 customers in healthcare can typically work with mid-size models that fit current proving capabilities. Large-model verification is a Phase 3 problem. Phase 2 explicitly scopes to model sizes where recursive proving is mature. Customers wanting larger-model verification get put on the roadmap rather than promised in Phase 2.
EZKL, Modulus Labs, Giza, and similar specialized verified-inference providers may extend their offerings to compete directly with Phase 2's verified inference category. They have head-start expertise on ML-circuit-specific optimization that general-purpose verified compute providers don't have.
Mitigation: Phase 2's competitive position is not "best ML proving" — that's a Phase 3 question. Phase 2's position is "verified compute for regulated industries with audit infrastructure, compliance posture, and operational track record." The architectural differentiation — verifiable public inputs, AO/Arweave audit, permanent evidence, compliance-native operations — is hard for the specialized players to retrofit. The customer relationships in regulated industries are slow to win but harder to lose once won.
Microsoft, Google, AWS could all build verified compute offerings as part of their existing enterprise cloud businesses. Their distribution advantage over a small company is substantial. The category is small enough today that they don't bother; if it grows fast, they will pay attention.
Mitigation: large players entering a category typically do so 3-5 years after the category is established. Phase 2 is the establishment work. By the time large players are interested, Paxiom's accumulated customer relationships and architectural depth are real moats. The risk is real but on a longer timeline than Phase 2's commercial-success window.
Enterprise B2B sales cycles slip routinely. A customer who looks 80% likely to close in three months may take twelve months and may not close at all. The aggregate revenue picture depends on a portfolio of opportunities; individual opportunity outcomes are unpredictable.
Mitigation: pipeline depth. Phase 2 economics work if the platform has 20-40 active opportunities at various stages, not if it has 5 specific deals. The first sales hire's primary role in Year 1 of Phase 2 is building the pipeline, not closing the deals. Closing comes from pipeline maturation; pipeline comes from sustained outbound and inbound flow.
HIPAA, SEC rules, and adjacent regulatory frameworks evolve. A regulatory change that disadvantages ZK-based compliance (unlikely but possible) would damage the Phase 2 thesis. A regulatory change that advantages ZK-based compliance (more likely given current trajectory) would accelerate it.
Mitigation: track regulatory developments through industry associations (HIMSS, FINRA, etc.), engage with relevant working groups when they form, position the platform's capabilities to align with directional changes regulators signal. Don't bet on specific regulatory outcomes; build for the underlying trends regardless of specific framework changes.
Phase 2 likely requires capital that Phase 1 surplus cannot cover. Either external capital (institutional or strategic) or internal patience longer than realistic for a single-founder runway. The timing of Phase 2 launch is partly determined by the capital availability rather than by build readiness alone.
Mitigation: begin capital conversations 12-18 months before Phase 2 launch. The drawing set is substantial credibility infrastructure for these conversations. The realistic check size for the right capital is $3-10M from a sophisticated investor who understands the agent economy and the regulated-industry verification thesis. Smaller institutional rounds or strategic capital from a partner with vertical-specific reach are viable alternatives.
Phase 1 is a heavy build for one person; Phase 2 is heavier. The founder cannot personally execute Phase 1 operations, Phase 2 build, Phase 2 selling, compliance infrastructure preparation, and capital raising simultaneously. Some of these get delegated. Wrong delegation choices can damage the platform's substrate.
Mitigation: hire the right first-three people, in order. First sales hire (Phase 2 prerequisite). First engineering hire (Phase 2 build). First operations hire (Phase 1 operations, freeing the founder for Phase 2). The order matters because the dependencies cascade — sales without product to sell is wasted; product without operations to support is fragile; operations without revenue to fund them is doomed.
Several Phase 2 questions are genuinely open and worth being explicit about.
None of these need to be resolved during Phase 1. All of them need to be resolved before Phase 2 selling begins in earnest.
Phase 2 launch is a gate, not a date. Specific conditions must be true before Phase 2 selling begins. Trying to launch Phase 2 before the gates are clear damages the substrate Phase 2 depends on.
The Phase 1 services must be operationally credible at scale. The honest threshold is roughly 12-18 months of all-five-services running with measured uptime above 99.5%, transaction volumes that demonstrate genuine demand (not just demo traffic), and a clean incident history with documented post-incident learning.
The audit trail through AO/Arweave must be demonstrably continuous and cryptographically valid. A Phase 2 procurement evaluation will spot-check the audit trail; a gap or anomaly invalidates the marketing claim.
The operations runbook procedures must have been actually exercised, not just documented. Several incidents resolved through O-series procedures, with post-incident write-ups available, build the operational track record that Phase 2 procurement values.
SOC 2 Type II report in hand, with the audit window covering the most recent 12 months. Without this, most Tier 2 procurement evaluations halt at the security review.
HIPAA BAA template ready, signed by counsel as ready-to-execute, with the operational backing (encryption posture, access controls, breach procedures) in place. Without these, healthcare engagement is blocked.
Annual third-party penetration test completed within the last 12 months, with findings remediated and remediation verified. Procurement evaluations request the most recent pentest report.
Privacy and security policies documented at the level of detail enterprise procurement expects. Privacy policy. Acceptable use policy. Data processing agreement. Information security policy. Business continuity policy. Vendor management policy. Each is a real document with real content, not boilerplate.
First sales hire on board and ramped (typically 90-120 days from start to productive). Without a dedicated sales motion, Phase 2 selling does not happen at the velocity Phase 2 economics require.
Legal entity formed (Delaware C-corp likely), with bank accounts, payroll infrastructure, and basic tax compliance in place. A handshake LLC is not adequate for $500k+ enterprise contracts.
Master Services Agreement template developed and reviewed by counsel, with experience executing it on at least a Pilot-tier deal. The first $1M+ contract is not the time to discover gaps in the contract template.
Pipeline of qualified prospects in active conversation, with realistic 30-90 day next steps. Phase 2 selling cannot start from zero pipeline; the pipeline development work happens in Phase 1 late stage.
Recursive proving stack ready for Phase 2 workload sizes. The integration of Polyhedra Expander or equivalent recursive system, tested on at least one realistic Phase 2 use case (e.g., a simple medical AI inference verification at modest scale).
Vertical-specific tooling for at least one vertical. ZK circuits for FHIR healthcare data schemas, or ZK circuits for common financial transaction formats. Building both in parallel is too much; one of them in usable form is the launch threshold.
Compliance documentation packages drafted for the lead vertical. Healthcare-specific compliance overview, financial-specific compliance overview, depending on which leads.
The gates are not all at the same stage of completion. Some clear early in Phase 1 operations; others clear at Phase 2 launch. The realistic sequence:
This is a 24-30 month bridge from Phase 1 launch to Phase 2 launch. It is not the dramatic ramp founders often imagine. The bridge is the work that makes Phase 2 a credible commercial offering when it launches; trying to compress it generally fails.
Phase 3 is verified AI inference at scale. The bridge from Phase 2 to Phase 3 is the natural one — Phase 2 establishes private-data primitives, Phase 3 layers full ML inference verification on top, using the same customer relationships and the same compliance posture.
Phase 2's private data compute handles inference verification at small to mid scale and other private-data computations of moderate complexity. Phase 3 extends to large-model inference verification — the billion-parameter and beyond regime — and adds inference-specific tooling that Phase 2 doesn't carry.
The technical work is recursive proving at much larger scale, specialized circuit optimization for common ML operations (matrix multiplication, attention, normalization), and integration with the major ML frameworks (PyTorch, TensorFlow, Hugging Face) so customers can verify inference on models trained in those frameworks without manual circuit construction.
The commercial work is extending existing Phase 2 customer relationships into ML-heavy use cases, plus new customer acquisition in segments where ML inference verification is the primary use case (Tier 1 healthcare AI vendors, fintech firms running ML-driven trading or risk models, content moderation services with regulatory exposure).
Many Phase 2 customers are natural Phase 3 customers. The healthcare AI vendor running inference verification on a 100M-parameter model in Phase 2 will want to verify their next-generation 1B-parameter model in Phase 3. The financial services customer using compliance proofs in Phase 2 will want to verify their ML-driven risk models in Phase 3. The procurement gate has already been cleared; the integration is already in place. Adding new use cases on existing customer relationships is much faster than acquiring new customers.
This is the structural advantage of the phased approach. Phase 3's customer acquisition cost is much lower than it would be for a Phase 1-equivalent cold start, because most Phase 3 customers already know the platform from Phase 2.
Phase 3 enters a category — verified AI inference — where specialized players have been working for years. EZKL, Modulus Labs, Giza, Inference Labs each have specific expertise. Phase 3's competitive position is not "best ML proving"; it is "verified ML inference for the regulated industries we already serve, with the audit posture and compliance infrastructure they require."
This is a focused position. Specialized verified-inference players who don't have the regulated-industry compliance work cannot easily reach those customers. Cloud platforms who build verified inference don't have the architectural depth that compliance-mature buyers require. Paxiom's Phase 2 work creates the position that Phase 3 capabilities populate.
Phase 3 launches realistically 24-36 months after Phase 2 launches, which is 48-66 months after Phase 1 launches. The timeline can be compressed if Phase 2 wins big customers fast and the ML inference work matures faster than expected; it can extend if Phase 2 takes longer to ramp than the realistic case suggests.
Phase 3 vision will be its own brief when Phase 2 is a year or two into operations. This document is the Phase 2 vision; Phase 3 vision should not be written until Phase 2 reality is informing it.
Phase 4 (IoT and telemetry) and Phase 5 (post-quantum migration) follow Phase 3 in the trajectory. Each builds on the substrate that prior phases establish. Each has its own customer base, its own commercial motion, its own pricing structure. None of them need to be planned in detail in this document; the Project Narrative B-1000 sketches them at the level of detail that's currently appropriate.
The discipline is to stay focused on Phase 2 while keeping the architecture compatible with later phases. Architectural decisions made in Phase 2 that work for Phase 2 specifically but break Phase 3 enablement are bad decisions. The pluggable proving stack, the audit posture, the compliance infrastructure — all are Phase 2 work that pays forward into Phase 3-5. Maintaining this discipline is what makes the trajectory durable rather than a sequence of disconnected commercial bets.
A vision brief is a document for thinking. It is the planning record that a future Phase 2 build will reference, the commercial framing that capital conversations will work from, and the public artifact that signals to potential customers and partners what the platform is becoming.
B-Series Project Narrative. The broader project context. Phase 2 is one of five phases in the trajectory. The B-700 series in the narrative covers the same territory as this brief at lower resolution; this brief is the higher-resolution Phase 2-specific treatment. Open the Project Narrative.
A-Series Phase 1 Blueprint. The current phase under construction. Phase 2 builds on Phase 1's substrate; Phase 1 should be operational at credible scale before Phase 2 launches. Open the Phase 1 Blueprint.
R-Series Build Map. The strategic positioning across all phases. Useful for understanding where Phase 2 sits in the longer arc. Open the Build Map.
O-Series Operations Runbook. The operational substrate that supports Phase 2 selling. Most of the SOC 2 control framework is already documented here. Open the Operations Runbook.
E-Series Key Custody & Identity. Phase 2's identity primitives extend the Phase 1 architecture documented here. Open the Key Custody Blueprint.
Several Phase 2 documents will be needed when Phase 2 build begins, but are not part of this brief.
Rev. A — 2026.04.30. Initial issue. Six sections covering the Phase 2 thesis, the verticals (healthcare, financial services, others), architectural foundations, commercial motion, risks and gates, and the connection to Phase 3.
Subsequent revisions will likely happen as Phase 1 operations produce data that informs Phase 2 planning, and as capital conversations refine the financial picture. Rev. B is expected approximately 12 months from this issue, with substantial updates to F-410 (pricing) and F-510 (gate timing) based on observed Phase 1 reality.
Phase 2 is not Phase 1. The motion is different, the customers are different, the timeline is longer, and the capital requirements are higher. Treating Phase 2 as "Phase 1 but bigger" is the most predictable way to fail Phase 2.
The work this brief tries to do is name what's actually different so that the build for Phase 2, when it begins, is built for the reality of Phase 2 rather than a generalization of Phase 1. Customer access in regulated industries is the bottleneck. Compliance infrastructure is the cost. Sales velocity is the variable. Architectural depth is the moat. Operational track record is the credibility input. None of these are Phase 1 concerns at the same scale; all of them are Phase 2 concerns at a scale that demands deliberate planning.
This document is the planning. The build comes later.