FORGE-101 — The Runtime Architecture of Project Forge

FORGE-101 — The Runtime Architecture of Project Forge

Project Forge — Second Engineering Document Status: Architectural Constitution (normative). Extends FORGE-100; implements FORGE-001, FORGE-002, FORGE-003. Precedence: FORGE-002 governs meaning; FORGE-100 governs construction; FORGE-101 governs composition — how constructed parts are organised into a runtime, domains, and deployments. FORGE-101 MUST NOT contradict its predecessors; where a reading of this document appears to contradict them, the reconciling reading governs, and an unreconcilable sentence is a defect in this document, to be amended.

Preamble

The founding trilogy defined what Forge means. FORGE-100 proved it constructable: a unidirectional pipeline from reality to reader, in which a fact is stored exactly once and everything a reader sees is a pure function of stored facts and identity.

This document exists because of a realisation that FORGE-100 anticipated but did not name.

FORGE-100’s Preamble already declared: “Forge is an architecture, not an application. Mjolnir is the first implementation, not the subject.” But the working assumption throughout the project’s first year remained that Project Forge was building an HPC Analytics platform, of which Mjolnir was the destination. That assumption is now retired:

Project Forge is not an HPC platform and not a framework for building one. Project Forge is the runtime for scientific platforms. The HPC Analytics platform is the first production domain implemented on Forge. Mjolnir is the first Forge Instance. BioHPC will be the second. Systems not yet imagined must be implementable without changing Forge Core.

FORGE-100 drew one seam — the Implementation Layer (Part 2.9) — between the instrument-neutral core and everything specific. That seam was drawn in the right place, but with one line where two were needed. “Everything specific” turns out to contain two different kinds of knowledge that change at different rates, are owned by different people, and are reused at different scopes:

Collapsing these into one layer produces a forced error the moment a second instance appears: either BioHPC rewrites the scheduler adapters and queue projections Mjolnir already built (duplication — the cardinal bug of FORGE-002 §3.6 applied to code), or those adapters migrate “down” into the shared core, and the core learns what a scheduler is — at which point the telescope facility of FORGE-100 Part 13.3 inherits scheduler code it can never use and never delete. Both failures are slow, both are fatal over a decade, and the only structural cure is a third layer.

This document therefore defines the three-plane architecture — Forge Core → Forge Domain → Forge Instance — and everything that follows from it: what modules and services are, where entities live, how the planes communicate, what may depend on what, how the repository is organised, how today’s HPC Analytics platform maps into the planes, and how it migrates there without disrupting production.

The reader this document is written for is the person who arrives in five years knowing nothing about Mjolnir, nothing about BioHPC, nothing about HPC — wanting only to build a scientific platform on Forge. Every part below should tell that reader exactly how the architecture works and exactly what they must write, what they inherit, and what they are forbidden to touch.

Terminology and naming discipline

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

Two naming collisions must be disarmed immediately, because this document introduces runtime concepts whose natural names are already taken by the ontology:

New defined terms introduced here: Plane, Forge Core, Forge Domain, Forge Instance, Forge Module, Forge Service, Domain Extension Package, Manifest, Signal, Composition, Promotion.

Part 1 — From Platform to Runtime

1.1 What “runtime” means in Forge

The word “runtime” usually implies a request-serving process. Forge’s constitution forbids that reading: ADR-007 makes build-time projection and static delivery the default substrate, and FORGE-100 Part 12 defends it as the source of speed, durability, and abandonment-grace.

Forge Core is a publication runtime, not a request-serving runtime. It is the machinery that ingests reality, keeps canonical truth, freezes snapshots, derives projections, and publishes artifacts — plus the thin read-time shell (Interaction Layer) that composes published artifacts for a reader and surfaces private facets after sign-in.

“Running a scientific platform on Forge” therefore means: configuring the publication pipeline with a domain’s adapters and modules and an instance’s connections and policies, and letting it publish. The reader-facing result is still, deliberately, mostly static files. Nothing in this document weakens ADR-007; the query-service exception of FORGE-100 Part 12.3 remains the only sanctioned dynamic read path, unchanged.

1.2 What changes, and what does not

Nothing in FORGE-100 Parts 1–12 changes. The layers (Ontology → Truth → Publication → Knowledge → Derivation → Presentation → Interaction, with Identity orthogonal), the governing invariant, the contracts, the privacy architecture, the performance architecture — all stand, verbatim. This document calls those the strata, to distinguish them from what it adds.

What changes is FORGE-100 Part 2.9 and Part 13. The single orthogonal “Implementation Layer” is refined into two planes — Domain and Instance — and the adoption story of Part 13.4 (“a new instrument writes adapters and configuration”) is corrected to its true form: a new instrument in an existing domain writes almost nothing; a new domain writes adapters and domain modules once, for all its instances. FORGE-100 Part 13.3’s own mapping table was the evidence: it mapped four classes of instrument, not four instruments — and a class is precisely a Domain.

This is a refinement, not a contradiction. FORGE-100 Part 2.9 said the Implementation Layer “owns everything Mjolnir-specific, BioHPC-specific, telescope-specific.” FORGE-101 observes that “Mjolnir-specific” and “HPC-specific” are different words, and gives each its own home.

1.3 Why a runtime and not a framework

The distinction is enforceable, not rhetorical:

Forge chooses runtime because the constitution demands properties that only hard boundaries preserve: truth kept once (a framework extension can smuggle a second store; a contract-bound module cannot), implementation independence (Part 13 of FORGE-100 is only true if the core is unreachable from above), and abandonment-grace (published snapshots must remain readable when every extension is gone). Concretely: Forge Domains and Forge Instances do not subclass Forge Core. They supply declared, validated artifacts — adapters, extension packages, modules, configuration, content — across versioned contracts. If a domain needs to patch Core behaviour, Core has a missing capability, and the fix is a Core amendment, never a reach-in.

Part 2 — The Three Planes

2.1 Definitions

┌─────────────────────────────────────────────────────────────────┐
│  FORGE INSTANCE      a real deployment: Mjolnir, BioHPC, Rubus  │
│  "this one"          configuration · branding · connections ·   │
│                      policies · content — and no logic          │
├─────────────────────────────────────────────────────────────────┤
│  FORGE DOMAIN        the expertise of a scientific practice:    │
│  "this kind"         Forge HPC, Forge Imaging, Forge Genomics   │
│                      adapters · extension packages · domain     │
│                      modules · domain knowledge templates       │
├─────────────────────────────────────────────────────────────────┤
│  FORGE CORE          the permanent runtime: truth, publication, │
│  "any kind"          identity, search, presentation, loading —  │
│                      everything universal, nothing domainal     │
└─────────────────────────────────────────────────────────────────┘

2.2 Why exactly three

Each plane exists because it removes a real constraint; none exists for elegance. The planes separate along three axes at once, and the fact that all three axes cut in the same place is the argument that the separation is real:

  1. Rate of change. Core changes on a constitutional timescale (years; amendments). Domains change on the timescale of a scientific practice (months; a new scheduler version, a new pipeline convention). Instances change freely (days; a policy, a node purchase, a rebrand). Software that mixes rates of change forces its fastest-changing part’s release cadence onto its slowest-changing part’s stability guarantees — the classic failure of every “unified platform.”

  2. Who knows it. Core encodes what the Forge project knows (truth-maintenance, publication, privacy). A domain encodes what a practice community knows (HPC operations, imaging pipelines). An instance encodes what one institution knows (its machines, its policies, its people). These are different authors with different authority, and architecture that muddles them muddles accountability — the same argument FORGE-100 Part 4.6 makes for per-facet truth ownership, applied to code.

  3. Scope of reuse. Core is reused by every scientific platform. A domain is reused by every instance of its class. An instance is reused by nobody. Placing knowledge at the wrong reuse scope produces either duplication (too high) or contamination (too low), and both are named failures of the two-layer model (Preamble).

