FORGE-102 — The Product Roadmap

FORGE-102 — The Product Roadmap

Project Forge — Third Engineering Document Status: Strategic Constitution (normative where it binds order, evidence, doctrine, and gates; indicative where it estimates effort or sketches a calendar). Extends FORGE-100 and FORGE-101; implements FORGE-001, FORGE-002, FORGE-003. Precedence: FORGE-002 governs meaning; FORGE-100 governs construction; FORGE-101 governs composition; FORGE-102 governs sequence — what must be true before what, and what evidence admits each next step. Where this document appears to promise a feature its predecessors forbid, the predecessors govern and the promise is void. Where this document appears to schedule a date, read again: it schedules a gate.

Preamble

The founding trilogy defined what Forge means. FORGE-100 proved it constructable. FORGE-101 proved the construction shareable — three planes, one invariant, a migration whose regression suite is byte-equivalence. Five documents now exist, a landing page is live, the domain projectforge.dk is secured, and the HPC Analytics platform continues to serve Mjolnir’s readers in production every day.

What does not yet exist is time. The documents describe a finished shape; reality will build it in an order, under constraints, by people with finite hours, against a production platform that must not stop. This document exists to govern that order.

I write here as Chief Architect, and this document forces me into the role the previous documents let me refuse: the planner. Planning is where architecture goes to be humiliated — every roadmap in this project’s ancestry promised sequences that dissolved on contact with the first quarter’s reality. So this document adopts a discipline the corpus has already taught: it binds order and evidence, never dates. A calendar estimate appears where honesty permits one, always marked indicative. What is normative is the sequence of gates — the statements of what must be demonstrably true before the next phase may begin — because a gate, unlike a date, cannot slip; it can only remain closed.

My loyalty in this document is to two readers. The first is the small team that must live this sequence: the people who will run the migration while keeping production alive, and who deserve a roadmap that budgets for their actual capacity rather than flattering their ambition. The second is the decision-maker in year three — a department head, a funding body, an external institution’s architect — who must judge whether Project Forge is real, on track, and safe to join. Both readers are betrayed by the same failure: a roadmap that describes the happy path and hides the gates. This document therefore states, for every phase, not only what will be done but what must explicitly not be done, and ends — in the corpus’s tradition — with an honest account of what remains unknown and what evidence will settle it.

Two sentences frame everything below. They are this document’s contribution to the constitutional record, and Part 1 elevates the first to doctrine:

  1. Forge is extracted from success, never designed in isolation. The HPC Analytics platform is not the thing Forge replaces; it is the proving ground Forge is distilled from, and it never stops moving.

  2. A roadmap is a promise about order, not about arrival. Every phase gate in Part 4 is written so that an outsider can verify its passage. If the gates are passed, the roadmap held — whatever the calendar says.

Terminology

RFC-2119 terms (MUST / MUST NOT / SHOULD / MAY) are used as in FORGE-100 and FORGE-101.

New defined terms introduced here: Gate (a verifiable condition that admits a phase transition), Phase (a period of the ecosystem’s life bounded by gates), Extraction (the movement of proven capability from the proving ground into its constitutional plane), Extraction Tax (the capacity spent on extraction rather than platform improvement), Proving Ground (the production platform in which capability is born and proven before extraction), Cold-Start Test (the timed, documented construction of a Forge Instance by people without prior Forge knowledge), Ghost Instance (a synthetic instance used to prove that no real instance’s knowledge remains in shared code), and the Evidence Ledger (the Final Review’s register binding each architectural assumption to the evidence that will confirm or refute it).

A note on numbering: FORGE-101 Part 16.1 defined migration phases 0–6, which are engineering mechanics. This document defines ecosystem phases 1–8, which are strategic states. They nest rather than compete; Part 4.0 gives the exact mapping. When the two documents are cited together, say “migration Phase n (FORGE-101)” or “roadmap Phase n (FORGE-102).”

Part 1 — The Extraction Doctrine

This part states the single most important rule in the document. Everything after it is elaboration.

1.1 The prime directive

Development of the HPC Analytics platform never stops. Not during the audit, not during Core extraction, not during domain extraction, not while BioHPC is being composed. The platform’s readers, its operators, and its improvement cadence are senior to every line of this roadmap. Any plan, phase, or extraction that requires freezing the platform is by that fact wrong and MUST be re-planned.

The reasoning is not sentimental. The platform is the only source of evidence Forge has. FORGE-101 Part 15 could map today’s subsystems into planes precisely because those subsystems exist, run, and are used; FORGE-101 Part 4.6 forbids speculative domains precisely because generality invented ahead of evidence is the death of platform projects. A frozen proving ground stops producing evidence, and a Forge built beside a frozen platform is a Forge designed in isolation — the exact failure this project was founded to avoid. The platform is not a legacy system awaiting replacement. It is the experiment whose results Forge publishes.

1.2 Extraction, defined

Extraction is the movement of capability that has already proven itself in the proving ground into the plane where it constitutionally belongs — Core if it passes the Core test (FORGE-101 Part 3.1), Forge HPC if it is practice expertise, Mjolnir’s instance repository if it is deployment fact. Extraction has three properties that distinguish it from rewriting:

1.3 The direction of invention

Where is new capability born, during and after the migration? The doctrine’s answer:

Invention happens at the narrowest plane that can express it, and generalises only on evidence. Before the planes exist physically, invention happens in the proving ground, labelled (Phase 1’s audit labels apply to new code from the day the audit completes). After the planes exist, an instance-felt need is first met as a domain option or Core capability only when the need is already understood; when it is not yet understood, it MAY be prototyped in the domain plane behind a flag, but never in Core, and never as instance logic (ADR-020 stands).

This resolves the apparent tension between “never design in isolation” and “instances contain no logic.” The proving ground for a new idea is the domain plane (where Forge HPC’s real modules run against Mjolnir’s real truth), not the instance plane (which stays pure declaration) and not Core (which admits only the proven-universal). The old platform played all three roles at once; after extraction, the domain plane inherits the role of laboratory.

1.4 The Extraction Tax, and its bound

Extraction costs capacity that would otherwise improve the platform. This tax is real, it is the roadmap’s central economic fact, and pretending otherwise would repeat FORGE-002 Part 1’s diagnosis of FORGE-001: spending promises like a lottery winner. The doctrine bounds the tax:

1.5 The doctrine as a test

In planning review, ask of any proposed work item: does this freeze the proving ground, invent ahead of evidence, or place invention at the wrong plane? If yes to any, it violates the doctrine and is presumed wrong until the review records why. This is the sequence-level twin of FORGE-100 Part 1.5’s governing invariant, and it is cited the same way: by number, as a complete objection. (ADR-028, Part 21.)

Part 2 — Vision: The Five-Year Shape

2.1 The one-sentence vision

Within five years, Project Forge is a small, governed ecosystem in which a handful of real scientific instruments publish their truth through one shared runtime and a few evidence-born domains — such that a stranger institution can stand up an honest, durable, privacy-sound public account of its instrument in weeks, by writing declarations rather than software.

Every clause is load-bearing. Small — the vision is a handful of instances and two or three domains, not a marketplace; Forge measures itself by the depth of each adoption, not the count (Part 19.3). Governed — amendments, ratifications, and promotions run through the process of Part 8, not through whoever is loudest. Evidence-born — every domain in existence traces to a committed instance that demanded it (FORGE-101 Part 4.6). Stranger institution — the acceptance test of the entire project is that the founding team is not in the room (Part 5, Part 4.8). Weeks and declarations — the instance plane’s smallness (FORGE-101 Part 5.1) converted into the adopter’s experience.

2.2 What exists in year five

Stated as an inventory, so that year five can be audited against it (the narrative rendering is Part 20):

  1. The constitution — FORGE-001 through FORGE-102, plus FORGE-004 (the assistant constitution, written before any assistant shipped — Part 4.6), the trunk ontology at a low single-digit version, the ratified extension registry, and an ADR series still deliberately short.
  2. Forge Core — one repository, releasing deliberately, at or past 1.0 for more than two years, still containing zero domain vocabulary (verified mechanically, forever).
  3. Two or three domains — Forge HPC mature; a second domain (in the expected history, Forge Genomics, pulled into existence by BioHPC’s own needs — Part 15.3) proven by its second instance; possibly a third in extraction.
  4. Four to eight instances — Mjolnir, BioHPC, Rubus, and a small number of external adopters, each a repository of declarations, at least one operated by an institution the founding team has never worked at.
  5. Governance that has said no — at least one extension package rejected or reworked, at least one promotion executed, at least one deprecation window opened and honoured to its close (Part 7.4). Governance that has never refused anything is decoration.
  6. A sustainability arrangement — named plane owners with distinct names on at least two planes, an editorial line item in every instance’s operating budget (Part 17.2), and funding that survives the founding grant (Part 17.4).
  7. The record itself — every snapshot ever published by any instance still readable; every permanent URL ever minted still resolving; the migration’s own history readable in Mjolnir’s Record as authored Deployment events (FORGE-101 Part 16.2).

2.3 What deliberately does not exist in year five

The vision is defined as much by its refusals, because a roadmap that only adds is a roadmap that has not read FORGE-001’s critique of accumulation:

2.4 The three horizons

The five years divide into three overlapping horizons, which the phases of Part 4 traverse:

Part 3 — MVP, Forge 1.0, and the Long Horizon

The words “MVP” and “1.0” carry industry meanings Forge must partially refuse. This part defines both precisely, because vague version words are how scope creeps in and trust leaks out.

3.1 The MVP — deliberately invisible

For a product, a minimum viable product is the smallest thing users will pay for. Forge’s readers already have the product — the platform is live. Forge’s actual customer at MVP stage is the second instance, and what the second instance buys is composability. Therefore:

The Forge MVP is the moment Mjolnir’s production platform is published by the composition forge-core + forge-hpc + mjolnir, byte-equivalent to its pre-migration output. The MVP ships no new feature, changes no pixel, and is invisible to every reader — and that invisibility is the specification, not a disappointment.

