08 of 09

The roadmap

~7 min read

Each phase deepens one face at a time.

The engine has five faces. Each phase extends one of them further out into the world — Phase 1 proved the architecture; Phase 2 hardens audit + factory + transfer with the first paying pilots; Phase 3 unlocks the cross-organisational corpus; Phase 4 makes the regulatory rail the global default. Capital, hires, and partnerships scoped to the phase, not the vision-state.

Phase 1 — NowQ2 2026 · complete · v1.1 with Phase R shipped May 12✓ shipped

The substrate works on itself — runtime-AI containment shipped at v1.1

Deterministic core + runtime-AI containment shipped. v1.0 stable lock landed May 12 2026 (schema-locked surface, additive-only changes thereafter). Same-day, v1.1 Phase R completed: the architectural commitment 'AI as building material, not arbiter' extended from build-time (intent → ProductSpec) to runtime (every LLM call a substrate-emitted product makes is bounded by a closed-enum schema + §67 reviewer gate + deterministic fallback + signed L12 receipt). Phase R sub-phases: R0 RuntimeAISpec + L12 chain + runtime SDK; R1 the 50th generator emitting typed client code; R2a verify.mjs walking L12 in 50 KB plain JS; R2b three new autoplay strategies catching LLM-SDK bypass attempts in CI; R3 three live reference deployments (paysafe / cliniclens / civicgate) each with a real signed L12 chain visible on the public surface; R4 multi-tenant tenantId + per-tenant verification for hosted Author deployments; R5 federated cross-substrate convergence via signed commitments — industry consortia can share rate posture on shared specs without exchanging entries. The cryptographic chain extends from L1–L11 to L1–L12. 141 runtime-AI tests across 11 suites, all green. Existing 99 tests still passing — Phase R is fully additive. Engineering is no longer the bottleneck at any layer.

Phase gate

v1.1 Phase R complete May 12 2026: runtime-AI containment is no longer a roadmap claim. Every commercial scenario the AI-flagship pitch claims is now a working primitive backed by tests — self-hosted (R0-R3), hosted Author with paying tenants (R4), industry consortium with cross-org evidence (R5). Three live regulator-verifiable reference deployments at /products/{paysafe|cliniclens|civicgate}/runtime-ai.

Phase 2 — ImmediateQ3 2026 onward · the only remaining bottleneck● in progress

First paying pilot operator · single critical path

With v1.1 Phase R shipped, Phase 2 is the SINGLE remaining gate to commercial validation. The substrate is in pre-Phase-2 stealth — public surface is the explainer site plus four signed, regulator-verifiable artifacts: state.json + runnable audit bundle + three L12 runtime-AI receipt chains. Source + 45-ADR access is NDA-gated. Targets: EU regulated organisations with a stuck AI mandate where runtime-AI containment is the unlock — fintech (PSD3 SCA + DORA decisioning), healthcare (HIPAA + MDR + EU AI Act Annex III §5), govtech (eIDAS + GDPR Art. 22 + AI Act §5(a)) — all three reference deployments already live and pointable at /products/{paysafe|cliniclens|civicgate}/runtime-ai. The full v0.14 RegulatorySpec → ProductSpec derivation (7 frameworks) + §65.1 CWE projections + Phase R runtime-AI containment + regulator handoff package are immediately actionable. Pilot instrumentation (v0.13) signs pre-registered falsifiable hypotheses under L1 before the pilot starts + counterfactual + compounding-coefficient measurement — once an operator engages, evidence not anecdote. Once first paying pilot validates, public source release becomes 'what serves Moat A best' rather than 'are we ready'.

Phase gate

Gate clears when first paying pilot operator runs Promethean in production CI for 60 consecutive days without unblocked critical findings. Pilot instrumentation (v0.13) provides signed pass/fail verdicts against pre-registered hypotheses at T+90d.

Phase 3 — Near-term2027 · 12 months · ecosystem activation○ planned

Federated substrates + cross-organisational corpus contribution

v1.0 is shipped (May 12 2026, ahead of original schedule). Phase 3 is now about activating the federated-substrates protocol (v0.17): multiple operators each run their own substrate instance under their own L1 key; substrates exchange signed signature claims WITHOUT exchanging corpora; cross-substrate convergence becomes the empirical surface that Moat A depends on. Contribution-governance review queue (already shipped) handles per-operator-finding admission; license-respecting, attributed, reviewer-signed before merge. 5–10 paying pilot operators. Public substrate dashboard. Producer-side end-to-end via the runtime evidence loop (v0.11). Operator handbook + onboarding script. The substrate becomes ecosystem, not instance — and that's what makes the 'operator N+1 benefits from operators 1..N' compounding claim operational rather than rhetorical.

