FORGE-202 — The Forge Engine

Project Forge — Third Execution Document Status: Normative for execution. Implements FORGE-101, FORGE-200, and FORGE-201; introduced by Capability 7C. Precedence: the constitutional corpus (FORGE-001 … FORGE-103) governs; FORGE-200 governs how the engine executes; FORGE-201 governs why organisms live apart from it. This document does not amend any of the three; it completes FORGE-201’s move by auditing this repository for what the split left behind, and it is the canonical definition of the engine that results. Where a reading of this document contradicts FORGE-101, FORGE-200, or FORGE-201, they govern.

Preamble

FORGE-201 split Mjolnir into its own repository. That was a decision about where an organism’s declaration, publications, and frontend belong, and it was made and executed correctly. It was not, by itself, a cleanup of the repository the organism was split out of. Capability 7A composed Mjolnir from inside this repository (FORGE-200); Capability 7B gave Mjolnir its own home (FORGE-201) but left this repository holding the artifacts of the arrangement it had just ended: a declaration nothing local read anymore, a publication nothing local served anymore, and a piece of frontend hydration wired to both.

Capability 7C is that cleanup. Its result is this document: the canonical statement of what Project Forge is, now that the separation FORGE-201 described is physically complete in both repositories, not just the one that received the organism.

One sentence carries it, extending FORGE-201’s:

The engine is timeless; the organism continuously changes — and now the engine’s own repository contains nothing that could make that stop being true.

Part 1 — What Capability 7C found and did

An audit of every file in this repository against FORGE-201 Part 3’s line — an organism’s repository owns its declaration, its vendored engine, its publications, its frontend, its own pace of change; the engine’s repository owns none of those — found four residues of the pre-split arrangement, uncleaned by the repository split itself:

Residue	What it was	Disposition
`instances/mjolnir/`	Mjolnir’s `forge-instance.json` declaration and README, composed in place by Capability 7A	Removed. The declaration’s canonical copy now lives, and is maintained, in `forge-mjolnir`.
`public/mjolnir/identity.json`	The published runtime identity document, an organism’s own truth	Removed. Publication now happens where the organism composes: `forge-mjolnir`.
`instances/tests/test_mjolnir.py`	A test verifying Mjolnir’s declaration composes and its publication has not drifted	Removed from here, not from existence: the equivalent test now lives in `forge-mjolnir`, verifying the same property against Mjolnir’s own vendored runtime. Coverage of the mechanism — composition, resolution, navigation derivation, identity-document determinism — is unaffected; it was never Mjolnir-specific here, and is carried by `forge-core/runtime/tests` against fixture instances (`aurora`), which name no organism and never did.
`js/forge-instance.js` and its hydration wiring in `index.html` / `css/forge.css`	The frontend script that fills a page’s `[data-forge-identity]` section from a runtime identity document, and this repository’s own landing page wired to hydrate itself as though it served Mjolnir	Removed. FORGE-201 Part 3 names this “its frontend” — an organism’s, not the engine’s. `forge-mjolnir` already carries its own copy, live, hydrating its own homepage from its own published document. This repository’s landing page is not an organism’s homepage and has no identity document to hydrate; keeping the wiring here was the split’s most visible unfinished corner — the reason `projectforge.dk`’s own front page still said “Mjolnir” under the fold.

instances/README.md was rewritten, not removed: FORGE-201 Part 6 requires organisms to register themselves somewhere durable, and “organism registry” was explicitly out of scope for deletion. It is now a registry of organisms and the repositories they live in, containing no organism’s declaration itself (Part 4).

Everything else audited — forge-core/, forge-hpc/, the founding documents, the 100- and 200-series execution documents, contracts/, ontology/, principles/, architecture/, governance/, roadmap/, templates/, docs/adr/ — was already clean. forge-core/runtime and every forge-capability.json under forge-core/ and forge-hpc/ were grepped for the string “mjolnir” as part of this audit and found clean, which is what FORGE-101 Part 2.3’s build-failure rule and FORGE-200 Part 8’s purity tests already guarantee mechanically; the audit’s job was confirming the guarantee, not discovering a violation.

Part 2 — Engine responsibilities

The engine is forge-core and its domain packages (forge-hpc, and successors). It owns:

The Forge Runtime (forge-core/runtime) — composition, discovery, resolution, derivation, and publication, as specified by FORGE-200.
Core capabilities — subsystems every organism may draw on regardless of domain (publication, and successors), each self-declared via forge-capability.json (FORGE-200 Part 6).
Domain packages (forge-hpc) — the vocabulary and contracts of a scientific practice: the canonical domain model, the scheduler contract and adapter boundary, and the domain’s own capabilities (queue-insights, software-intelligence, scheduler, storage, telemetry, reservations, node-intelligence), each self-declared the same way.
The constitutional and architectural corpus — FORGE-001 through FORGE-103, this 200-series, ADRs, contracts, ontology, principles, governance, and roadmap: everything that would still be true if no organism existed yet.
The organism registry (instances/README.md) — a record of which organisms exist and where they live, not their declarations.

The engine owns no organism’s name, hosts, branding, credentials, or published truth. Every one of the items above is reused, unmodified, by every organism the engine composes; none of them is true of Mjolnir alone.

Part 3 — Organism responsibilities

Restated from FORGE-201 Part 3, because this document exists to make it stick: an organism’s own repository owns its declaration, its vendored copy of the engine, its publications, its frontend, and its own pace of change. Nothing on that list may reappear in the engine’s repository. This is the rule Part 1’s audit enforced.

Part 4 — Shared contracts

The engine and every organism meet at exactly three seams, all specified by FORGE-200 and unchanged by this document:

The instance manifest (forge-instance.json) — an organism’s declaration, validated by the runtime’s VALIDATE step (FORGE-200 Part 2, Part 4).
Capability registration (forge-capability.json) — the engine’s and its domains’ self-declared surfaces, discovered by the runtime’s DISCOVER step (FORGE-200 Part 6).
The runtime identity document (public/<namespace>/identity.json) — the derived artifact an organism’s frontend hydrates from (FORGE-200 Part 4, Part 5).

An organism composes correctly against these three seams if and only if it vendors a copy of the engine sufficient to run ForgeRuntime.compose(...) locally. Nothing else needs to be shared, requested, or negotiated between an organism’s repository and this one.

Part 5 — Runtime ownership: canonical source, not documentation-only

FORGE-201 already decided this, in one sentence easy to read past: “Vendoring is a deployment necessity, not a claim of ownership — the engine’s canonical source, and the right to change how it works, stays in Project Forge.” Capability 7C’s brief asked that this decision be re-examined rather than assumed correct, so here is the analysis, redone.

Option A — Project Forge retains the runtime as canonical source; organisms vendor copies. This is the status quo, confirmed.

Option B — Project Forge becomes documentation-only; organisms own their own executable runtime.

The case for B is real: it removes the vendoring problem entirely (no copy ever drifts from a “canonical” version, because there is no canonical version, only documented behaviour every organism independently implements against). It is how many spec-and-multiple-implementations ecosystems work, and it would make the engine repository lighter — pure prose, no Python.

The case for A, and why it wins:

FORGE-200 Part 8 already makes the runtime’s correctness a constitutional check — purity tests (no instance name in the engine) and determinism tests (a published document matches regeneration) are “constitutional checks… their failure is a build failure, not a warning.” A constitutional check needs one implementation to check against. Under Option B, “the runtime discovers capabilities declaratively” is prose an organism author could misread or reimplement inconsistently, and the first divergence would surface as two organisms disagreeing about what forge-instance.json means — exactly the failure mode FORGE-101’s plane discipline exists to prevent.
Every capability the engine adds (a new forge-capability.json shape, a new resolution rule) is currently free for every organism, the moment they re-vendor (FORGE-200 Part 6: “adding a capability means adding a manifest, never editing the engine”). Under Option B, the same addition would require every organism to have independently implemented the runtime deeply enough to already support it — turning a manifest-only change into an N-times reimplementation exercise.
The cost Option B removes — vendoring drift — is bounded and cheap under A. A vendored copy is a snapshot, refreshed at the organism’s own pace (FORGE-201 Part 5); nothing forces synchrony, and nothing breaks when an organism vendors an older engine version, because the runtime’s contract (Part 4, above) is the compatibility boundary, not the implementation’s internals.
The cost Option A keeps — one canonical implementation to maintain — is exactly the cost FORGE-101 already assigned to the engine’s owners, and is smaller than the cost Option B would impose on every organism author who would otherwise need to build a composition engine from a specification, correctly, before they could compose anything at all.

Recommendation: Option A, retained. The runtime’s canonical source stays in forge-core/runtime. Every organism vendors a copy sufficient to compose and publish independently (FORGE-201 Part 3); the canonical copy, and the right to change how it works, stays here. This is not a new decision — it is FORGE-201’s decision, re-derived rather than assumed, and it still holds.

Part 6 — Publication ownership

The engine publishes nothing. PublicationNamespace (FORGE-200 Part 5) is engine machinery — a function from (namespace, relative path) to a safe artifact path — but invoking it, and thereby producing artifacts under public/<namespace>/…, is something only a composed organism does, using its own vendored runtime, on its own build. Project Forge’s own repository contains no public/ directory for exactly this reason: it composes no organism, so it has nothing to publish. A future organism populates its own public/<namespace>/ the same way Mjolnir’s did before the split, and the same way forge-mjolnir does now — never here.

Part 7 — Future evolution

New engine capabilities are added the way FORGE-200 Part 6 already specifies: a new forge-capability.json beside new code under forge-core or a domain package. No organism needs to change, and no organism is required to adopt the capability on any schedule but its own (FORGE-201 Part 5).
New domains (Forge Imaging, Forge Genomics, and others FORGE-101 Part 6 leaves unnamed) are created only once a committed organism needs one (FORGE-101 Part 6), following the same shape as forge-hpc: abstract vocabulary and contracts, no instance names, no institution-specific logic.
New organisms are created by following FORGE-201 Part 4 exactly — declare, vendor, compose, publish, house — and are recorded with one row in instances/README.md. Nothing about creating an organism touches this repository beyond that row.
This document is amended, not the runtime’s behaviour, if the engine/organism boundary is ever redrawn. Any future capability that would put organism-specific data back into this repository — a declaration, a publication, a hydrated frontend — is a constitutional violation of FORGE-201 Part 6, not a convenience, exactly as it was when this capability found and removed the last of it.

Part 8 — What this document binds

Project Forge’s repository MUST NOT contain any organism’s declaration, publication, or frontend, now or after any future capability. Part 1’s residues are the last instance of each; their recurrence is a regression, not a design choice.
The Forge Runtime’s canonical source MUST remain in forge-core/runtime, per Part 5’s analysis; organisms vendor copies and never fork the canonical source’s authority to change.
The organism registry (instances/README.md) MUST record every organism and its repository, and MUST NOT hold a declaration itself.
The engine’s landing page (index.html) MUST describe Project Forge, never present itself as an organism, and MUST NOT hydrate from a local identity document it does not itself publish.
The engine is timeless; the organism continuously changes. FORGE-201 said so; this document is the record that the engine’s own repository now, physically, agrees.