This definition (reached at the Phase 4 gate, Part 4.4) has three virtues. It is testable — byte-equivalence is a mechanical check, not a judgment call. It is honest — it claims composability, which the composition demonstrates, and nothing more; the claim of re-composability (that a different instance can compose the same parts) is explicitly not made until BioHPC makes it (Part 13). And it is disciplined — defining MVP as “no visible change” removes the incentive to smuggle features into the migration, which FORGE-101 Part 16.3 already forbids.

What the MVP is not: it is not adoptable, not documented for strangers, not supported, not stable in its contracts, and not 1.0. Between the MVP and 1.0 lies the entire distance between “works for us” and “safe for you,” and Part 4’s Phases 5–6 are that distance made explicit.

3.2 Forge 1.0 — the seven claims

Forge 1.0 is not a feature level. It is the moment seven claims become simultaneously true, each backed by cited evidence. Declaring 1.0 is a governance act: the claims are audited, the evidence is recorded in the Record, and the declaration itself is a Deployment event in the project’s own history.

The seven claims:

  1. Composability is proven by production. Mjolnir runs in production as a composition of released Core and domain versions — not repository heads — and has for at least two quarters. (Evidence: the composition lockfiles and Deployment events.)
  2. Re-composability is proven by a second instance. BioHPC passed the constitutional acceptance test of FORGE-101 Part 16.1 Phase 6 — zero Core changes, domain changes limited to new adapters or bindings — and has run in production for at least one quarter. (Evidence: BioHPC’s composition record and the change log of the proof period.)
  3. The contracts have survived change. At least one additive contract evolution and at least one deliberate deprecation (opened, windowed, honoured, closed) have been executed across the ecosystem without breaking either instance. A versioning discipline that has never been exercised is a versioning theory. (Evidence: the contract version history and the Record’s deprecation events.)
  4. The laws are enforced by machines. The dependency law (FORGE-101 Part 14), the no-logic rule, Core’s vocabulary ignorance, manifest completeness (upkeep owner, degraded state) — all checked mechanically at composition time, with the checks themselves tested. (Evidence: the composition toolchain and its test suite.)
  5. Privacy has been adversarially audited. The re-audit of user analytics (FORGE-101 Part 16.3’s named exception) is complete; aggregation floors and differencing resistance (ADR-017) have been attacked by someone whose job was to break them, and the findings are resolved or recorded. (Evidence: the audit report, held to the same append-only honesty as everything else.)
  6. A stranger has succeeded. The Cold-Start Test (Part 5.3) has been passed at arm’s length: people who did not build Forge stood up an instance from the documentation alone, within the published time bound. In the expected history this is Rubus (Part 14). (Evidence: the timed, journaled cold-start report — published, including its failures.)
  7. The promises have owners. Every contract, every core and domain module, every document set has a named maintainer; the support policy (what an adopter may expect, at what latency, for how long) is published; the project’s continuity arrangement (Part 17) is written down. (Evidence: the governance registry.)

1.0 adds no features by definition. It subtracts uncertainty. If a proposed 1.0 work item is a feature, it is misfiled.

3.3 Version semantics before and after 1.0

3.4 The long horizon — what lies beyond 1.0

Named so that it cannot later be smuggled in as scope: federation (a national portal projecting across instances — kept buildable by ADR-001’s instrument-scoped identifiers, constitutionally unresolved per FORGE-101 Final Review unknown 4); the assistant (gated on FORGE-004); further domains (gated on committed instances); internationalisation policy (the mechanism is decided — FORGE-100 Part 16.3 — the policy is an instance/domain governance question for the ecosystem to answer when a non-English instance commits). None of these is on the road to 1.0. All of them are cheaper because the road to 1.0 refuses them.

Part 4 — The Eight Phases

4.0 How to read the phases