Phase gate

Gate clears when ≥ 3 substrate instances are federated under independent operator L1 keys + the federated convergence detector surfaces ≥ 1 strength-3 cross-substrate convergence (a signature observed by ≥ 3 distinct operators) on real production evidence.

Phase 4 — Vision-state2027+ · partnership-paced○ planned

The empirical-correctness layer for European software

The substrate becomes the default for EU regulated AI-assisted software. Capability-transfer licensing program — developed-market revenue funds global-south access. Platform-of-platforms: AI coding tools and agent frameworks build on Promethean primitives. EU certification bodies cite the substrate as compliance proof. v1.0 lock (May 12 2026) crossed the architectural-readiness gate ahead of schedule — schema-stable, externally-verifiable, regulator-handoff-ready. What remains is partnership development (ENISA, EU AI Office, national notified bodies + the regulator pre-engagement primitive built into v0.18 that turns their requirements into a structured target the substrate can verify against).

Phase gate

No fixed gate — this is the vision-state. We measure progress by adoption + regulator citation, not by a specific calendar.

The moat

Two layers. The foundation, then the loops.

The code will be open. We expect competitors. Defensibility sits at two layers — the unforkable foundation underneath, and three compounding loops on top of it. The loops only work because the foundation holds. A copycat can clone the loops on paper; they cannot clone the trajectory the loops require.

The foundation moat · why a fork is a different organism

living constraints

Code is forkable. Time is not.

What forks

  • The code
  • The architecture
  • A snapshot of the population at time T
  • The provenance schema
  • The discipline rules (written down)
  • The license terms

What doesn't

  • The lineage of every constraint
  • The selection history that produced the population
  • Years of mortality decisions, written by reviewers
  • The plateau rotations that birthed cross-language convergences
  • The corpus contribution graph (license-aware, attributed)
  • The discipline practiced, not the discipline described

Living constraints aren't data — they're organisms with lineage. A copycat at fork-point inherits state, not trajectory. Their constraints have to earn fitness in their environment, with their operators, against their regulators, drawing from the corpus they can persuade contributors to feed. Within months the fork is a different organism: same body, different years. The compounding loops below are what this foundation makes possible.

The compounding loops, on top of the foundation

The unforkable foundation is what makes three reinforcing loops actually compound — instead of being three business plans a competitor could try to outrun. Every product the factory ships enriches the corpus; every corpus addition raises what the audit can verify; every regulator citation pulls more operators onto the rail; every operator install grows the capability-transfer footprint and widens the next corpus harvest. The loops are the consequences. The foundation is why nobody else gets to run them.

Three reinforcing loops

the compounding moat

Each loop reinforces the next. Every product the factory ships enriches the corpus. Every corpus addition raises the substrate's discriminating power. Every regulator citation pulls more operators onto the rail. Three feedback loops, each compounding, intersecting where the moat lives.

A

The cross-organisational corpus

Every operator's findings, contributed back, become evidence for the next operator. License-aware harvesting. Provenance-tracked predicates. Cross-validated across thousands of repos. A new entrant starts with zero. We compound from where every previous operator left off.

B

The closed feedback loop

Production runs feed the corpus. The corpus gates the next production runs. Frontier-model improvements raise the quality of harvested predicates, which raise the substrate's discriminating power, which raises the value of contributing back. The loop tightens with every cycle.

C

The European regulatory rail

Curated GDPR + EU AI Act obligations with EUR-Lex permalink citations and risk-tier mapping — the only category in modern software where Europe enters from asymmetric strength. Whoever builds the first substrate cited by EU certification bodies as the reference implementation defines the global default. Today regulators cite American tools. Tomorrow they cite a European-built substrate that was regulator-aware by design. Brussels effect compounds: every operator that ships into the EU eventually adopts the rail. We build it from inside the regulatory tradition, not retrofitted from American assumptions.

The compounding, mechanically

Six loops. One compounding factor.

The Microsoft-Office competition claim is not "we will outwork them." It is "our architecture compounds where theirs is linear." Each product the substrate ships enriches the substrate, which enriches every subsequent product. Below: the six concrete mechanisms that produce the compounding factor — each one already present in the substrate's harvesters, predicates, generators, and audit chains.

The compounding, mechanically

why architecture matters

Microsoft's structure

1 + 1 + 1 + … = N

Each product is its own engineering org. Capability scales linearly with headcount. Cross-product learning requires cross-team coordination cost.

Substrate's structure

1 × cN