Why not two planes is answered in the Preamble: the second instance forces the error. Why not four deserves an answer too, because the temptation will arise (a “sub-domain” for Slurm-vs-PBS, an “institution” plane above instances sharing policy across a university’s clusters). The rule: within a domain, variation is handled by the domain’s own internal structure (adapter families, optional modules — Part 4.4); across instances, shared policy is handled by configuration inheritance inside the instance plane (Part 5.5). Neither needs constitutional standing. A plane earns constitutional standing only when it has its own author class, rate of change, and reuse scope — and only three of those exist.

2.3 What the planes are forbidden to know

These prohibitions are the constitution of this document. Each is stated with the failure it prevents.

The mirror-image permissions are equally constitutional: Domains depend on Core. Instances depend on domains and Core. Everything depends on the constitution (ontology + contracts). The full dependency law, with its graph, is Part 14.

2.4 The planes and the strata form a matrix

The strata of FORGE-100 (vertical flow of truth) and the planes of FORGE-101 (horizontal scope of knowledge) are orthogonal. Every piece of the system has a coordinate in both: which stratum does it serve, and which plane owns it? Part 6 draws the full matrix; the rule of thumb that generates it:

Core owns every stratum’s machinery. Domains own stratum content that is true of a class. Instances own stratum content that is true of one deployment.

The Truth Layer engine is Core; the fact that a Slurm sacct row becomes a Job facet is Forge HPC; the credential that reads Mjolnir’s Slurm is Mjolnir’s. Same stratum, three planes, no ambiguity.

Part 3 — Forge Core

3.1 What Forge Core is

Forge Core is the permanent, instrument-agnostic, domain-agnostic runtime: the concrete implementation of FORGE-100’s strata plus the composition machinery this document adds. It is the part of Forge that should still be recognisable in ten years, which is why its contents are defined by a test rather than a list:

The Core test: a capability belongs in Core if and only if (a) every conceivable Forge Instance needs it, (b) it can be specified without any domain vocabulary, and (c) it enforces or implements a constitutional principle. Failing any one of the three, it belongs in a domain or an instance.

3.2 What Forge Core knows

The universal concepts, organised by the strata they serve. Each entry is machinery, per Part 2.4 — Core provides the mechanism; planes above provide the content.

The truth spine (FORGE-100 Parts 3–4, 9–10):

The reader surface (FORGE-100 Parts 5–8, 12):

The gate (FORGE-100 Parts 2.8, 11):

The composition machinery (new in FORGE-101):

3.3 What Forge Core is forbidden to contain

Everything domain-specific, restated concretely because the temptations will be concrete: no scheduler concepts, no queue semantics, no biology, no astronomy, no microscopy, no genomics, no notion of GPU or basecall or exposure or sample, no predictive model of anything (Part 8.5 places prediction), no domain’s display vocabulary, and no instance’s anything.

The subtle exclusions matter more than the obvious ones:

3.4 The temptation Core must survive

The gravest long-term risk to this architecture is not a domain violating the rules; it is Core absorbing domain logic for convenience — because Core’s maintainers are closest to the machinery, and “we’ll just handle this in Core for now” is always locally cheaper. The constitutional defence: any Core change is reviewed against the Core test (3.1), and a Core capability that mentions a domain concept in its specification is rejected regardless of how many domains would benefit. If three domains need the same thing, the thing is abstracted first (specified domain-neutrally) and only then admitted. The Promotion rule (Part 7.8) provides the legitimate path; there is no other.

Part 4 — Forge Domains

4.1 What a domain is

A Forge Domain is the reusable middle: everything that is true of a class of scientific platform and false of others. Its relationship to Core, in one line each way:

Core provides infrastructure; domains provide expertise. Core knows how to keep truth about something; a domain knows what that something is for one scientific practice. Core without domains publishes nothing (it has no adapters, no vocabulary, no readers’ questions). Domains without Core are folklore (expertise with no truth machinery under it).

Illustrative domains (illustrations, not commitments — see 4.6): Forge HPC (shared computational infrastructure — the first production domain), Forge Imaging (microscopy, CryoEM), Forge Genomics (sequencing platforms), Forge Earth Observation, Forge Chemistry. The brief’s suggested “Forge AI” is examined and re-placed in Part 8.5.

4.2 What a domain contains

Five kinds of artifact, and only these five:

  1. Adapter families (Source → Truth). The domain’s knowledge of its class’s Systems of Record: what a Slurm accounting record is, how a PBS queue differs, how an instrument-vendor’s export format maps to ontology facts. Adapters are Forge Services (Part 8) written against Core’s ingestion contract. A domain ships families — the Slurm adapter, the PBS adapter — and an instance binds the ones its reality requires (Part 5.3).
  2. A Domain Extension Package (Part 4.3). The domain’s ratified additions to the ontology: extension object types, facet families on trunk objects, measure types with units and methods, event kinds, relation types.
  3. Domain Forge Modules (Part 7). The domain’s projections and views: the queue outlook, the fleet view, software usage shapes — expertise expressed as pure functions over published truth.
  4. Domain knowledge templates. Document and Story scaffolding written in the domain’s register with transclusion points ready (FORGE-100 Part 7): the “your job failed with an out-of-memory ending” document exists once, in Forge HPC, with instance facts transcluded per deployment. Judgment is authored once per practice, not once per institution.
  5. Domain vocabulary. Display labels, search synonyms, and unit conventions for the domain’s readers — the configuration content that Core’s labelling and search mechanisms consume (“Node” presented as “Compute Node” here, “Sequencer” there — FORGE-100 Part 13.3 already established labels are presentation, not ontology).

What a domain MUST NOT contain: truth stores of its own (Part 10.3), presentation machinery (it uses Core’s design system — a domain has an atmosphere within the visual grammar, never a costume outside it, per Principle 10), identity machinery, instance facts, or another domain’s anything.

4.3 Domain Extension Packages — the constitutional mechanism

This is FORGE-101’s one genuine amendment to prior law, and it must be handled with care because ADR-016 is explicit: “new object types require amending the shared ontology (constitutional); no instrument gets a private object type.”

FORGE-100 Part 13.5 already anticipated that new instrument classes would justify amendments, and insisted such types “enter the shared ontology or not at all.” FORGE-101 keeps that discipline and gives it structure:

The ontology becomes a trunk and ratified branches. The trunk is the sixteen objects, their relations, events, and measures — Core-owned, universal, amended as rarely as ever. A Domain Extension Package is a namespaced, versioned set of ontology additions (hpc:Accelerator, genomics:Sample, imaging:AcquisitionSession) proposed by a domain and ratified through the same constitutional amendment process as trunk changes, then owned by the domain but binding on all its instances.

The discipline this preserves, point by point:

Why this is an extension of ADR-016 and not its violation: ADR-016 forbade private types and accretion; it demanded amendment. Extension packages are amendments — namespaced, ratified, shared within their reuse scope. What FORGE-101 adds is only the recognition that “shared” has two legitimate radii: universal (trunk) and practice-wide (extension). A radius of one (instance) remains forbidden, exactly as before.

4.4 Variation within a domain

Domains face internal variation (Slurm vs PBS; short-read vs long-read sequencing) and MUST absorb it internally rather than leaking it upward or downward: adapter families cover source variation; optional domain Forge Modules cover capability variation; configuration parameters (declared, typed, documented) cover behavioural variation. If variation within a domain grows so deep that two sub-communities share almost nothing, that is evidence of two domains wearing one name, and the domain SHOULD split — a governance act, recorded, with both successors keeping the ratified extension types they genuinely use.

4.5 When two domains need the same concept

Forbidden: Domain A importing Domain B’s extension type. Required: promotion. If Forge Genomics and Forge Imaging both need Sample, then Sample is evidently not genomics expertise — it is a concept of laboratory science generally, and it is proposed for the trunk (or, if the trunk’s guardians judge it insufficiently universal, for a deliberately shared extension package owned jointly and ratified as such). The mechanism matters less than the rule it enforces: a concept lives at exactly one place in exactly one namespace, at the widest radius that genuinely needs it — FORGE-002’s one-home rule, applied to meaning itself.

An instance composing two domains (BioHPC = Forge HPC + Forge Genomics is the expected first case) is normal and requires no domain-to-domain dependency: each domain binds trunk objects and its own extensions; where their truths meet, they meet on trunk objects (a genomics Sample relates to a trunk Job; the HPC domain projects that Job without knowing samples exist). Composition happens in the ontology’s shared trunk, never in domain code. This is the load-bearing reason the trunk must stay rich enough to be the meeting ground — and a standing argument against over-eager extension.

4.6 No speculative domains

A domain is extracted from evidence, never invented ahead of it. A Forge Domain may be created only when a committed Forge Instance requires it, and its claim to generality is unproven until its second instance ships. Forge HPC is legitimate today because Mjolnir exists and BioHPC is committed. Forge Imaging is a name in this document, not a codebase, and MUST remain so until an imaging deployment is real. The graveyard of platform projects is full of frameworks generalised from zero examples; Forge generalises from one and verifies with the second (Part 16.6 makes BioHPC the formal acceptance test).

Part 5 — Forge Instances

5.1 What an instance is

A Forge Instance is one real deployment: the composition of Forge Core with one or more Forge Domains, plus everything true of this deployment alone. Mjolnir is the first. BioHPC will be the second. Rubus, future clusters, future laboratories follow the same shape. An instance is small — and its smallness is the measure of the architecture’s success: every line an instance contains is a line the next adopter cannot reuse, so the architecture succeeds exactly insofar as instances approach pure declaration.

5.2 What an instance contains

5.3 Configuration as contract

Instance configuration is not a folder of ad-hoc YAML. Core defines a typed configuration schema assembled from the declared parameters of Core, the composed domains, and the selected Forge Modules; the instance supplies values; composition fails loudly on unknown keys, missing required values, or type violations. Configuration values are themselves provenance-stamped (who set this floor, when) — the platform whose every fact carries provenance extends the same honesty to its own settings, because an aggregation floor is a privacy-bearing decision (ADR-017) and “who decided this?” must be answerable.

5.4 The instance is also an object of its own platform

An instance’s deployed composition — Core version, domain versions, module set, configuration (public facets thereof) — is recorded as Deployment events in its own Record (Part 3.2, Deployment). The platform accounts for itself: “what was running in March?” is a query, like every other question about the past (FORGE-100 Part 9.3). Instance-private configuration (credentials, obviously; policies where sensitive) is classified like any facet — the transparency gradient applies to the platform’s own account of itself.

5.5 Shared policy across sibling instances

When one institution operates several instances (a university with three clusters), shared policy is expressed by configuration inheritance within the instance plane — a base configuration document that sibling instances extend. This is data composition, not a new plane (Part 2.2), and it MUST NOT become one: a “university layer” with logic in it is a shadow domain, rejected by the same rule as 5.2.

Part 6 — The Matrix: Planes × Strata

6.1 The layered architectural diagram

The full picture — FORGE-100’s strata as rows, FORGE-101’s planes as columns. Every cell answers: what does this plane contribute at this stratum?

────────────────┬──────────────────────────┬─────────────────────────────┬────────────────────────────
   STRATUM      │  FORGE CORE              │  FORGE DOMAIN (e.g. HPC)    │  FORGE INSTANCE (e.g. Mjolnir)
   (FORGE-100)  │  machinery — universal   │  content — of the practice  │  content — of the deployment
────────────────┼──────────────────────────┼─────────────────────────────┼────────────────────────────
 Interaction    │ read-time shell: walk,   │ —                           │ —
                │ ask, scrub, sign-in      │                             │
 Presentation   │ design system, object    │ domain atmosphere &         │ wordmark, theme tokens,
                │ anatomy renderer, a11y   │ vocabulary (labels, units)  │ (constrained variation)
 Derivation     │ projection engine,       │ domain Forge Modules:       │ module selection +
                │ search engine,           │ queue outlook, fleet view,  │ parameters; no projections
                │ core Forge Modules       │ software intelligence, …    │ of its own
 Knowledge      │ transclusion & binding   │ domain Document/Story       │ instance Documents,
                │ machinery                │ templates (judgment, once)  │ Stories, translations
 Publication    │ Publisher, snapshot      │ —                           │ publishing cadence,
                │ format, time-addressing  │                             │ retention/coarsening policy
 Truth          │ Truth Store, identity    │ —                           │ —
                │ resolution, provenance   │                             │
 Ontology       │ the trunk (sixteen),     │ Domain Extension Package    │ — (forbidden)
                │ amendment machinery      │ (namespaced, ratified)      │
 Source         │ ingestion contract,      │ adapter families            │ adapter bindings:
                │ service harness          │ (Slurm, PBS, vendor X, …)   │ endpoints, credentials
────────────────┼──────────────────────────┼─────────────────────────────┼────────────────────────────
 Identity (⊥)   │ enforcement: (reader,    │ facet classifications for   │ identity provider,
                │ facet)→emit/occlude/agg, │ extension types             │ authorization mapping,
                │ fail-closed              │                             │ aggregation floors
────────────────┴──────────────────────────┴─────────────────────────────┴────────────────────────────

Empty cells are constitutional, not accidental: a domain contributes nothing to Truth machinery (it feeds truth through adapters; it never keeps it), an instance contributes nothing to the ontology (Part 4.3), and nobody but Core touches Interaction (the reader’s shell must be identical across every Forge platform on Earth — that uniformity is the product, per FORGE-002 §3.6 rule 3 scaled up: learn one Forge Instance, and you have learnt them all).

6.2 One flow, three plane-crossings