Each phase below is specified as: Goal · Deliverables · Risks · Gate (acceptance criteria) · Explicitly not done. Three reading rules:

 FORGE-102 (ecosystem)                     FORGE-101 Part 16.1 (migration mechanics)
 ──────────────────────                    ──────────────────────────────────────────
 Phase 1  Proving ground + audit      ⊇    Phase 0  Constitution · Phase 1  The Audit
 Phase 2  Mjolnir extracted           =    Phase 2  Instance extraction
 Phase 3  Forge Core exists           =    Phase 3  Core extraction
 Phase 4  Forge HPC exists            ⊇    Phase 4  Domain extraction · Phase 5  The residue is Mjolnir
 Phase 5  BioHPC proves it            =    Phase 6  The proof: BioHPC
 Phase 6  Forge 1.0                        (beyond FORGE-101's horizon)
 Phase 7  First external adopter           (beyond FORGE-101's horizon)
 Phase 8  Additional domains               (steady state, governed by ADR-027)

FORGE-101 Part 16 remains the authoritative specification of the mechanics of Phases 2–5 (what moves, in what order, verified how). This part adds what FORGE-101 deliberately left out: the strategic content of each phase, its risks, and its refusals.

4.1 Phase 1 — The Existing HPC Analytics Platform (now; audit measured in weeks, the phase itself never truly ends)

Goal. Establish the baseline from which everything is extracted: a production platform whose every component carries a plane label, whose builds are verifiably deterministic, and whose improvement cadence is measured — while that platform continues to ship features as if this roadmap did not exist.

Deliverables.

Risks. The audit stalls in dispute (mitigation: disputes are time-boxed; an undecidable label defaults to the narrower plane, because promotion on evidence is cheap — ADR-027 — while demotion of something wrongly generalised is surgery). Determinism proves harder than expected (mitigation: this is exactly why it is Phase 1; the fallback — a defined semantic-equivalence comparison with recorded exclusions — is designed now, not improvised later; see Evidence Ledger A2). The team treats the audit as paperwork (mitigation: the audit’s output is load-bearing for every later gate, and Part 4.0’s mapping makes skipping it a constitutional violation, not a shortcut).

Gate to Phase 2.

  1. 100% of the platform’s components carry an adjudicated plane label; the dispute log is closed or explicitly carried.
  2. Two consecutive production releases pass the byte-equivalence harness (same inputs → identical published artifacts).
  3. The cadence baseline is recorded.
  4. New code written in the platform carries a plane label at review time (the audit becomes a habit, not an event).

Explicitly not done in Phase 1. No repositories are created. No code moves. No Core API is designed beyond what labelling requires. No configuration schema is drafted “while we’re at it.” The single most damaging Phase 1 failure would be starting Phase 3 enthusiasm early — designing forge-core in the abstract while the audit is half-finished, which is designing in isolation with extra steps (Part 1.5).

4.2 Phase 2 — Mjolnir Extracted Into Forge (indicative: weeks to a small number of months)

Goal. Mjolnir is born as data. Every Mjolnir-specific value — endpoints, credentials (into a secret store, never a repository), branding, policies, labels, floors, feeds — moves into one typed, provenance-stamped configuration document (FORGE-101 Part 5.3), and the remaining codebase becomes a function parameterised by it.

Deliverables.

Risks. The long tail of hidden instance knowledge — the hardcoded threshold that encodes Mjolnir’s node count, the layout tuned to Mjolnir’s partition names (mitigation: the ghost instance finds what grep cannot, because the ghost’s different shape breaks assumptions a string search misses). Premature schema calcification — designing the configuration schema as if it were already the multi-instance contract (mitigation: the schema is 0.x and expected to be reshaped by BioHPC; what must be right now is the typing and provenance discipline, not the final key names).

Gate to Phase 3.

  1. Byte-identical production output before and after extraction (the harness, now doing its first real work).
  2. The Ghost Instance builds and publishes with zero Mjolnir residue.
  3. Lint enforces instance-vocabulary absence in core- and hpc-labelled code, in CI, blocking.

Explicitly not done in Phase 2. The forge-core repository is not created. No feature is redesigned in passing — the analytics re-audit (the one sanctioned correction, FORGE-101 Part 16.3) is scheduled, not performed here. The configuration schema is not documented for external consumption; it has one consumer and no stability promise yet.

4.3 Phase 3 — Forge Core Exists (indicative: months; the longest single phase)

Goal. The forge-core repository exists and is real: the Truth Store, Publisher, projection engine, search, design system, identity enforcement, composition machinery, and core Forge Modules live there, released as versioned artifacts — and the existing platform becomes forge-core’s first consumer, shrinking around it (the strangler pattern of FORGE-101 migration Phase 3).

Deliverables.

Risks. Core absorbs domain logic for convenience — the gravest long-term risk in the architecture (FORGE-101 Part 3.4), at its most tempting exactly now, when the same hands hold both repositories and the deadline pressure is real (mitigation: the Core test applied in review of every move + the vocabulary firewall + the audit labels, which were adjudicated calmly in Phase 1 precisely so they could overrule convenience now). The ceremony trap — three repositories, one mind (FORGE-101 Final Review unknown 5): the boundaries feel like theatre and discipline erodes (mitigation: the boundaries are enforced by CI, not willpower; and the Phase 5 gate is where the ceremony pays off visibly, which is soon enough to keep faith). Extraction tax spike — this phase moves the most code (mitigation: Part 1.4’s cadence canary, checked monthly; the phase plan is a sequence of small shippable moves, each individually abortable).

Gate to Phase 4.

  1. The production platform composes released forge-core versions; the old shell contains no core-labelled code.
  2. Byte-identical output maintained across every individual move (a per-move check, not a phase-end check).
  3. The dependency-law checker and vocabulary firewall run blocking in CI on every repository that exists.
  4. Core has made at least three 0.x releases consumed in production — the release muscle demonstrably works.

Explicitly not done in Phase 3. No public announcement of forge-core as adoptable; 0.x is not an offer (Part 3.3). No documentation written for external adopters (internal architecture notes only — external docs written against 0.x churn are rot scheduled in advance, violating Principle 9 in spirit). No ontology second-guessing: the trunk is FORGE-002’s sixteen; Phase 3 implements, it does not re-legislate. No domain extraction started until the Core gate closes — Core’s contracts are what the domain will be written against, and extracting against a moving target is the double-migration FORGE-101 Part 16.2 warns of.

4.4 Phase 4 — Forge HPC Exists (indicative: months)

Goal. The practice expertise leaves the shell: adapter families (logic split from bindings per FORGE-101 Part 8.4), domain modules (queue outlook, fleet view, software intelligence), knowledge templates, and vocabulary move into forge-hpc; the hpc: Domain Extension Package is ratified through the governance process as its first live exercise; and what remains of the old codebase — manifest, configuration, branding, content — becomes the mjolnir repository. The old codebase is retired with an authored Deployment event. At this phase’s close, the Forge MVP exists (Part 3.1).

Deliverables.

Risks. The ratification process fails its first exercise — too heavy (weeks of process for obvious facet families) or too light (rubber stamp) (mitigation: Part 8.4 sizes the process before the exercise; the friendly first case is deliberate). The adapter split exposes credential entanglement deeper than the audit found (mitigation: the split was rehearsed in Phase 2’s secret externalisation; residual entanglement is relocation work, not redesign). Scope creep wearing a toolbelt — “while we’re extracting the queue module, let’s finally improve it” (mitigation: FORGE-101 Part 16.3 is law; improvement is view-layer work after relocation, when views are free).

Gate to Phase 5 — the MVP gate.

  1. Production Mjolnir is published by the composition forge-core + forge-hpc + mjolnir from three repositories, byte-equivalent to the pre-migration platform.
  2. The hpc: extension package is ratified, versioned, and registered; the ratification is recorded with its reasoning.
  3. The mjolnir repository contains zero logic — verified mechanically (no executable code beyond declared configuration), not rhetorically (ADR-020).
  4. The Ghost Instance composes from the same three public parts (ghost config in place of mjolnir’s), proving the composition path carries no hidden Mjolnir dependency.
  5. The analytics re-audit is complete with findings resolved or recorded.
  6. The old repository is archived, its retirement authored in the Record.

Explicitly not done in Phase 4. No BioHPC work — not “preparatory,” not “just the adapters” — because Phase 5’s evidentiary value depends on BioHPC arriving after the extraction is finished and testing it cold; contaminating the test to save a month is spending the proof to buy the rehearsal. No new domain modules invented during extraction. No Forge Genomics anything (Part 15.3). No 1.0 talk: the MVP is composability for one instance, and Part 3.1 bounded its claims deliberately.

4.5 Phase 5 — BioHPC Proves the Architecture (indicative: one to two quarters)

Goal. The constitutional acceptance test (FORGE-101 migration Phase 6): a second real instance composes forge-core + forge-hpc + biohpc and enters production, with zero changes to Forge Core and zero domain changes beyond new adapter families/members or bindings that BioHPC’s genuinely different reality requires. Every violation of that bound is treated as a misplacement that escaped Phases 1–4 and is fixed by relocation, never by exception.

Part 13 specifies this phase in full — what BioHPC is, when it starts, what counts as failure, and what evidence it yields. Here, the phase-frame only:

Deliverables. The biohpc repository (declarations only); any new adapters BioHPC’s sources demand, landing in forge-hpc as domain capability (immediately reusable by every future HPC instance — the first upward extraction driven by a second instance, the doctrine of Part 1.2 operating in its intended direction); the misplacement log (every relocation the test forced, because each is a lesson the audit missed); and the first time-to-instance measurement — the number Part 5 and Part 14 will steadily drive down.

Risks. Named and mitigated in Part 13.4–13.5: the reality gap (BioHPC differs more than the domain absorbed), the special-case temptation, the schedule coupling of another institution’s calendar to this roadmap’s gate.

Gate to Phase 6.

  1. BioHPC in production ≥ one quarter, on released versions, composed with zero Core changes and only sanctioned domain changes — the test passed as stated, with the change log published as proof.
  2. The misplacement log is empty or fully resolved by relocation.
  3. Both instances upgrade through at least one shared Core 0.x release — the first evidence that one runtime can serve two masters moving at different speeds.

Explicitly not done in Phase 5. No genomics domain, even though BioHPC’s name begs for it: BioHPC ships first as a pure Forge HPC instance, because Phase 5’s question is “does the HPC domain generalise?” and adding a second variable would blur the answer (Part 13.6). No external adopter conversations that imply availability. No 1.0 declaration at the moment the test passes — claims 3 through 7 of Part 3.2 remain unevidenced, and 1.0 on the strength of claim 2 alone would be the industry habit this document exists to refuse.

4.6 Phase 6 — Forge 1.0 (indicative: two to three quarters of deliberate, unglamorous work)

Goal. Convert the architecture’s proofs into promises safe for strangers: the seven claims of Part 3.2, each evidenced, audited, and declared in a recorded governance act.

Deliverables.

Risks. Declaring early — enthusiasm after Phase 5’s success is the moment of maximum pressure (mitigation: the seven claims are written as an audit checklist precisely so the declaration is a verification, not a mood). Documentation lag — writing is the work most easily deferred (mitigation: docs are gate conditions, not accompaniments; Part 10.4’s stranger test makes their quality measurable). The unglamour problem — Phase 6 contains no visible construction, and morale dips in phases that only harden (mitigation: Rubus lives here, and Rubus is construction).

Gate to Phase 7. The seven claims of Part 3.2, each with cited evidence, audited by someone other than the person who produced the evidence, declared and recorded. There is deliberately nothing else in this gate: 1.0 is the gate.

Explicitly not done in Phase 6. No features to “round out” 1.0. No assistant implementation (FORGE-004 is written; nothing ships against it yet). No new domain. No adopter onboarding before the declaration — a pre-1.0 adopter inherits 0.x churn under a 1.0 handshake, which is a small lie of exactly the kind the platform refuses to tell about facts, told instead about software.

4.7 Phase 7 — The First External Adopter (indicative: opens in year three; runs one to two quarters per adopter)

Goal. An institution the founding team does not control composes, deploys, and operates a Forge Instance in production — and the project survives the experience: support load measured and sustainable, laws intact under external pressure, the adopter’s needs landing as domain options and Core capabilities rather than special cases.

Deliverables.

Risks. Support drowns the team — the classic fate of small infrastructure projects at first adoption (mitigation: one adopter at a time, deliberately; the support policy’s latencies are honest rather than eager; every support incident that reveals a docs gap fixes the docs, so cost amortises). The adopter demands law violations — a private object type, instance logic, a Core special case (mitigation: the laws are citable and mechanical; the legitimate pressure valve is the domain-option path of ADR-020, and the governance process of Part 8 exists to say no politely and in writing). The adopter forks — takes the code, ignores the constitution (mitigation: the license permits it — Part 9.5 — and the ecosystem’s answer is not legal but economic: a fork inherits all maintenance and no community; the roadmap’s job is to make staying cheaper than leaving, and everything in Phases 1–6 was that job).

Gate to Phase 8 (and steady state).

  1. The external instance in production ≥ two quarters with zero Core changes on its account and no unresolved law violations.
  2. Support load measured and within the sustainability envelope of Part 17.
  3. The adoption playbook updated with every lesson; a second external adopter can be onboarded without heroics.

Explicitly not done in Phase 7. No parallel onboarding of multiple adopters. No adopter whose instrument requires a domain that does not exist — an adopter arriving with a committed non-HPC instrument is the trigger for Phase 8, not a Phase 7 customer, and the sequencing matters: adopting Core+domain must be routine before creating domains for adopters can be safe. No hosted offering, however sincerely requested (Part 2.3).

4.8 Phase 8 — Additional Scientific Domains (indicative: years three through five; then steady state)

Goal. The domain plane proves it can grow: a second domain is extracted on evidence (in the expected history, Forge Genomics, summoned by BioHPC’s own sequencing reality — the committed instance already exists in the family, Part 15.3), composed alongside Forge HPC in one instance, and validated by its own second instance — demonstrating trunk-mediated cross-domain composition (FORGE-101 Part 4.5), the promotion mechanism on a real concept (Sample is the predicted first case, FORGE-101 Part 9.2), and governance with genuinely distinct names on genuinely distinct planes.

Deliverables.

Risks. The domain community does not materialise — practice experts use software; far fewer maintain it (mitigation: Part 16’s community roadmap starts cultivating at Phase 5, not Phase 8; and Part 17.4’s consortium model is the fallback — funded maintenance where volunteered maintenance falls short). Trunk pressure — each new domain arrives believing its central noun is universal (mitigation: ADR-016/019’s ratification, plus FORGE-101 Part 9.3’s radius test, applied in a governance process that has by now said no before). The mesh temptation — two domains in one instance will surface “just one small import” cases (mitigation: rule 4 is checked mechanically; the promotion path is the pressure’s only outlet, by construction).

Gate (to steady state).

  1. The second domain’s second instance passes the same zero-change acceptance test BioHPC passed for Forge HPC — generality proven the only way this project accepts, twice-instantiated (ADR-027).
  2. A two-domain instance runs in production with the dependency law intact.
  3. At least one promotion ratified and executed.
  4. Plane ownership includes at least two genuinely distinct names.

Explicitly not done in Phase 8 — or ever. No domain without a committed instance. No third domain while the second is unproven. No “Forge AI” domain (FORGE-101 Part 8.5 placed prediction permanently; the placement is not reopened by fashion). No relaxation of Core’s ignorance to ease cross-domain composition — the trunk is the meeting ground, and enriching the trunk through ratified amendment is the lawful response to composition pressure (FORGE-101 Part 4.5), Core-side shortcuts are not.

Part 5 — The Gate to the World: Milestones Before External Adoption

Part 4.7 names external adoption as a phase. This part enumerates what must exist before any stranger is invited — the checklist behind the 1.0 declaration, stated separately because it will be tested separately, and because eagerness to show the work will pressure every item on it.

5.1 The offer is not made before it is safe

Before 1.0, Forge does not offer adoption. It may be admired in public — the constitutional documents are public, the landing page is live, and openness about the work in progress is both honest and community-building (Part 16) — but there is a difference between watch us build this and build on this, and the difference is a promise. Principle 11 governs the platform’s living surfaces; this document extends its logic to the project itself: an adoption offer is a living promise with an upkeep cost, and it MUST NOT ship before its upkeep is funded and its degraded state (the support policy’s honest limits) is declared.

5.2 The milestone checklist

Each item is a precondition of the Phase 7 gate opening; most are Phase 6 deliverables, gathered here in the order an adopter encounters them:

  1. A license and a legal identity. The repositories carry an OSI-approved license chosen for infrastructure longevity (Part 9.5); the project has an answerable legal shape (institutional home, consortium, or foundation — Part 17.5 weighs them) so that an adopting institution’s lawyers have someone to write to.
  2. Versioned, stable contracts — 1.0, with the deprecation regime exercised (Part 3.2 claim 3).
  3. The documentation corpus — constitution, runtime handbook, domain handbook, adoption playbook — passing the stranger test (Part 10.4).
  4. The Cold-Start Test, passed at arm’s length — Rubus’s journal published, including the failures, with the measured time-to-instance (Part 14).
  5. The security and privacy audit — because an adopter inherits Forge’s identity enforcement and aggregation machinery sight-unseen, and “we audited it and here is the report” is the only honest substitute for their own review (Part 3.2 claim 5).
  6. The support policy — scope, latency, channel, and limits, published; and the continuity statement — what happens to adopters if the project ends (Part 17.6).
  7. A worked example that is not aspirational — Mjolnir and BioHPC in production, their composition records public at whatever fidelity their institutions permit, so the adopter’s architect can inspect a real instance rather than a demo.
  8. A governance door — the documented path by which an adopter raises needs, proposes changes, and appeals decisions (Parts 8–9), so that adoption is entry into a governed commons rather than dependence on a vendor’s goodwill.

5.3 The Cold-Start Test, specified

The Cold-Start Test is this roadmap’s most important single measurement, referenced by Parts 3.2, 4.6, and 14. Specification:

The test is repeated — not retired — at each major Core version, because adoption surfaces rot exactly like documentation, and the cure is the same: make staleness a detectable failure rather than a discovered embarrassment.

Part 6 — Core, Domains, and Instances Over Time

FORGE-101 defined the three planes structurally. This part describes them economically — how value, evidence, and obligation flow between them across the roadmap’s life — and gives the repository structure at each stage, because the repositories are where the abstraction meets the file system.

6.1 The ecosystem’s economy

The planes trade in two currencies, moving in opposite directions:

Machinery flows down; evidence flows up. Core gives every domain its truth-keeping, publication, privacy, and search for free; domains give every instance their practice’s adapters, projections, and written judgment for free. In return, instances generate the evidence — real needs, real misplacements, real usage — that justifies every domain capability; and domains generate the twice-needed patterns that justify every Core capability. Neither flow may be forced: machinery pushed down without evidence is speculation (ADR-027); evidence hoarded at the instance as local logic is theft from the next adopter (ADR-020).

Three consequences shape the roadmap:

6.2 The repository structure over time

Three stages, per the horizons of Part 2.4. (The steady-state shape is FORGE-101 Part 13.1; what follows is its arrival sequence.)

Today (Phase 1–2):

 forge                      the constitution (this repository): FORGE-001…102,
 │                          ontology, contracts, ADRs, governance, templates
 │                          + the landing page at projectforge.dk
 └── (hpc-analytics)        the production platform — one repository, all three
                            planes' knowledge interleaved, now carrying audit
                            labels; the proving ground

After the MVP (Phase 4 gate):

 forge                      constitution + ontology/extensions/ registry
 ├──▶ forge-core            the runtime (0.x): truth, publisher, projection,
 │                          search, design system, identity, composition,
 │                          core modules
 ├──▶ forge-hpc             first domain: adapter families, hpc: extension
 │                          package, domain modules, knowledge templates
 └──▶ mjolnir               first instance: manifest, lockfile, configuration,
                            branding, authored content — no logic
 (hpc-analytics)            archived; retirement recorded in the Record

Year five (Phase 8, steady state):

 forge                      constitution; extension registry; governance records
 ├──▶ forge-core            ≥1.0; slow, deliberate; least-active repository
 ├──▶ forge-hpc             mature; community co-owned; most-active repository
 ├──▶ forge-genomics        second domain, evidence-born, twice-instantiated
 ├──▶ mjolnir               ─┐
 ├──▶ biohpc                 │ instance repositories: small, declarative,
 ├──▶ rubus                  │ each owned outright by its institution
 └──▶ (external instances)  ─┘ (FORGE-101 Part 13.2: adoption is a checkout)

Repository creation is gated, never anticipatory: forge-core exists only when Phase 3 opens, forge-hpc when Phase 4 opens, a domain repository when its committed instance exists (Part 15.2). An empty repository is a promise with no owner, and this ecosystem does not mint those.

6.3 The smallness budget

FORGE-101 Part 5.1 made instance smallness the architecture’s success measure; this roadmap makes it a tracked number. From Phase 4 onward, each instance repository’s composition is measured and published: lines of declaration, count of configuration values, count of authored content documents, and — the number that must be zero, mechanically, forever — lines of logic. The trend across instances is the ecosystem’s honesty about itself: if each successive instance is larger than the last, the domain plane is failing to absorb what instances keep needing, and the finding routes to the Promotion rule (FORGE-101 Part 7.8), not to exhortation.

Part 7 — Release Strategy

FORGE-101 Part 13.2 assigned each plane a release rhythm; this part specifies the rhythms and the rules that keep them decoupled. The governing observation: a release is a published claim about compatibility, and Forge treats claims the way it treats facts — versioned, provenance-stamped, honest about age.

7.1 Core releases like a runtime

7.2 Domains release like libraries

7.3 Instances deploy like configuration

7.4 Lockstep is a smell

If a Core release routinely requires same-day domain releases, or a domain release routinely requires same-day instance action, the planes’ boundaries are leaking coupling, and the finding is architectural, not procedural. The release strategy’s deepest purpose is diagnostic: decoupled planes were the promise; decoupled release trains are the proof. Part 19’s metrics watch precisely this.

Part 8 — Governance

FORGE-100 Part 14 created the governance directory; FORGE-101 Part 13.3 gave it the domain lifecycle; FORGE-101’s Final Review left its hardest question — who ratifies, who may say no — deliberately open with a real deadline (before the first extension package). This part is the roadmap’s answer: not a final constitution of governance, but the staged shape it takes, matched to the ecosystem’s actual size at each stage, because governance sized for an imagined community is as speculative as a domain built for an imagined instrument.

8.1 What governance is for

Forge’s governance exists to do exactly four things: amend the constitution (documents, trunk ontology, contracts — the rarest act), ratify and retire extension packages (the domain-scoped amendments of ADR-019), adjudicate placement (promotions, demotions, plane disputes — the Promotion rule’s judiciary), and say no (to speculative domains, to law-violating requests, to accretion wearing a good reason). Everything else — feature priorities, release timing, instance policies — is not governance and stays with the plane owners who do the work. A governance body that drifts into product management has failed by expansion, the same failure mode as a Core that absorbs domain logic, and is corrected the same way: by citing the boundary.

8.2 Stage one — the custodial phase (Phases 1–5)

Today, one small team holds every plane. Pretending otherwise would be ceremony (FORGE-101 Final Review unknown 5’s warning); refusing to prepare for otherwise would be negligence. The custodial arrangement:

8.3 Stage two — the council phase (Phase 6 onward)

Triggered by 1.0 — because 1.0 is the moment strangers acquire a stake — governance formalises into a small council:

8.4 Ratification, sized to reality

The first ratification (the hpc: package, Phase 4) sets the enduring precedent, so its shape is decided now, calmly:

A ratification submission is the extension template of FORGE-100 Part 14 completed in full — the questions only these types can answer, relations with trunk endpoints, facet classifications, upkeep owner — plus the mechanical validation (Core’s extension checker) already green. The ratifier reviews for exactly four things: namespace discipline (nothing shadowing the trunk), radius honesty (is this genuinely practice-wide, per FORGE-101 Part 9.3’s test — neither one instance’s need dressed up, nor a universal concept being fenced), classification completeness (every facet’s privacy class, ADR-017 reviewed where aggregation-bearing), and upkeep reality (a named owner who plausibly exists in year five). Decision within a published window — indicative: thirty days — because governance latency is a tax on every domain’s roadmap and Part 19 tracks it.

Ratification is deliberately not a design review of the domain’s modelling taste. A domain is the authority on its own practice (FORGE-101 Part 2.2, the who-knows-it axis); the ratifier guards the shared language’s coherence, not the domain’s judgment.

8.5 Governance failure modes, named in advance

Part 9 — The Contribution Model

9.1 Contribution follows the planes

There is no single “contributing to Forge,” and the model’s first job is routing. A contribution is aimed at exactly one plane artifact, and each has its own bar:

9.2 Every contribution is a promise

The constitution’s deepest cultural rule extends to contributors: code is not a gift; it is a promise of upkeep (Principle 11). Accordingly:

9.3 The contributor’s path

The expected trajectory, which Part 16’s community roadmap cultivates deliberately: operator → reporter → contributor → co-owner. An institution adopts (operator); its misplacement reports and cold-start defects improve the commons (reporter); its staff contribute the adapter for their scheduler variant (contributor); and, when their contributions and upkeep record warrant, they join the domain’s maintainer group (co-owner) — at which point FORGE-101’s aspiration that “a practice community can genuinely co-own forge-hpc” (Part 13.2) has become a fact with names attached. Each step is smaller than the last one looks: that is the design.

9.4 What is not accepted, from anyone

The refusals, so that review can cite rather than argue: speculative generality (“this might be useful for other domains” — ADR-027 demands the second need exist first); payload-bearing signals (ADR-022); modules with private stores or private caches (FORGE-101 Part 10); instance logic however small (“just a small script in the instance repo” — ADR-020 names this pressure exactly); unratified ontology vocabulary smuggled in as code constants; and any contribution, however excellent, that arrives without its manifest promises. None of these refusals is about quality. All are about the laws that make the ecosystem composable, and the contribution model is where those laws meet strangers for the first time — politely, in writing, with citations.

9.5 License

The license decision is made at Phase 6 (it is milestone 1 of Part 5.2) but its criteria are set now: OSI-approved; proven over decades in infrastructure software; permitting commercial use and institutional forks (an escape hatch that keeps governance honest, per 8.5); requiring no contributor copyright assignment beyond a lightweight provenance assertion — because a project whose data model stamps provenance on every fact should demand no less and no more of its code. Weak-copyleft and permissive licenses both satisfy these criteria; choosing between them is a governance act with the funding shape (Part 17) in view, recorded with reasons like everything else. What the license will not be is bespoke, source-available-but-not-open, or revocable: the abandonment-grace principle (FORGE-001 Principle 8) applies to the code as to the record — if the project dies, everything must remain usable by its survivors.

Part 10 — Documentation Strategy

10.1 Documentation is the adoption surface

For readers, the platform is the product. For adopters, the documentation is the product — an adopter experiences Forge as documents first, contracts second, and code a distant third (FORGE-101 Part 13.2: adoption is a checkout, not an excavation; the checkout is navigated by prose). The roadmap therefore treats documentation as engineering deliverable, phase-gated like code, and never as accompaniment.

10.2 The four bodies

  1. The constitution (exists): FORGE-001–102 and their successors, the principles, the ADRs. Audience: architects, governance, the maintainer in year five. Changes by amendment only.
  2. The runtime handbook (written in Phase 6, against stable contracts): how Forge Core works, operates, and is composed — the manual for domain builders and instance operators. Audience: the people who run the machinery.
  3. The domain handbooks (one per domain, begun at each domain’s birth): the practice’s mapping into the ontology, its adapter families and their source requirements, its modules and their parameters, its knowledge templates. Audience: the practice. The forge-hpc handbook is the template all later domains inherit.
  4. The adoption playbook (drafted in Phase 6, validated by Rubus, revalidated by every cold start): the straightest possible line from “we have an instrument” to “our instance is in production” — deliberately narrow, deliberately opinionated, measured by the Cold-Start Test.

10.3 The documentation obeys the platform’s own laws

The project that made documentation rot a build failure for its readers (FORGE-100 Part 7) does not exempt its own manuals:

10.4 The stranger test

Documentation quality is measured behaviourally: can the intended stranger do the intended thing with the document alone? The Cold-Start Test (Part 5.3) is the stranger test for the adoption playbook; scaled-down versions apply to the other bodies (a domain builder implements a toy adapter from the handbook; an operator executes an upgrade-by-diff from the runbook). Every stranger failure is a filed defect against the document, and the defect rate — not page count — is the corpus’s health metric. Documentation nobody has tested on a stranger is documentation the roadmap counts as unwritten.

10.5 What gets written when

The schedule follows a single rule: write against stability, document evidence not intention. Phase 1–5: internal architecture notes and decision records only (external docs against 0.x churn are pre-scheduled rot — Part 4.3). Phase 6: the runtime handbook, domain handbook, and adoption playbook, written against 1.0-candidate contracts, tested by Rubus. Phase 7 onward: continuous, defect-driven, stranger-tested. The one standing exception is the constitution itself, which documents decisions rather than software and therefore has been writable — and written — all along.

Part 11 — Testing Philosophy

Forge’s testing philosophy has one organising insight, inherited rather than invented: the architecture’s constitutional properties are its test infrastructure. Determinism, purity, contracts, and mechanical law-checking were chosen for constitutional reasons; each happens to be the strongest testing primitive an ecosystem could ask for. The philosophy is to spend these inheritances fully before writing a single conventional test.

11.1 Byte-equivalence — the migration’s regression suite

Because projections are pure and deterministic (FORGE-100 Part 2.5), behaviour preserved is bytes preserved: rebuild from the same snapshot, diff the published artifacts, and the diff is the complete, exhaustive account of what changed (FORGE-101 Part 16). Phases 2–4 rest their entire verification on this — which is why Phase 1 hardens determinism before anything moves, and why the harness runs per-move, not per-phase. Where byte-equivalence is unachievable for honest reasons (a legitimately reordered build, a corrected timestamp), the exception is recorded with its reason, semantic-equivalence rules are declared for that artifact class, and the exception list is reviewed — because an exception list that grows silently is the harness dying in place (Evidence Ledger A2).

11.2 Determinism as a standing invariant, not a phase

After the migration, the double-build check remains in CI forever: same snapshot + same composition → identical artifacts, on every release of every plane. This single check enforces, at once: no module reads the network at build time, no module holds private state across builds, no projection consults a clock — the whole family of purity violations (FORGE-101 Part 10) caught by one diff. It is the cheapest strongest test in the ecosystem and it MUST never be demoted to nightly-optional.

11.3 Contract conformance suites

Every contract of FORGE-100 Part 10 ships with an executable conformance suite, versioned with the contract: a snapshot claiming the Snapshot contract is fed to the suite; a search implementation claiming the Search contract answers the suite’s queries; an adapter claiming the ingestion contract has its emissions validated. Conformance suites are what make “implementation-independent” testable rather than aspirational — the static search path and a future query service pass the same suite (FORGE-100 Part 6.5), or one of them is lying. Domains and external contributors inherit the suites for free, which is most of what makes Part 9’s contribution bar objective.

11.4 The laws, tested as laws

The dependency rules, vocabulary firewalls, no-logic verification, manifest completeness — Part 4’s phases installed each as blocking CI. The testing philosophy adds one meta-rule: the checkers are themselves tested, with known-violating fixtures that must fail. A law checker that cannot demonstrate a conviction is presumed broken — the ecosystem’s constitutional enforcement gets the same scepticism as any other code.

11.5 Adapter fixtures — golden recordings of reality

Adapters are the most-breaking code in the system (FORGE-100 Final Review), coupled to sources that change without notice. The domain testing pattern: every adapter family maintains golden recordings — captured, anonymised source outputs (accounting rows, export files, API responses) with their expected ontology emissions — serving three duties at once: regression tests for the adapter, executable documentation of the source’s observed behaviour, and the seed data for the Ghost Instance (Part 4.2), which is how the whole pipeline stays testable with no real instrument attached. When a source changes upstream, the first commit is the new recording; the recording diff is the change’s specification.

11.6 Privacy is tested adversarially, forever

ADR-017’s floors and differencing resistance get standing adversarial tests — projections attacked with crafted queries and small-group fixtures, attempting re-identification — run in CI like everything else, extended after every audit finding. FORGE-100’s Final Review said this risk “will not be solved by a k-anonymity floor alone. It requires ongoing adversarial review” — the roadmap’s contribution is to make that review scheduled (each phase gate from 4 onward re-runs the suite; Phase 6 adds the external audit) rather than remembered.

11.7 What Forge does not test

Stated to keep the budget honest: pixel-perfection across browsers (the design system is reviewed by humans; visual regression tooling MAY be used but never gates truth); load and scale beyond each instance’s published thresholds (the static substrate makes read-scale a CDN’s problem — ADR-007 — and build-scale is watched by measurement, Part 12.2 of FORGE-100, not by synthetic benchmarks); and user behaviour (Forge measures its pipelines’ health, not its readers — the platform that refuses surveillance of researchers does not A/B test them either). Testing effort concentrates where the constitution concentrates its promises: truth, laws, contracts, determinism, privacy.

Part 12 — The Migration and the Living Platform

FORGE-101 Part 16 owns the migration’s mechanics. This part adds what a strategy owes on top of mechanics: how the migration coexists with a platform that never stops (Part 1.1), and when the migration itself may pause.

12.1 The dual track

From Phase 1 to Phase 4, the team runs two tracks against one codebase-becoming-four: the feature track (the platform’s ordinary improvement, at its baseline cadence) and the extraction track (small shippable moves, each byte-verified). The tracks share people, so their arbitration rule is written down: the feature track yields only to gate-critical extraction work, and the extraction track yields to production incidents and to the cadence canary (Part 1.4). When both tracks want the same week, the tie goes to the feature track — because a delayed extraction costs the future a little, while a stalled platform costs the evidence base everything (Part 1.1’s reasoning, applied at sprint scale).

12.2 Improvements during the migration land labelled

Every feature built during Phases 1–4 is born with its plane label (Phase 1’s gate made this a review habit) and written as if already extracted: instance values via configuration even while configuration still lives in the monolith, domain logic behind the seams the audit drew, nothing new crossing a boundary the extraction will have to re-cut. The migration thereby gets easier as it proceeds rather than harder — new code arrives pre-sorted, and the extraction surface shrinks from both ends.

12.3 When the migration may pause — and how it must not end

The migration MAY pause — for a production crisis, a funding gap, a staffing loss — because every extraction move ships independently and the codebase is coherent at every intermediate state (FORGE-101 Part 16.2’s every-move-ships discipline exists precisely to make pausing safe). What the migration MUST NOT do is end silently: dissolve into a permanent half-state where the strangler neither finishes nor is called off. The defence is the gates themselves — each phase’s gate is either passed, in progress, or formally suspended by a recorded decision with a revisit date. “We’ll get back to it” is not a state this roadmap recognises; suspension is a governance act with a name on it, like every other act in this project.

Part 13 — BioHPC: The Validation Instrument

13.1 What BioHPC is, architecturally

BioHPC is the second production Forge Instance and the first composition — the first time forge-core and forge-hpc are assembled by a manifest that is not Mjolnir’s. Its constitutional role was fixed by FORGE-101 (Part 4.6: generality is unproven until the second instance ships; migration Phase 6: the acceptance test): BioHPC is the experiment that decides whether Forge HPC is a domain or merely Mjolnir’s codebase wearing a general name. No amount of internal review substitutes for it; the architecture’s authority ends where the evidence begins, and BioHPC is the first evidence (FORGE-101’s closing words, now with a schedule).

13.2 When BioHPC begins — the entry criteria

BioHPC’s composition work begins when, and only when: the Phase 4 gate is fully closed (the MVP exists; starting earlier contaminates the test — Part 4.4’s refusal); BioHPC’s institution has committed operationally (named operators, access to its Systems of Record, an owner for its authored content — an instance is a publication with an editor, not a deployment with a checkbox); and the Ghost Instance has rehearsed BioHPC’s shape as far as fixtures allow (its scheduler family, its identity provider type), so that composition day starts from informed expectations rather than discovery.

The date this yields is not this document’s to promise — it couples to another institution’s calendar, which is itself a finding: the roadmap’s critical path runs through a commitment the team does not control (Evidence Ledger A4; risk R3). The mitigation is sequencing freedom: if BioHPC’s commitment slips, Rubus (Part 14) can be pulled earlier as a weaker-but-available second composition, explicitly recorded as rehearsal evidence, not proof — the acceptance test’s constitutional weight stays reserved for a real second instrument with real readers.

13.3 The test, and what counts as failure

The acceptance test is FORGE-101 migration Phase 6, verbatim: zero changes to Forge Core; domain changes limited to new adapter families/members, bindings, or declared options that BioHPC’s genuinely different reality requires; everything else is a misplacement, fixed by relocation. Three clarifications the test’s execution will need:

13.4 What BioHPC must not become

13.5 The evidence BioHPC yields

For the Evidence Ledger: the pass/fail of the acceptance test (A4, A5); the first measured time-to-instance (input to the Cold-Start bound, Part 5.3); the misplacement log (the audit’s error rate, A1); the configuration schema’s growth profile (how much of “instance” was actually enumerable in advance, A3); and the first data on operating two instances from one small team — the support-load prototype that Part 17’s economics extrapolate from. BioHPC is, deliberately, the single most information-dense event on this roadmap; the phases before it exist to make its evidence clean, and the phases after it spend what it proves.

13.6 BioHPC and genomics — the deferred second pull

BioHPC’s science will eventually want what its name implies: sequencing reality — samples, runs, pipelines — that Forge HPC rightly does not speak. That want is the expected origin of the second domain (Part 15.3), and it is deliberately deferred out of Phase 5: BioHPC ships first as a pure Forge HPC instance, its genomics-shaped needs recorded as evidence rather than met on the spot. When the composition has passed and 1.0 has hardened the ground, that recorded evidence is precisely the committed-instance demand that ADR-027 requires a new domain to have — the roadmap’s phases feeding each other by design: Phase 5’s restraint becomes Phase 8’s mandate.

Part 14 — Rubus: The Third Instance

14.1 What Rubus proves that BioHPC cannot

BioHPC proves the architecture generalises. Rubus proves it routinises — that the second success was the architecture working, not the founding team performing heroics through the composition seams they themselves cut. The distinction matters because heroics do not transfer, and Phase 7 is entirely about transfer. Rubus’s constitutional role is therefore the dress rehearsal for external adoption: the Cold-Start Test’s first arm’s-length execution (Part 5.3), run where the stakes are still recoverable.

14.2 When Rubus is natural — the entry criteria

Rubus becomes the natural next instance when: BioHPC’s proof period has closed (its lessons relocated, its misplacement log resolved); the adoption playbook exists in draft (Phase 6 has begun); forge-hpc covers Rubus’s source systems within existing adapter families, or the gap is honestly scoped as ordinary domain work; and — the criterion that makes Rubus a rehearsal rather than a third performance — people who did not build Forge are available to build it. Rubus done by the founding team is just BioHPC again with less to prove; Rubus’s value is proportional to the builders’ distance.

14.3 The dress-rehearsal rules

14.4 What Rubus must not be allowed to do

Rubus must not wait indefinitely for a perfect moment (if no third internal instrument materialises on schedule, the Ghost Instance can host the cold-start rehearsal at reduced fidelity — recorded as such); must not force premature capability (a Rubus need that requires new domain work is ordinary evidence on the ordinary bar, not a rehearsal-blocking emergency); and must not inflate into a flagship (Rubus is deliberately the least dramatic instance in this document — its success criterion is that nothing about it is interesting except the journal).

Part 15 — How Future Domains Emerge

15.1 The law, restated as roadmap

ADR-027 and FORGE-101 Part 4.6 already bind this: domains are created only for committed instances; generality is proven only by the second instance; speculation is forbidden. The roadmap adds the operational sequence and the cultural defences, because the pressure to speculate will arrive dressed as opportunity — a conference talk goes well, an imaging facility expresses interest, a funder asks “could this do earth observation?” The answer to all of these is the same, and it is neither yes nor no: “commit an instance, and the domain becomes buildable.”

15.2 The domain birth sequence

Every future domain follows the same five steps — no exceptions, including for domains the founding team itself wants:

  1. A committed instance exists: an instrument, an institution, named operators, access to Systems of Record, an editorial owner. Interest is not commitment; a letter is not commitment; a budget line and a person are commitment.
  2. The instance’s platform runs first, narrow and real — on Forge Core plus whatever existing domains genuinely fit, its unmet practice needs accumulating as recorded evidence in production, not as workshop output. (The proving-ground doctrine of Part 1, applied at domain scale: the new domain’s content is extracted from this running reality, exactly as Forge HPC was extracted from the HPC Analytics platform.)
  3. The extension package is proposed and ratified (Part 8.4) — the domain’s language enters the shared ontology’s registry before its code stabilises, because meaning governs construction (the precedence chain, honoured at every scale).
  4. The domain repository is born carrying the extracted adapters, modules, and templates — at which point it serves exactly one instance and claims nothing more (its README says so, in those words).
  5. The second instance ships and passes the acceptance test — and only then does the ecosystem call the domain proven, list it in the adoption offer, and seat it in governance (Part 8.3).

15.3 The expected order — a forecast, labelled as one

In the tradition of Principle 3, a prediction with its method shown: Forge Genomics is the likely second domain, because its committed instance already exists inside the family (BioHPC, Part 13.6) and its arrival exercises the two mechanisms the architecture most needs proven — cross-domain composition on trunk objects and the promotion of a shared concept (Sample, FORGE-101 Part 9.2’s predicted first promotion). Beyond that, this document forecasts nothing: FORGE-101 Part 17’s six walked-through futures (imaging, EO, lab, collections, climate) remain what they were — demonstrations that the architecture could absorb them at zero Core cost, never commitments that it will. The candidate list is not a queue. There is no queue. There are only committed instances, or their absence.

15.4 Domain communities

A proven domain’s long-term home is its practice community (FORGE-101 Part 13.2’s co-ownership aspiration; Part 9.3’s contributor path). The roadmap’s honest expectation: community co-ownership arrives slowly and unevenly — HPC operations has a strong existing culture of shared tooling and is the best case; other practices may never volunteer-maintain and will need the consortium economics of Part 17.4 instead. Both are acceptable end states. What is not acceptable is a domain whose maintenance story is unexamined hope — that is an orphaned promise at ecosystem scale, and Part 9.2’s rule against silent orphans applies to whole domains as to single modules.

Part 16 — The Community Roadmap

16.1 The four communities

Forge’s “community” is four distinct populations with distinct needs, and addressing them as one audience would serve none:

  1. Readers — the public of each instance: researchers, students, funders, ministers, the curious (FORGE-002 Part 6’s cast). They are served by instances, not by the project; the project’s obligation to them is discharged entirely through the constitution’s promises (truth, honesty, privacy, permanence). Readers are not recruited. They arrive, or the instrument’s account has failed on its own terms.
  2. Operators — the people who run instances and author their Records: HPC staff, facility engineers, the authors of maintenance events and incident resolutions. The platform’s honesty about their work (FORGE-002 §1.3’s “overdue fairness”) makes them its natural first constituency, and the roadmap treats them as such: operators are the most credible advocates an infrastructure project can have, and the only advertising this project will ever do well is operators showing other operators their instrument’s Record.
  3. Practice communities — the eventual co-owners of domains (Part 15.4): scheduler experts, sequencing-core managers, the people who know what a practice’s truth looks like.
  4. Adopter institutions — the architects, directors, and lawyers who decide to run an instance, and the staff who then join population 2.

16.2 Community actions, phase-aligned

16.3 Communication is a public record

The project communicates in its own constitutional register: dated, factual, provenance-carrying artifacts — journals, records, measurements, amendments — on its own domain, permanent at their URLs. No engagement metrics, no growth targets, no launch theatre. The style is not modesty; it is selection: the institutions Forge needs are precisely the ones that trust a project whose announcements read like its Record, and the audiences repelled by that register were never going to run an instrument’s public account anyway.

Part 17 — Sustainability, Maintenance, and Funding

17.1 The maintenance economics of the planes

The planes have structurally different maintenance profiles, and sustainability planning starts from that asymmetry rather than a blended average:

17.2 The editorial line, honoured

FORGE-100’s Final Review named editorial capacity the project’s single largest existential risk and demanded the roadmap include a staffing line for it. This document complies, in three commitments: (1) every instance’s adoption checklist includes a named editorial owner — an instance without one is an instance that will pass the composition test and rot anyway, and the playbook says so on its first page; (2) domain knowledge templates are the strongest structural relief available (judgment written once per practice, FORGE-101 Part 4.2) and their coverage is a tracked domain-health metric, because every template is an instance-editor’s workload halved; (3) the project’s own editorial obligations — the handbooks, the journals, the governance records — carry named owners in the governance registry from Phase 6, budgeted as work, not squeezed from margins. What this document cannot do is conjure the writers (FORGE-100’s confession stands); what it can do is refuse every plan that pretends they are free — and it does.

17.3 Bus factor and succession

Stated without flinching: today the project’s bus factor approaches one, and Phases 1–5 will largely be executed in that condition. The mitigations are the ones actually available to a small project, deployed fully: the constitution is the succession plan (five documents written explicitly for the maintainer who never met the author — the corpus’s stated reader); every decision recorded with reasons (governing-in-public, Part 8.2); mechanical enforcement that does not require the founder’s taste to hold the laws (Part 4’s firewalls); and, from 1.0, a hard governance target — no plane with a bus factor of one — met through the contributor path (Part 9.3), the council (Part 8.3), and hiring as funding allows. Until that target is met, the continuity statement (17.6) is the honest interim answer, and it is published rather than whispered.

17.4 Funding possibilities

Forge is infrastructure for publicly funded science; its funding model is the same as its instruments’ — grants, institutional budgets, and consortium shares — and the roadmap treats funding as a portfolio matched to phases. Named instruments below are illustrative of category, not commitments:

17.5 What funding must never buy

The laws are not for sale: no funder acquires a private object type, an instance-logic exemption, a Core special case, or a governance seat outside Part 8.3’s composition. Funding buys capacity — maintenance, documentation, audits, editorial work — and is acknowledged in the project’s record like any provenance. A grant whose deliverables would violate an ADR is declined with a citation, and the citation is this sentence.

17.6 The abandonment plan is a feature

A project whose constitution promises graceful abandonment (FORGE-001 Principle 8) owes its adopters the project-level version: published with the adoption offer, the continuity statement specifies that if development ends — funding lost, team dissolved — every instance keeps operating on its pinned versions indefinitely (compositions are reproducible; nothing phones home); every published record remains complete and readable forever with zero running services (ADR-009; the constitutional design doing its deepest work); the license permits any survivor coalition to continue maintenance (Part 9.5); and the constitutional repository remains, so that what the survivors inherit includes the reasons. Forge is very possibly the only platform category where the vendor-death scenario is a designed, tested, published behaviour — and that fact belongs in the adoption offer’s first conversation, because it is the strongest trust argument the project has.

Part 18 — Risks and Mitigation

The consolidated register. Each risk names its live phases, its mitigation, and — the register’s real purpose — its early signal: the observable that says the risk is materialising while the response is still cheap. Risks already treated in depth elsewhere are indexed, not repeated.

# Risk Live in Early signal Mitigation
R1 Extraction tax stalls the platform — migration eats the proving ground’s cadence 2–4 Cadence canary below baseline two consecutive months Slow the migration, never freeze the platform; small shippable moves (Part 1.4, 12.1)
R2 The perpetual strangler — migration pauses dissolve into a permanent half-state 3–4 A phase gate untouched for a quarter with no recorded suspension Gates are passed, in-progress, or formally suspended with revisit dates (Part 12.3)
R3 BioHPC slips or decommits — the proof loses its subject 4–5 Institutional commitment criteria (13.2) unmet as Phase 4 closes Rubus pulled earlier as rehearsal evidence; acceptance test’s weight reserved for a real second instrument (Part 13.2)
R4 Core absorbs domain logic — the gravest architectural erosion 3–∞ Vocabulary-firewall exceptions requested; Core churn rising post-1.0 The Core test in review; mechanical firewalls; Part 6.1’s churn expectation as audit trigger (FORGE-101 Part 3.4)
R5 Ceremony without benefit — three repositories, one mind; discipline erodes before it pays 3–5 Law-checker overrides; “temporary” cross-repo shortcuts Enforcement by CI, not willpower; named plane owners even when names coincide (Part 8.2; FORGE-101 unknown 5)
R6 Support drowns the team at adoption 7 Support hours/adopter/month exceeding the sustainability envelope One adopter at a time; honest latencies; every incident fixes the docs (Part 4.7)
R7 Funding gap between grants — typically years two–three 3–6 17.4’s portfolio showing single-source dependence for two+ quarters Portfolio across categories; instances self-funding structurally; the migration pausable without damage (R2’s discipline)
R8 Privacy incident — re-identification through aggregation; the risk most likely to harm a person all Adversarial-suite findings; audit findings; near-miss reports ADR-017 machinery + standing adversarial tests (11.6) + external audit at 1.0; fail-closed everywhere (FORGE-100 Part 11.5)
R9 Editorial starvation — surfaces tended by nobody; the mausoleum outcome all Template coverage falling; instance Records going quiet; stale upkeep owners The editorial line (17.2); loud failure over silent rot (FORGE-100 Part 7.4); shrink promises rather than fake them
R10 Upstream source churn breaks adapters faster than maintenance absorbs all Golden-recording diffs arriving faster than they are resolved Domain plane pools the cost across instances (17.1); ADR-014 makes breakage visible staleness, never wrong data
R11 Governance fails — capture, stall, theatre, or zeal 4–∞ Part 8.5’s four signatures, each named there Staged governance sized to reality; recorded reasons; windows tracked as promises (Part 8)
R12 The assistant arrives before FORGE-004 — a demo outruns the constitution 6–8 Any assistant prototype in any plane’s branch FORGE-004 scheduled at Phase 6, before external adopters ask; the interim prohibition of FORGE-101 unknown 6 is law until then

Two risks deserve prose beyond their table rows, because they are the ones this document judges most likely to actually happen:

R5 is the near-term one. For roughly two years, every boundary this corpus has drawn will be maintained by the same few people it constrains, and constitutional discipline without an external beneficiary feels like theatre precisely when it is being load-tested. The defence that will actually work is not resolve but automation: every law that matters is CI by the phase that creates it, so that the discipline holds on the team’s worst week, which is the only week that counts.

R9 is the long-term one. FORGE-100 said it and this roadmap repeats it with a schedule attached: the architecture can guarantee truth; it cannot guarantee hospitality. Five years from now the difference between a living ecosystem and a beautifully-machined mausoleum will be whether the Records are authored, the templates tended, and the stories written. Every structural relief this document can deploy, it has (17.2); the rest is a standing obligation on every phase’s budget, and the register exists so nobody can say it went unnamed.

Part 19 — Success Criteria

19.1 The gates are the criteria

Forge’s primary success criteria are Part 4’s gates, verbatim — passed in order, each verifiable by an outsider. A year-three review of this project SHOULD consist of opening this document to Part 4 and asking, gate by gate: passed, in progress, or suspended with a recorded reason? Any answer is compatible with a healthy project except the unrecorded kind.

19.2 The ecosystem measures

Beyond the gates, the standing measurements — each chosen because it reads a constitutional property off reality, and each published in the project’s record at a stated cadence:

19.3 The measures Forge refuses

Consistent with FORGE-002’s retirement of vanity genres, the project does not steer by: adoption count as a target (the vision is a handful, deep — Part 2.1; ten shallow instances would be a worse year five than four real ones), traffic or engagement (the platform does not surveil readers — Part 11.7 — and the project does not either), stars and mentions (selection effects, Part 16.3), or feature count in any plane (features are views; views are free; counting them measures nothing but appetite). The refusal is itself a criterion: a steering meeting that reaches for a vanity metric is a steering meeting that has run out of gates, and should read Part 4 again.

Part 20 — The First Five Years

What follows is a forecast, and it obeys the platform’s law for forecasts: labelled, method stated, error bars acknowledged. The method is Parts 1–19 run forward at their indicative pace; the error bars are the Evidence Ledger’s unknowns, any one of which can stretch a year into two. This is the pencilled future of FORGE-003 Part 4 — visibly lighter than the inked past — written so that year five has something specific to be audited against (Part 2.2 is the checklist; this is the texture).

Year one is invisible. The platform ships features all year, and its readers notice nothing else. Underneath: the audit closes its dispute log; the byte-equivalence harness catches its first real non-determinism and earns its keep; Mjolnir becomes a configuration document; the Ghost Instance builds for the first time — an empty, fictional instrument publishing a coherent account of nothing, which the team finds unreasonably moving. By year’s end forge-core exists and the platform consumes its 0.x releases. Nothing about the year would make a conference talk, and that is the year working as designed.

Year two is the crossing. Forge HPC is extracted; the hpc: extension package becomes the governance process’s first live fire, and the process is resized within the month based on what it was actually like. The old repository is archived with an authored retirement event that a handful of people read like an obituary — the platform’s own Record now contains its reconstruction. The MVP exists: three repositories, one production instrument, identical bytes. Then the year’s real event: BioHPC composes. The misplacement log is not empty — the honest expectation is a bruising first fortnight as reality names what the audit missed — and every entry is resolved by relocation with the law’s full stubbornness. BioHPC enters production; for the first time, a Forge Instance exists that Mjolnir’s builders did not hand-assemble.

Year three is the hardening. The unglamorous year: contracts to 1.0; one deliberate deprecation opened and honoured to the day, mostly to prove the windows are real; the privacy audit, whose findings are recorded rather than survived; the handbooks written against contracts that finally hold still; FORGE-004 drafted — the assistant constitution written years before any assistant, which future maintainers will recognise as the corpus’s habit of paying for things before they are wanted. Rubus runs the cold start at arm’s length, and the journal is published with its worst afternoon intact. Late in the year, the seven claims are audited by someone who did not produce them, and Forge 1.0 is declared in a Deployment event of eleven unexciting lines. The team notes that the declaration changed nothing operationally, which is precisely what made it safe to make.

Year four is the stranger. An institution the founding team has never worked at composes an instance from the playbook. It goes slower than Rubus and faster than feared; the support channel’s honest latencies hold; three playbook defects are found and fixed; the adopter’s scheduler variant lands in forge-hpc as the first external contribution, and its author becomes the first co-maintainer whose office nobody on the founding team could find on a map. Meanwhile BioHPC’s accumulated genomics evidence — two years of recorded, unmet, real needs — crosses ADR-027’s bar, and the second domain begins its birth sequence not as an idea but as an extraction from a running instance’s proving ground. The doctrine of Part 1, which was written about one platform, turns out to be the ecosystem’s permanent metabolism.

Year five is the ecosystem, if the word is earned. Forge Genomics passes its own second-instance test; BioHPC recomposes as the first two-domain instance, and the Job that is both a batch computation and a sequencing run gets its presentation collision resolved from the real case, as FORGE-101 said it must be. Sample begins its promotion — the first concept to move radius since the trunk was ratified, setting the precedent everyone knew it would. The council has refused at least one thing and been appealed at least once, and both records read as boring as governance should. Core has had two quiet quarters, which Part 6.1 taught everyone to read as health. Somewhere, a facility operator shows a colleague from another institution their instrument’s Record — the incident from March, its resolution, the name of the engineer who fixed it at 03:40 — and the colleague asks the only marketing question this project ever wanted to provoke: how do we get one of these?

And through all five years, on a Tuesday in November at 01:40, a researcher whose job failed opens a page that tells the truth about what happened, with its age shown, and never learns or cares that the platform beneath it was rebuilt from one repository into an ecosystem while it served them. That continuity — the unwatched hours undisturbed across the entire reconstruction — is the roadmap’s real acceptance test, and it is the one gate that is checked every single day.

Part 21 — New Architectural Decision Records

Continuing the series (ADR-001–017 in FORGE-100; ADR-018–027 in FORGE-101; all stand unchanged). Five roadmap-era decisions, deliberately few, each recording why for the future maintainer who will otherwise repeal it by convenience.

ADR-028 — The Extraction Doctrine. Development of the proving-ground platform never stops; Forge capability is extracted from proven production reality, never designed in isolation; invention happens at the narrowest plane that can express it and generalises only on evidence; the Extraction Tax is bounded by the platform’s improvement cadence, and the mandated response to an excessive tax is slowing the migration, never freezing the platform. Exists because every pressure of the next five years — deadlines, funding milestones, enthusiasm — will argue for either freezing the platform or designing ahead of evidence, and both must be refusable by citation. (Part 1.)

ADR-029 — Gates, Not Dates. Roadmap phases are bounded by verifiable gates; a phase ends when its gate’s conditions are demonstrably true, never on a calendar; indicative durations bind nothing; a stalled gate is passed, in progress, or formally suspended by recorded decision with a revisit date — no other states exist. Exists because date-driven phase transitions are how architectures ship unproven, and because the silent half-abandoned migration (R2) must be constitutionally impossible rather than merely embarrassing. (Parts 4.0, 12.3.)

ADR-030 — Forge 1.0 Is Seven Evidenced Claims. 1.0 is declared only when the seven claims of Part 3.2 are simultaneously true with cited evidence, audited by someone other than the evidence’s producer, and recorded; 1.0 adds no features, and a feature proposed for 1.0 is misfiled. Exists because the pressure to declare on enthusiasm will peak exactly when Phase 5 succeeds, and the checklist must outrank the mood. (Part 3.2, Part 4.6.)

ADR-031 — No Adoption Before the Cold Start. External adoption is not offered before 1.0; the offer requires the Cold-Start Test passed at arm’s length with a published, evidenced time bound; founding-team keyboard interventions during any cold start are recorded defects against the adoption surface; the test is re-run at every major Core version. Exists because an adoption offer is a living promise (Principle 11 applied to the project itself), and because the difference between “works for us” and “safe for you” is precisely the distance this ADR forbids skipping. (Parts 5, 14.)

ADR-032 — Sustainability Is a Gate Condition. No plane artifact ships without a named upkeep owner; no instance is adopted without a named editorial owner; contributions without upkeep owners are adopted explicitly or declined; from 1.0, no plane may rest at bus factor one without a recorded succession arrangement; the continuity statement (the project-level abandonment plan) is published with the adoption offer. Exists because the corpus’s largest named existential risk is maintenance capacity, and a roadmap that gates only on function while assuming upkeep would be repeating FORGE-001’s original sin — spending promises like a lottery winner — at ecosystem scale. (Parts 9.2, 17.)

Final Review — Unknowns, Risks, and the Evidence Ledger

The corpus’s tradition, continued: what this document has decided is above; what it cannot know, and must not pretend to, is below. A roadmap’s particular obligation is stronger than its predecessors’ — FORGE-100 and FORGE-101 described structures whose truth their own coherence could partly argue; a roadmap describes the future, whose truth nothing but arrival can argue. So this review is built around the Evidence Ledger: every major assumption the roadmap rests on, bound to the evidence that will confirm or refute it, the phase where that evidence arrives, and what the plan does if the assumption fails.

The biggest risks, ranked

In this document’s judgment, the three risks most likely to determine the project’s fate, in order:

  1. Capacity, in both of its forms (R5 near-term, R9 long-term). The plan asks a very small team to run a production platform, execute a multi-year extraction, and observe constitutional discipline whose beneficiaries mostly do not exist yet — and then asks the resulting ecosystem to fund writing, forever. Everything mechanical that can carry this load has been made mechanical; the residue is human, and the roadmap’s honest position is that it has bounded this risk (cadence canary, CI-enforced law, editorial gates) without eliminating it, because it is not eliminable by documents.
  2. The second-instance dependency (R3). The architecture’s central claim is only provable by BioHPC, and BioHPC’s commitment belongs to an institution, not to this plan. The mitigation (Rubus as rehearsal, evidence-weight reserved) is real but partial: a roadmap whose proof depends on someone else’s calendar has a critical path it does not own, and says so.
  3. The funding trough (R7). The extraction’s value is largest exactly when it is least demonstrable — years two and three, after the investment and before the external validation. The portfolio of 17.4 is designed for this shape, and the migration’s pausability (ADR-029) is the shock absorber; but a long trough would stretch every indicative duration in Part 4, and the gates would hold while the calendar slid.

The Evidence Ledger

# Assumption Evidence that tests it Arrives If it fails
A1 Three plane labels are exhaustive and adjudicable — every component of the real platform is core, domain, or instance The audit’s dispute log; later, BioHPC’s misplacement log Phase 1; re-tested Phase 5 A component genuinely needing two planes’ knowledge is a FORGE-101 amendment case — the architecture is debugged, not defended (FORGE-101 Preamble’s own standard)
A2 Byte-equivalence is achievable — the platform’s builds can be made fully deterministic The harness on two consecutive production releases Phase 1 gate Declared semantic-equivalence rules per artifact class, exceptions recorded and reviewed; the migration proceeds on a weaker but still mechanical check (Part 11.1)
A3 Instance knowledge is finite and enumerable — Mjolnir can become pure data The Ghost Instance building clean; the configuration schema’s growth profile at BioHPC Phases 2, 5 Residual “instance logic” is, by ADR-020, a missing domain/Core capability — each finding relocates; a systemic failure would mean the no-logic rule needs a declared escape hatch, which is a constitutional amendment argued then, not padded for now
A4 Forge HPC generalises — the domain extracted from Mjolnir fits a second real HPC instance with only sanctioned change The BioHPC acceptance test Phase 5 Relocation and re-test (Part 13.3); a deep failure (Core changes unavoidable) reopens FORGE-101’s plane boundaries with the best possible data in hand
A5 An instance can live with no logic, indefinitely BioHPC and every later instance, mechanically verified at every composition Phase 5 onward, continuous See A3; the pressure valve is domain options, and the ledger tracks whether the valve suffices
A6 The Extraction Tax is payable — migration and cadence can coexist in one small team The cadence canary against baseline, monthly Phases 2–4 Slow the migration (ADR-028); if even the slowed migration starves, the formal-suspension mechanism (ADR-029) preserves coherence until capacity returns
A7 The ontology and contracts survive contact with genomics — the second domain fits the trunk-and-extensions model, and cross-domain composition works on trunk objects Forge Genomics’ ratification; the two-domain BioHPC composition; the Sample promotion Phase 8 Trunk amendment on evidence (FORGE-101 Part 13.5 always expected one or two); a failure of composition itself would be the corpus’s deepest architectural finding and is exactly why Phase 8 precedes any wider ambition
A8 Strangers can adopt from documents — the cold start works without the founding team Rubus’s journal; the first external adoption Phases 6, 7 Defects fix the adoption surface and the bound is re-published honestly; a systemic failure means the offer narrows (assisted adoption, honestly priced) rather than the promise inflating
A9 Practice communities will co-own domains The contributor path’s actual traversal; forge-hpc’s maintainer roster at year five Phases 7–8 The consortium model (17.4) funds what volunteerism doesn’t — an acceptable end state, planned for, not a surprise
A10 Funding exists for a runtime nobody buys The portfolio’s actual yield across 17.4’s categories Phases 3–7 The migration pauses without damage (ADR-029, R2’s discipline); instances remain self-funding; the record remains durable regardless — the failure mode is slowness, never data loss, by construction
A11 Governance sized-to-reality works — custodial discipline now, council legitimacy later The first ratification (Phase 4); the first refusal and first appeal (by Phase 8) Phases 4–8 Governance is the most amendable layer in the corpus — its failure modes are named in advance (8.5) precisely so that redesign cites symptoms, not vibes

What this document does not know, and could not

Three honest confessions beyond the ledger’s reach:

Closing judgment

FORGE-100 proved the vision constructable. FORGE-101 proved the construction shareable. FORGE-102’s claim is the humblest and the most falsifiable of the three: that there is an order of work — extraction from a living platform, proof by a second instance, promises only after evidence, domains only from commitment — under which a small team, without stopping the platform its readers already depend on, can turn one instrument’s account into an ecosystem’s runtime; and that every step of that order can be gated on evidence an outsider can check.

The roadmap’s deepest design choice is that it is built to be survived by its own failures. A late BioHPC, a funding trough, a paused migration, a domain nobody volunteers to maintain — each has a named response that preserves the record, the platform, and the option to continue. The one failure it refuses to survive gracefully is dishonesty about its own state: every gate, every suspension, every declaration is a recorded, citable fact, because a project whose product is an instrument’s honest account of itself must be, before anything else, an honest account of itself.

The roadmap’s authority, like its predecessors’, ends where the evidence begins. Phase 1’s audit is the first evidence, and it can begin tomorrow.

— End of FORGE-102.