Each product enriches the substrate. The substrate enriches every subsequent product. Capability compounds. The factor c is generated by the six mechanisms below.

The compounding curve

capability per product · vs n

At product 1
conv: 1× capability
substrate: 1× capability (no prior learning yet)
At product 10
conv: still 1× per product
substrate: ~5× the cumulative learning
At product 100
conv: still 1× per product
substrate: 100× cumulative learning · empirical moat
01

Test-predicate cross-pollination

↓ harvestevery product's passing test signatures
↑ propagateevery future product in the same domain

Test-writing becomes curation from a shared corpus, not authorship from scratch.

why hard:Microsoft Excel's tests cannot speak to Word's — siloed teams, separate codebases, no shared abstraction layer.

02

Compliance-fingerprint propagation

↓ harvestevery regulatory event (Schrems II ruling, AI Act guidance, GDPR fine)
↑ propagateall existing + future products, retroactively + prospectively

Maintaining compliance across N products becomes a single corpus update.

why hard:Coordinating compliance updates across hundreds of Microsoft products is a ~10,000-engineer problem. The substrate solves it as one merge.

03

Failure-mode library

↓ harvestevery production incident, security finding, audit complaint
↑ propagateall future products as 'do-not-ship-this-configuration' predicates

Every shipped product inherits immunity to known failure modes from day zero.

why hard:Incident reviews in one Microsoft team don't translate cross-product without dedicated coordination cost — and rarely do.

04

Generator improvement loop

↓ harvestevery product's runtime telemetry + user-reported issues
↑ propagatethe 49 product generators, sharpening their output monotonically

Scaffolding quality increases with every product. Product 100's auth flow is better than product 1's by construction.

why hard:Microsoft has no cross-product code generators. Each product is hand-built; refinements stay local.

05

UX-conversion harvesting

↓ harvestevery deployed product's onboarding · conversion · retention metrics
↑ propagatethe substrate's UX-pattern library, indexed by vertical

Top-performing flows in vertical X become the defaults for new products in vertical X. Pattern selection becomes empirical, not theoretical.

why hard:Excel UX research doesn't propagate to Word UX without dedicated cross-team work — and the org structure resists it.

06

Portfolio leverage

↓ harvestevery operator's account on any substrate-shipped product
↑ propagateshared auth · billing · audit log · telemetry across the entire portfolio

Single sign-on across all products comes for free, not as integration work. Cross-sell is structural.

why hard:Microsoft built this over 25 years across teams that started independent. The substrate gets it as a property of the architecture.

Each loop is concrete — already in the substrate's architecture as harvesters, predicates, generators, audit chains. At product 1, the substrate is roughly equivalent to a conventional SaaS team. At product 50, the per-product cost has approached substrate-fixed-cost and the per-product capability is the cumulative learning of 50 deployments. That is what makes Microsoft-Office-class competition structurally possible from a small team — not a feature claim, an architectural one.

The business case

Each path monetises a different face.

We do not need all three to work — we need one to work, and the others to be open. Path A monetises the audit + corpus (Faces I + III) as a SaaS. Path B monetises the rail (Face IV) via regulator partnership. Path C monetises the transfer (Face V) by inverting the funding flow — developed-market revenue funds underserved-operator access. The factory (Face II) is the operating advantage that makes all three viable from a small team.

APhase 2 onward · monetises Faces I + III

Audit + corpus · open-core SaaS

  • Gap-detector CLI + Action: free + open source
  • Paid tier: cross-org corpus access, custom rule packs, regulatory enterprise dashboards
  • Per-seat or per-repo pricing for EU regulated software
  • Initial target: 10–50 EU operators paying €500–5,000/mo by end of Phase 2
BPhase 3–4 · monetises Face IV

Rail · regulatory partnership

  • Partner with EU certification bodies and notified bodies
  • Substrate provides compliance evidence for high-risk AI Act systems
  • Revenue from certification fees + audit-as-a-service
  • Adjacent: assurance reports, conformity-assessment integration
CPhase 4+ · monetises Face V

Transfer · capability-transfer licensing

  • Developed-market enterprise tier funds global-south access
  • Substrate ships at zero cost to operators in restricted-capital markets
  • Operators contribute findings back; corpus value compounds
  • Brand asset: Promethean as the substrate that closes the gap

Capital structure

Phase 2 (6 months to first paying pilots) requires a focused team of 3–5 and 12–18 months of runway to clear the Phase 3 gate. The current state of the substrate de-risks the technical bet — what we are raising for is distribution, regulatory partnership development, and the discipline of running the audit pattern on dozens of external operators instead of one.