Truth still moves in exactly one direction (FORGE-100 Part 1.2). The planes do not add flows; they annotate ownership along the one flow:

 reality ──▶ Systems of Record          (external; instance's reality)
                │
                ▼  adapter family (DOMAIN) × binding/credentials (INSTANCE)
            Truth Store                  (CORE machinery; trunk + extension shapes)
                │  freeze (CORE)
                ▼
            Snapshots                    (CORE; the durable record)
                │  project: core modules (CORE) + domain modules (DOMAIN),
                │           parameterised by configuration (INSTANCE)
                ▼
            Published artifacts          (views, indices, receipts, documents)
                │  render (CORE design system; DOMAIN vocabulary; INSTANCE theme)
                ▼
            Reader                       (gated by Identity: CORE enforcement,
                                          INSTANCE provider, floors)

6.3 The composition lifecycle

The lifecycle of a Forge Instance, from declaration to retirement — the lifecycle diagram the brief requests:

   DECLARED      instance manifest exists: domains, modules, config
      │   compose: resolve versions, validate manifests, schema-check config,
      │            verify dependency law (Part 14) mechanically
      ▼
   COMPOSED      a reproducible, recorded composition (lockfile + Deployment event)
      │   first build: adapters ingest → truth → first snapshot → projections
      ▼
   PUBLISHED     the instance exists as a public record; readers arrive
      │   steady state: ingest → snapshot → incremental projection → publish,
      │   at the instance's declared cadence; observability watches every stage
      ▼
   EVOLVING      recomposition events: module added/retired, domain upgraded,
      │          policy changed — each a recorded Deployment event, each rebuilt
      │          deterministically, each reversible to the prior composition
      ▼
   DEGRADED      (entered and left automatically) a pipeline fails → affected
      │          surfaces show staleness or vanish (ADR-014); the Record steps
      │          forward; recovery is undramatic
      ▼
   ENDED         the instrument retires: final snapshot published, marked final;
                 the static record remains readable forever with zero running
                 services (ADR-007, ADR-009) — the instance ends; its account
                 does not vanish. Objects end but never vanish (§3.6 rule 1),
                 and an instance is no exception.

Part 7 — Forge Modules

7.1 Definition

A Forge Module is a versioned, manifest-described unit of derivation-and-presentation capability that consumes published truth and knowledge through Core’s contracts and contributes projections, view models, routes, knowledge bindings, and search vocabulary — owning no truth, holding no durable state, and knowing nothing of its instance.

In FORGE-100’s terms: a Forge Module is a bundled set of Projections (Part 5) with their presentation, packaged for composition. Everything FORGE-100 says about views therefore applies: pure, deterministic, regenerable, disposable, owning nothing. The Forge Module is the unit in which views are shipped, versioned, selected, and retired — the packaging FORGE-100 Part 5 implied but did not name.

Modules exist at two planes: core modules (universal capability: the object anatomy pages, the Record browser, the Ledger projection, search) and domain modules (practice capability: the queue outlook, the fleet view, software intelligence). Instances select; they do not author (Part 5.2). There are no instance modules — the pressure that seems to demand one is, every time, a missing domain option or a missing Core capability, and Part 7.8 gives the pressure a legitimate outlet.

7.2 The manifest

Every Forge Module declares, machine-readably:

7.3 Discovery

Discovery is declarative and closed at composition time. The instance manifest names its domains; domains and Core publish module catalogues; the instance selects from the union. There is no runtime plugin scanning, no dynamic marketplace, no module arriving after the build — because every module is a promise (Principle 11), and promises are made deliberately, in a recorded composition, not discovered at midnight. Core discovers everything — domains and modules alike — solely through manifests presented at composition; this is what keeps Core free of any compiled-in registry of names (Part 2.3).

7.4 Loading — the module loading sequence

Loading is primarily a build-time act (Part 1.1). The sequence:

 1. READ        instance manifest: domains, modules, versions, config
 2. RESOLVE     exact versions (lockfile); fail on conflict, never guess
 3. VALIDATE    each manifest: ontology range ∩ deployed trunk+extensions ≠ ∅;
                contract versions supported; declared inputs exist in the
                ontology; routes collision-free; config schema satisfied;
                upkeep owner and degraded state present
 4. CHECK LAW   dependency rules (Part 14) verified mechanically:
                plane direction, contract-only edges, acyclicity,
                no cross-domain module edges
 5. ORDER       topological sort of declared module-to-module dependencies
 6. REGISTER    projections, routes, knowledge bindings, vocabulary,
                signal subscriptions — into the composition plan
 7. RECORD      the resolved composition as a Deployment event (Part 5.4)
 8. BUILD       projections run (incrementally) against the current snapshot;
                view models render through the design system
 9. PUBLISH     content-addressed artifacts; the site is the output
10. SERVE       statically; the Interaction shell composes at read time;
                signals (Part 11) trigger the next incremental cycle

Steps 1–7 are the composition phase — pure validation and planning, no truth touched, failures cheap and loud. Steps 8–10 are the standing publication cycle. A module failing at build time (a projection whose transclusion no longer resolves, FORGE-100 Part 7.4) fails its own artifacts into their declared degraded state without halting the pipeline for others — module isolation is what makes a composition of twenty modules operable by a small team.

7.5 Versioning

7.6 Communication and boundaries

How modules communicate is answered by what they are: pure functions over shared truth.

7.7 Module lifecycle

Proposed → Active → Deprecated (still composable; instances warned at composition; replacement named) → Retired (no longer composable; existing published artifacts remain — published views are part of the record and do not vanish retroactively). Retirement honours FORGE-100 Part 5.5: view URLs a retired module claimed either redirect to the underlying objects/snapshot or their removal is recorded in the Record. Deprecation and retirement are recorded events; a module, like everything in Forge, ends but does not vanish from history.

7.8 The Promotion rule

Logic gravitates toward generality only on evidence:

Part 8 — Forge Services

8.1 Definition and the placement rule

A Forge Service is a long-running or scheduled process with its own lifecycle, supervised by Core’s service harness, that produces truth (through the ingestion contract), publishes artifacts, or serves projections — and never renders UI.

The rule distinguishing Service from Forge Module is positional, and therefore unambiguous:

Modules live above Publication: they consume snapshots and exist only at build/read time. Services live at or below Publication: they run on their own clock, because reality does not wait for a build.

Something becomes a Service instead of a Module exactly when it must act independently of a reader or a build — polling a scheduler, training a model nightly, freezing a snapshot every N minutes, serving queries for an instance past the static threshold. If it can be a pure function of a snapshot, it MUST be a module (the cheaper, safer, more disposable form); Services are the expensive form, each one a standing operational promise, and their number is watched the way the ontology’s object count is watched.

8.2 The service roster

8.3 Services and UI, services and events

8.4 Adapters, re-homed

FORGE-100 Part 2.9 placed adapters in the undifferentiated Implementation Layer. FORGE-101 splits them along the seam the Preamble identified: adapter logic is domain (what a Slurm record means — expertise, reusable across every Slurm shop), adapter binding is instance (which endpoint, which credential, which enabled subset — deployment fact). The migration (Part 16) performs this split on the existing adapter code as its central surgery.

8.5 Prediction, and why “Forge AI” is not a domain

The brief lists “Forge AI” among example domains. Examined against Part 2.2’s tests, it fails them: prediction has no instances of its own, no Systems of Record of its own, and no reader community of its own — it is a capability that serves domains, not a scientific practice. Calling it a domain would create the mesh Part 2.3 forbids (every domain depending on Forge AI). The architecture places prediction in three pieces:

The same decomposition pre-answers the assistant question FORGE-004 must settle (FORGE-100 Part 16.3): whatever conversational capability arrives, its mechanism (projection-bound reading, source-carrying answers, “unknown” with dignity) would be Core; its knowledge is domain; its deployment is instance. FORGE-101 reserves the sockets and defers the constitution of the thing itself, as FORGE-100 did.

Part 9 — Canonical Entities Revisited

The brief asks where entities belong. The answer has a general form, then the specific placements.

9.1 The placement rule

The trunk holds what is true of any shared scientific instrument that does work for people and produces science. A Domain Extension Package holds what is true of one practice. An instance holds no types at all — only instances of types, which is what the name always meant.

A useful test for trunk membership, inherited from FORGE-100 Part 13.2’s defence of the sixteen: does the concept survive translation across the four instruments of Part 13.3 (supercomputer, sequencing centre, telescope, biobank) without becoming a metaphor? Job does (a unit of executed work). GPU does not (a telescope has no GPU in any non-metaphorical sense).

9.2 The entities, placed

9.3 The general lesson

Note the pattern in every hard case (GPU, Sample, Workflow, Prediction): the architecture never asks “is this important?” — everything on the list is important. It asks “what is the radius of the community that means the same thing by this word?” Universal → trunk. One practice → extension. One deployment → not a type at all. Importance is not altitude; shared meaning is altitude. That is FORGE-001’s founding insight — unify meaning, not systems — operating at the level of individual nouns.

Part 10 — The Invariant Across the Planes

FORGE-100 Part 1.5’s governing invariant is restated, because every architecture document must carry it:

A fact is stored exactly once, in canonical form, with its provenance and time; everything a reader ever sees is a pure function of stored facts and the reader’s identity.

FORGE-101 adds no second invariant. It answers how the one invariant propagates through composition — what it demands of each thing the brief names.

Why every user-visible representation must remain a pure function of canonical facts and identity — stated once, plainly, because the brief asks for the justification and not just the law: purity is what makes trust compositional. A reader who trusts the Truth Store and can read a projection’s stated method needs no separate reason to trust any page, module, domain, or instance built on them — trust flows through function application, and nowhere else does trust have to be re-earned or re-audited. The moment one surface holds one fact of its own, that surface must be audited independently, forever, and the platform’s trust budget fragments into as many pieces as there are surfaces. One thousand pure views cost one audit; one impure view costs one thousand.

Part 11 — Event Architecture

11.1 Two kinds of event, never confused

Forge has exactly two event concepts, and conflating them would break the invariant:

11.2 Thin signals, fat record

The content-free rule is constitutional, and it is what keeps an event system from quietly becoming a second database:

Signals carry addresses; the Record carries truth. A consumer that needs the facts follows the address to the canonical copy. A signal with a payload is a fact in flight — a copy that can be stale, reordered, or lost while diverging from its home — and is forbidden.

Consequences, each earning its keep: consumers can never act on data fresher or staler than the published record (Principle 3 holds even in plumbing); lost signals degrade latency, never correctness (the next cycle finds the same truth at the same address — which is why at-least-once delivery suffices and no exactly-once machinery is needed); and replay is trivial (re-emit addresses; the truth was never in the pipe). The signal system can be replaced wholesale without touching truth — it is, deliberately, the least interesting component in the architecture.

11.3 How modules and services communicate, assembled

The full communication model, in one place:

11.4 Long-running workflows

Reality’s undertakings (a maintenance campaign, a data-release pipeline, a month-long observing programme) outlive any build cycle. Forge represents them as what they leave behind, not as live orchestration state:

11.5 The event flow diagram

 reality: a node fails at 03:12
    │
    ▼
 System of Record registers it (TSDB alarm / operator observes)
    │
    ▼
 DOMAIN adapter service (next cycle) materialises:
    Record event {kind: incident-detected, affected: node c042,
                  author: detection service, at: 03:12}
    │  ingestion contract
    ▼
 CORE Truth Store: validate · resolve identity · stamp provenance · append
    │
    ▼                                  ┌────────────────────────────────┐
 CORE Publisher freezes snapshot S ───▶│ SIGNAL: "snapshot S published" │
    │                                  └───────────────┬────────────────┘
    │ (the truth)                                      │ (the address)
    ▼                                                  ▼
 incremental build: modules whose declared inputs include
 node events / incident kinds are recomputed against S —
 the node's page (core module), the fleet view (domain module),
 the Record browser (core module), search index (core module)
    │
    ▼
 published artifacts update; the operator later authors the
 resolution event (same path, human as System of Record);
 the reader at 08:00 sees the incident and its resolution,
 each timestamped, each attributed — and nothing anywhere
 holds a copy of the fact outside the Truth Store and its
 snapshots.

Part 12 — API Philosophy

12.1 What Forge APIs expose

The brief asks: entities, commands, events, or queries? Forge’s answer follows from what already exists — FORGE-100 Part 10’s contracts are the API, and FORGE-101 packages rather than reinvents them:

12.2 Evolution and compatibility

Inherited whole from ADR-015, restated as the consumer’s guarantee: contracts are versioned, additive-by-default; breaking changes require a new contract version with a declared deprecation window recorded in the Record; consumers bind to contract versions, never implementations. FORGE-101 adds the composition-era corollaries:

Part 13 — Repository Architecture

13.1 The shape: one repository per plane artifact

 forge                      THE CONSTITUTION (this repository — unchanged in role)
 │                          founding documents · trunk ontology · contracts ·
 │                          ADRs · governance · templates · design grammar
 │                          No production code (FORGE-100 Part 14, still law).
 │
 ├──▶ forge-core            THE RUNTIME (one repository)
 │                          truth store · publisher · projection engine ·
 │                          search · design system · identity enforcement ·
 │                          composition machinery · service harness ·
 │                          core Forge Modules (in-repo: modules/)
 │
 ├──▶ forge-hpc             ONE REPOSITORY PER DOMAIN
 │    forge-genomics        extension package (ontology/) · adapter families
 │    forge-imaging …       (adapters/) · domain modules (modules/) ·
 │                          knowledge templates (knowledge/) · vocabulary
 │
 └──▶ mjolnir               ONE REPOSITORY PER INSTANCE
      biohpc                composition manifest + lockfile · configuration ·
      rubus …               branding assets · instance knowledge & stories ·
                            adapter bindings (credentials via secret store,
                            never in-repo)

13.2 Why this shape and not a monorepo

The choice is argued, because it will be questioned:

The counter-argument is acknowledged honestly: multi-repository coordination costs real friction (a trunk ontology change ripples through repositories on different clocks). The mitigation is the same discipline the API has — additive-by-default, versioned, windowed deprecations (ADR-015) — and the friction is accepted because it is honest: a change that ripples across planes SHOULD feel heavy, since it is constitutionally heavy. A monorepo would make constitutional changes feel free precisely when they are most expensive.

13.3 What lives in forge (this repository) after FORGE-101

FORGE-100 Part 14’s structure stands, with two additions: ontology/extensions/ — the registry of ratified Domain Extension Packages (the packages’ definitions live here in their ratified form, because the ontology including its branches is constitutional; domains develop proposals in their repositories and ratification lands them here); and governance/domains/ — the domain lifecycle process: creation criteria (Part 4.6), extension ratification, promotion/demotion, split and retirement.

Part 14 — The Dependency Rules

These rules are constitutional. They are checked mechanically at composition time (Part 7.4, step 4); a violation is not a code smell but a composition failure.

14.1 The dependency graph

                        ┌──────────────────────────────┐
                        │   FORGE INSTANCE             │
                        │   (Mjolnir, BioHPC, Rubus)   │
                        └──────┬───────────────┬───────┘
              selects, pins,   │               │  configures, binds,
              configures       │               │  supplies credentials
                               ▼               ▼
        ┌──────────────────────────────┐   ┌──────────────────────────┐
        │   FORGE DOMAIN(S)            │   │  (Core's configuration   │
        │   (Forge HPC, Forge          │   │   surface, directly)     │
        │    Genomics, …)              │   │                          │
        │   — no edges between         │   │                          │
        │     domains, ever —          │   │                          │
        └──────────────┬───────────────┘   └────────────┬─────────────┘
          extends via ratified              │
          extension packages;               │
          consumes contracts                │
                               ▼            ▼
                        ┌──────────────────────────────┐
                        │   FORGE CORE                 │
                        │   (runtime + core modules)   │
                        └──────────────┬───────────────┘
                          conforms to  │
                                       ▼
                        ┌──────────────────────────────┐
                        │   THE CONSTITUTION           │
                        │   trunk ontology · contracts │
                        │   · principles · ADRs        │
                        └──────────────────────────────┘

   Every arrow points downward. There are no upward arrows,
   no lateral arrows between domains, and no arrow may skip
   the contract at its boundary.

14.2 The rules, enumerated and explained

Each rule names what it permits or forbids, and why — because a rule whose reason is forgotten will be repealed by convenience.

  1. Everything may depend on the constitution. The trunk ontology and the contracts are the root; they depend on nothing and everything speaks them. Why: a shared language must have exactly one definition (FORGE-001’s founding argument), and it must sit below every party that speaks it.

  2. Domains depend on Core. Core MUST NOT depend on domains — permanently. Not on their code, their names, their vocabulary, or their existence. Core compiled today must be byte-identical whether one domain exists or fifty. Why: the moment Core knows one domain, every other domain inherits that knowledge as dead weight, and Core’s release cadence couples to the fastest-moving practice it knows about. Core’s ignorance is every domain’s independence.

  3. Instances depend on domains and on Core’s configuration surface. Domains and Core MUST NOT depend on instances — permanently. Why: an instance is the narrowest possible knowledge (radius of one, Part 9.3). Anything below it that learns its name has moved deployment fact into shared machinery, where it becomes the next adopter’s inherited falsehood.

  4. Domains MUST NOT depend on other domains. Shared needs are promoted (Part 4.5), never imported. Why: one lateral edge makes two domains un-adoptable separately and un-retirable ever; a handful make the domain plane a mesh, and a mesh has no seams — which is to say, no architecture.

  5. Instances MAY depend on Forge Modules — by selection and pinned version, through manifests only. An instance names modules and supplies their declared parameters; it MUST NOT reach into module internals, fork a module, or patch one in place. Why: the manifest is the module’s whole promise (upkeep, degraded state, inputs); an instance that bypasses it holds an unrecorded promise, which Principle 11 forbids.

  6. Forge Modules MUST NOT know their instance. A module receives (snapshot, knowledge, configuration) and nothing else; instance identity is not among the things a module can name (Part 7.6). Why: a module that behaves differently on Mjolnir than on BioHPC under identical configuration is untestable, unportable, and secretly instance logic — the no-logic rule (Part 5.2) evaded by relocation.

  7. Modules depend downward or laterally-within-plane, on contracts, acyclically (the full statement is Part 7.6). Core modules on Core only; domain modules on Core, core modules, their own domain, and same-domain modules; never across domains. Why: module edges are the finest-grained place the plane law could leak, so the plane law is restated at module grain.

  8. Services obey their owning plane’s rules, and additionally MUST NOT be depended on directly by anything — a service’s consumers read what it publishes (truth, snapshots, signals), never call it. Why: the unidirectional flow (FORGE-100 Part 1.2) admits no runtime call graphs; a called service is a runtime dependency that can fail at read time, which the static thesis exists to preclude.

  9. Nothing depends on a view, ever. Citations point at objects and moments (FORGE-100 Part 5.5); machinery reads truth, not renderings. Why: views must stay free to delete (§3.3), and anything depended-upon is no longer free.

  10. Skipping a boundary’s contract is forbidden even in the permitted direction. A domain module reading Core’s truth store directly (rather than snapshots), an instance writing a domain service’s working state — these follow the arrows and still violate the law, because the contract at the boundary is part of the boundary. Why: contracts are what make each layer reimplementable (FORGE-100 Part 10); a permitted-direction bypass destroys that property as surely as a forbidden-direction import.

14.3 Answering the brief’s questions directly

Part 15 — Mapping Today’s HPC Analytics Platform

The existing platform is not ignored; it is the evidence base. Every major subsystem below is mapped to its plane and stratum. The goal is evolution: nearly everything survives; what changes is where it lives and what may know about it. Where a subsystem’s internal function is not fully visible from the constitutional record, the mapping is by function as named, and the migration’s Phase 1 audit (Part 16.2) verifies it.

Today’s subsystem Destination plane Destination stratum The mapping, reasoned
Scheduler abstraction Forge HPC Source (adapter family) The existence of an abstraction over schedulers is itself the proof of the domain plane: it is not Mjolnir-specific (any Slurm shop needs it) and not universal (a telescope has no scheduler). It becomes Forge HPC’s flagship adapter family; Mjolnir keeps only endpoint bindings and credentials.
Node inventory Split: Forge HPC + Core Source → Truth The ingestion of node facts (CMDB/procurement adapters) is domain. The keeping of Node objects — identity, lifecycle, service records — is Core’s Truth machinery operating on trunk types. The inventory UI (fleet view, generations) is a domain module in Derivation.
Queue insights Forge HPC Derivation (domain module) Queue semantics are pure HPC expertise. The queue remains a view, never an object (§3.3). The honest outlook (FORGE-002 §1.2) is projected here; any predictive upgrade issues forecasts through Core’s mechanism (Part 8.5).
Software Intelligence Split: Core + Forge HPC Truth + Derivation Software and its installed builds are trunk objects (FORGE-002 §3.2 Software / ontology-Module). The intelligence — usage shapes, adoption trends, deprecation surfacing — is a Forge HPC domain module projecting trunk truth.
LEAF (energy/efficiency accounting, as deployed today) Split three ways Truth + Derivation + Instance config Energy measures on objects and the Ledger projection are Core (FORGE-100 Part 8.5 — the Ledger owns no truth). HPC-specific energy interpretation (node power models, job attribution methods) is Forge HPC. The grid carbon-intensity feed — and whether carbon is derived at all — is Mjolnir instance configuration (FORGE-100 Final Review: no honest feed, no derived carbon).
User analytics Split: Core + Forge HPC Truth + Derivation, gated by Identity Person/Group/Project truth and the aggregation machinery (floors, differencing resistance — ADR-017) are Core. HPC-specific usage projections are domain modules. Everything person-grained is private facets; the migration MUST re-audit today’s analytics against ADR-017 rather than porting them as-is — this is the one subsystem where migration is also correction.
Prediction services Split per Part 8.5 Core mechanism + domain services + instance config Forecast issuance/recording/calibration → Core. Queue-wait and similar models → Forge HPC services. Model selection, thresholds → Mjolnir config.
Presentation Core Presentation The design system, object anatomy, visual grammar — universal by Principle 10. Mjolnir retains wordmark and theme tokens only.
Publication (the publishing pipeline) Core Publication Snapshot freezing, content addressing, static artifact generation — the constitutional heart, domain-blind by construction.
Authentication Split: Core + Mjolnir Identity (orthogonal) Enforcement (facet gating, fail-closed, null-identity public path) → Core. The identity provider, authorization mapping, and floors → instance (already FORGE-100 Part 13.4’s position).
Routing Core Interaction/Navigation Permanent URLs as functions of identifiers (ADR-001) — constitutionally universal. Domain modules claim view-routes through manifests; nobody owns routing but Core.
Static frontend Core (shell) + modules Presentation/Interaction The shell — walking, asking, scrubbing, sign-in — is Core. Individual surfaces decompose into core modules (object pages, Record, Ledger, search) and Forge HPC modules (queue, fleet, software intelligence).
Search Core, fed by domain vocabulary Derivation Engine, contract, typed answers, honest zero → Core (ADR-010). HPC synonyms and vocabulary → Forge HPC content. Mjolnir contributes nothing — searching Mjolnir and searching BioHPC MUST feel like the same instrument.
Canonical entities Core (trunk) + Forge HPC (bindings/extensions) Ontology The sixteen remain trunk. HPC-specific facet families (accelerators, interconnect, storage allocations) become the first ratified Domain Extension Package — regularising, through Part 4.3’s process, whatever HPC-specific vocabulary today lives mixed into the entity definitions.

Two observations the table compresses. First, almost every subsystem splits — which is the empirical confirmation that the old two-layer model was storing two kinds of knowledge in one place; a mapping under which subsystems landed whole in single planes would suggest the planes were unnecessary. Second, nothing lands in Mjolnir but configuration, bindings, branding, and content — the first demonstration of Part 5.1’s smallness criterion, performed on real code.

Part 16 — Migration Strategy

A migration, not a rewrite: production keeps publishing throughout, and no reader should be able to date the migration from the outside. The strategy rests on one inherited property: projections are deterministic (FORGE-100 Part 2.5), so any refactor that claims to preserve behaviour can be proven to — rebuild from the same snapshot and diff the published artifacts. Byte-equivalence is the migration’s regression suite, and it is the strongest one an architecture has ever handed its own refactoring.

16.1 The roadmap

 Phase 0   CONSTITUTION            FORGE-101 ratified; ADRs 018–027 written;
 (now)     │                       governance for domains established.
           ▼
 Phase 1   THE AUDIT               Label every file/component of HPC Analytics
 (weeks)   │                       core / hpc / mjolnir — annotation only,
           │                       nothing moves. Disagreements about labels
           │                       are the architecture being debugged cheaply.
           ▼
 Phase 2   INSTANCE EXTRACTION     Pull every Mjolnir-specific value into one
 (weeks)   │                       typed configuration document consumed by the
           │                       rest. Mjolnir is born as data, not code.
           │                       ✓ verify: byte-identical output
           ▼
 Phase 3   CORE EXTRACTION         Move core-labelled machinery into forge-core;
 (months)  │                       the existing platform becomes forge-core's
           │                       first consumer (strangler pattern — the old
           │                       shell shrinks as the runtime grows inside it).
           │                       ✓ verify: byte-identical output per move
           ▼
 Phase 4   DOMAIN EXTRACTION       Move hpc-labelled expertise into forge-hpc:
 (months)  │                       adapter families (split logic from bindings,
           │                       Part 8.4), domain modules, knowledge
           │                       templates; ratify the hpc: extension package.
           │                       ✓ verify: byte-identical output per move
           ▼
 Phase 5   THE RESIDUE IS MJOLNIR  What remains — manifest, config, branding,
 (weeks)   │                       content — becomes the mjolnir repository.
           │                       The old codebase is empty; retire it with a
           │                       Deployment event, honestly recorded.
           ▼
 Phase 6   THE PROOF: BIOHPC       Compose forge-core + forge-hpc + new instance
           │                       repo. Acceptance test (constitutional):
           │                       BioHPC MUST require zero changes to Core and
           │                       zero domain changes beyond new adapter
           │                       bindings or genuinely new source adapters.
           │                       Any other change failing this test is a
           │                       misplacement escaping Phase 1–4, fixed by
           │                       relocation, not exception.
           ▼
           STEADY STATE            New instances are repositories of declaration;
                                   new domains are extracted when committed
                                   instances demand them (Part 4.6).

16.2 The phase disciplines

16.3 What is deliberately not migrated

Correction is separated from relocation, with one named exception. The migration moves knowledge to its right plane; it does not simultaneously redesign features — with the single exception of user analytics, where Part 15’s ADR-017 re-audit is a constitutional obligation, not an improvement, and where porting-as-is would migrate a privacy defect into a new decade. Everything else that deserves redesign gets it after its relocation, as ordinary view-layer work — because views are free (Part 5 of FORGE-100), and the migration’s job is to make them free, not to spend the freedom early.

Part 17 — Future-Proofing: Six Systems That Must Cost Core Nothing

The test of this document is a system its authors have not imagined. The nearest available proxies, walked through the planes. In every case the claim is the same and falsifiable: Forge Core changes by zero lines.

The pattern across all six: new science lands as bindings, extensions, adapters, and modules — the planes built for it — and the further a system sits from HPC, the more its value concentrates in the constitutional core rather than any domain. That inversion is the strongest available evidence that the Core/Domain split was drawn along the true grain.

Part 18 — New Architectural Decision Records

Continuing FORGE-100’s numbering (ADR-001–017 stand unchanged). Each entry: decision, and why it must be an ADR — that is, why future maintainers will need the reasoning, not just the rule.

ADR-018 — The Three Planes: Core, Domain, Instance. The Implementation Layer of FORGE-100 Part 2.9 is refined into Domain (practice expertise) and Instance (deployment fact); planes separate by rate of change, author class, and reuse radius. Exists because it is FORGE-101’s founding decision, and every later argument (“shouldn’t this just live in Core?”) must be answerable by citation.

ADR-019 — Domain Extension Packages: Trunk and Ratified Branches. The ontology is a universal trunk plus namespaced, constitutionally ratified, domain-owned extension packages; instance-level types remain forbidden; concepts needed by two domains are promoted. Exists because it deliberately extends ADR-016, and the boundary between “extension” and “fork of the language” must be citable when a domain pushes on it.

ADR-020 — Instances Contain No Logic. An instance is manifest, configuration, bindings, branding, and authored content; behaviour is selection among declared options; anything else is a missing capability implemented in the domain or Core. Exists because this is the rule most eroded by deadline pressure (“just a small script in the instance repo”), and erosion must be nameable as violation.

ADR-021 — Forge Modules: Manifest-Declared, Build-Time Composed, Contract-Bound. Capability ships as modules declaring identity, requirements, inputs, contributions, parameters, upkeep owner, and degraded state; composition is closed, validated, recorded; declared inputs are the whole of granted access. Exists because the manifest is where Principles 11 and 12 become unskippable fields, and the closed-composition choice (no runtime plugins) will be challenged by every future marketplace fantasy.

ADR-022 — Thin Signals, Fat Record. Two event kinds only: Record events (truth, authored, published) and Signals (runtime notifications carrying addresses, never facts); payload-bearing signals are forbidden. Exists because an event bus with payloads is the single most common way modern architectures silently duplicate truth, and the prohibition needs a permanent, citable reason.

ADR-023 — Module and Plane Dependency Law. The rules of Part 14, mechanically enforced at composition: downward-only across planes, no lateral domain edges, contract-only boundaries, modules blind to their instance, nothing depends on views or calls services. Exists because dependency rules not written as law decay into lore, and lore loses arguments with convenience.

ADR-024 — Services Below Publication, Modules Above. The positional rule: what can be a pure function of a snapshot must be a module; services exist only for work on reality’s clock; services are never called by consumers, only read through what they publish. Exists because every future capability will arrive asking to be a service (services feel powerful), and the presumption must run the other way.

ADR-025 — Forecasts Are Derived Measures with Recorded Issuance. Prediction is Core mechanism (issue, label, record, calibrate), domain models, instance deployment; an issued forecast becomes an observed fact about its issuing service; Prediction is never an object type. Exists because it operationalises FORGE-002 §1.2’s error-bar demand and pre-answers part of FORGE-004, and because “just store the predictions” will be proposed within the year.

ADR-026 — One Repository Per Plane Artifact. Constitution, Core, each domain, each instance: separate repositories; modules live in their owning plane’s repository; promotion moves code between repositories as a recorded act. Exists because the monorepo argument will recur with every new hire, and the answer — boundaries enforced physically, cadence and ownership per plane — deserves better than repetition.

ADR-027 — Promotion on Evidence, Never Speculation. Logic moves toward generality only when demonstrated (instance need → domain option; two domains → Core or trunk); domains are created only for committed instances; generality is proven by the second instance; altitude is reviewed in both directions. Exists because speculative generality is the death of platform projects, and the burden of proof must be citable in every “while we’re at it, let’s make it generic” review.

Ten planes-era decisions, deliberately few, mirroring FORGE-100’s restraint: each ADR is itself a promise of upkeep.

Final Review — What Remains Unresolved Before Implementation

The honest account, in FORGE-100’s tradition: what this document has decided is above; what it has not decided, and must not pretend to have, is below. Each item names the question, why it is genuinely open, and what bounds it in the meantime.

1. Who ratifies a Domain Extension Package? Part 4.3 reuses “the constitutional amendment process,” but FORGE-001 §23 Q7’s question — who holds the authority to say no? — was answered for one instrument’s platform, not for an ecosystem where a domain’s community and the trunk’s guardians may disagree. A domain denied an extension can fork nothing (the law forbids private types), so the ratifier holds real power over practices they may not understand. Bound by: governance/domains/ (Part 13.3) must define the ratification body and an appeal path before the first extension package — which is Phase 4 of the migration, so the deadline is real and near.

2. Two domains binding the same trunk object for one instance. BioHPC composes Forge HPC and (eventually) Forge Genomics; both bind Job — one as batch computation, one as sequencing run, sometimes the same Job. Part 4.5 establishes that they meet on trunk objects without knowing each other, but the presentation question is open: whose vocabulary labels that Job’s page? Whose module claims its primary view-route when both offer one? Composition-time route collision detection (Part 7.4) makes the conflict loud, and manifest-declared precedence configurable by the instance is the likely shape — but the answer is deferred to the first real collision, on the principle that presentation conflicts should be designed from an actual case, not an imagined one. Bound by: it is a Derivation/Presentation question only; truth is unaffected whatever the answer.

3. The Core–Domain compatibility matrix. Modules declare compatibility in ontology and contract versions (Part 7.5), which is clean — but Core itself evolves, and the question of how many trunk versions Core must simultaneously serve (a 2027 snapshot beside a 2032 one, per Part 12.2) has a cost curve nobody has measured. Supporting every version forever is the record’s promise (ADR-009); supporting every version in the live pipeline is not the same promise, and the distinction needs an operational policy. Bound by: the published record’s readability is constitutional and non-negotiable; only live-pipeline support width is open.

4. Federation across instances. FORGE-100 Part 13.6 kept federation possible and unbuilt. The planes sharpen the question: a cross-instance view (a national portal over Mjolnir + BioHPC) is a projection over multiple snapshot chains — but whose projection? It is not an instance (radius > 1), not a domain (it is a deployment, not expertise), and making it Core machinery smuggles a product into the runtime. The honest answer may be a fourth kind of composition — an instance whose “sources” are other instances’ published records — which would be elegant precisely because it adds no plane. Bound by: instrument-scoped identifiers (ADR-001) and self-describing snapshots already guarantee federation remains buildable; only its constitutional shape is open.

5. Staffing the planes. FORGE-100’s Final Review named editorial capacity the project’s largest existential risk; the planes multiply the question. A domain is a community’s codebase in theory — but Forge HPC at birth will be maintained by the same small team as Core and Mjolnir, and the plane boundaries this document enforces mechanically will be socially fictional until at least one plane has a genuinely distinct owner. The risk is not that the boundaries break but that they become ceremony — three repositories, one mind — and ceremony without benefit erodes the will to maintain the discipline when it finally matters (at BioHPC, at the first external domain contributor). Bound by: Phase 6’s acceptance test is mechanical and does not care who maintains what; but the governance documents of Part 13.3 should name plane owners explicitly, even if today several names are the same person, so that divergence is a planned event rather than a crisis.

6. The composition of FORGE-004. Twice deferred before this document, and deferred again here with sockets reserved (Part 8.5): the assistant question. FORGE-101 adds one new urgency to FORGE-100’s: a conversational layer will be domain-flavoured (it must speak HPC to HPC users), which tempts implementers to build it inside a domain, coupling the most constitutionally dangerous capability to the least constitutionally supervised plane. The pre-commitment stands and is now plane-specific: whatever FORGE-004 permits, its mechanism is Core, bound by the invariant — sources, ages, “unknown” with dignity — and no domain ships its own assistant machinery in the interim. Bound by: the reservation just stated, which this document makes law until FORGE-004 supersedes it.

Closing judgment

FORGE-100 proved the vision constructable. FORGE-101’s claim is narrower and, if anything, harder: that the construction can be shared — that the machinery built for one Danish supercomputer can be the runtime for sciences not yet chosen, institutions not yet met, and instruments not yet built, without those futures paying for HPC’s past or Mjolnir’s particulars.

The claim rests on three decisions, and it is worth being plain about which carries the most weight. The three planes (ADR-018) are the skeleton; the extension-package mechanism (ADR-019) is the joint that lets the skeleton grow without fracturing the shared language; but the load-bearing decision is the humblest one: Core’s permanent ignorance (Part 14, rule 2). Every failed platform in this document’s ancestry — the portal of doors, the framework that knew its first customer too well, the unified system that unified nothing — failed by knowing too much. Forge Core is designed to know almost nothing about the sciences it serves, and to be incapable of learning, because what the runtime does not know, it cannot impose; what it cannot impose, it cannot break; and what it cannot break, a stranger in five years can trust.

That stranger is this document’s reader of record. They will compose a platform for an instrument nobody in this project has heard of, out of a Core that has never heard of them — and if Parts 1 through 18 have done their work, both parties will find that mutual ignorance is precisely what makes the collaboration safe, cheap, and durable. The architecture’s authority ends where the evidence begins; BioHPC is the first evidence, and Phase 6 is its test.

— End of FORGE-101.