FORGE-201 — The First Organism

FORGE-201 — The First Organism

Project Forge — Second Execution Document Status: Normative for execution. Implements FORGE-101 and FORGE-200; introduced by Capability 7B. Precedence: the constitutional corpus (FORGE-001 … FORGE-103) governs; FORGE-200 governs how the engine executes. This document does not amend either; it records why the engine and its first organism now live in separate repositories, and binds every organism that follows to the same pattern. Where a reading of this document contradicts FORGE-101 or FORGE-200, they govern. Sequel: Capability 7B, recorded here, split the organism out. Capability 7C, recorded in FORGE-202, finished the other half of the same move — auditing this repository for the organism-specific residue the split had not yet swept up (a stale declaration, a stale publication, a stale piece of hydrated frontend, a landing page that still spoke as though it were Mjolnir’s) and removing it. FORGE-202 is the canonical definition of what the engine, post-cleanup, actually is.

Preamble

FORGE-200 gave the engine a body: a runtime that loads a declaration, discovers what has registered, resolves what an instance enables, and publishes the result. It proved the machinery worked by composing one organism, Mjolnir, from inside the engine’s own repository.

That arrangement was always provisional. FORGE-103 Part 2.2 anticipated it directly: each instance eventually lives in its own repository. Capability 7B is that anticipation made real. Mjolnir now lives at forge-mjolnir, its own repository, running at mjolnir.projectforge.dk. Project Forge — this repository, projectforge.dk — keeps the architecture: the constitution, the runtime’s canonical source, the founding documents, and every principle an organism is built from.

One sentence carries this document, and it is FORGE-200’s sentence extended one clause:

Project Forge is the engine; Mjolnir is a living organism built on it; and now the two live where their natures put them — the engine in one timeless repository, the organism in its own, changing one.

Everything below explains why that separation had to become physical, not just conceptual, and what it obligates every organism that follows.

Part 1 — Why engine and organism must live apart

A repository is not a neutral container. Whatever lives inside one repository shares its history, its release cadence, its issues, its sense of what is “done.” FORGE-200 could keep Mjolnir’s declaration beside the engine’s code because nothing yet depended on Mjolnir changing on its own schedule. That stopped being true the moment Mjolnir became a real, running instrument: a cluster’s queues fill and drain by the hour; its software catalogue updates by the week; the engine that composes it changes by the capability. Sharing a repository would force one of two false choices — freeze the organism to the engine’s pace, or drag the engine into the organism’s churn.

The architecture already named this distinction before it had a repository boundary to enforce it: Part 1 of FORGE-200 draws the engine as “everything under forge-core and the domain packages,” reused by every deployment, and an instance as “pure declaration” — a document the engine reads, not a fork of the engine. A repository split is the same line, drawn where a reader can see it without reading a single file. projectforge.dk answers “what is Forge?” mjolnir.projectforge.dk answers “what is Mjolnir doing right now?” No visitor to either site should need the other to make sense of what they are looking at.

Part 2 — Why Mjolnir is the first organism

Mjolnir was never chosen as a permanent flagship; it was chosen as a forcing function. FORGE-101 Part 16.6, echoed at the close of FORGE-200, states the test plainly: the second organism is the acceptance test of the first’s architecture. An architecture proven by one instance has proven nothing — it may simply have absorbed that instance’s peculiarities as unexamined assumptions. Mjolnir’s job was to be composed honestly enough, and generally enough, that a second organism could be built from the same engine without touching the engine at all.

Capability 7B is the midpoint of that test, not its conclusion. Splitting Mjolnir into forge-mjolnir and vendoring the engine into it is the first time the engine has been asked to leave its own repository and still stand up. It passed: the runtime composes, discovers, resolves, and publishes Mjolnir’s identity from inside a repository that has never heard of projectforge.dk, using nothing that is not either Mjolnir’s own declaration or a copy of engine code whose canonical source remains here. The real test — a second organism, built by someone who has only ever read this document and FORGE-200 — is still ahead, and is what Part 4 exists to make cheap.

Part 3 — The responsibilities of an organism

An organism’s repository owns everything true of it alone, and nothing that would be true of any other organism:

What an organism’s repository does not own: the engine’s architecture, the constitutional corpus, the platform’s founding documents, or any principle that would still be true if Mjolnir had never existed. Those stay in Project Forge because they were never Mjolnir’s to begin with.

Part 4 — How future organisms are created

Rubus, Sigma, or any organism after them is created by repeating exactly what Capability 7B did for Mjolnir, not by inventing a new pattern:

1. DECLARE   a new forge-instance.json — the organism's identity,
             branding, enabled capabilities, domain settings
2. VENDOR    a copy of the Forge Runtime and the capability
             registrations the declaration enables
3. COMPOSE   run the runtime locally; let it discover, resolve, and
             publish the organism's own identity document
4. PUBLISH   the frontend, hydrating itself from that document alone
5. HOUSE     the whole of the above in the organism's own repository,
             named for the organism, never for an analytics project
             or any other capability it happens to enable first

Nothing in this sequence names Mjolnir, and nothing in it is specific to HPC. A biology-domain organism follows the same five steps against a biology-domain capability set; the engine does not need to know either exists. This is what “adding a capability means adding a manifest, never editing the engine” (FORGE-200 Part 6) buys at the organism scale: adding an organism means adding a repository, never editing this one.

Part 5 — Why organisms evolve independently of Forge

An organism that could not outpace its engine would not be alive; it would be a demo. Mjolnir’s queues, software catalogue, and telemetry will change with the reality of a running cluster, on schedules no engine release should gate. The engine, symmetrically, must be free to grow — new capabilities, new contracts, new domains — without waiting on every organism’s readiness to adopt them, and without an organism’s local branding or urgency leaking backward into architecture meant to outlast it.

Independent evolution is not a failure to integrate; it is the integration succeeding. The contract between the two is exactly what FORGE-200 already specified: an instance manifest, a set of capability registrations, and a runtime identity document. As long as an organism’s repository can still compose against that contract, it may change everything else about itself — including, eventually, adopting engine capabilities Project Forge has not yet imagined when this document was written — without either side asking the other’s permission first.

Part 6 — What this document binds