FORGE-203 — The Living Organism Experience

FORGE-203 — The Living Organism Experience

Project Forge — Fourth Execution Document Status: Normative for execution. Implements FORGE-002 (Truth Over Illustration), FORGE-003 (the Experience Bible), FORGE-200, FORGE-201, and FORGE-202; introduced by Capability 8A; extended by Capability 8C, which precedes an organism’s runtime identity readout with a symbolic Emergence (Part 9). Precedence: the constitutional corpus (FORGE-001 … FORGE-103) governs; FORGE-200 governs how the engine executes; FORGE-201 and FORGE-202 govern why the engine and Mjolnir live apart and what each repository owns. This document does not amend any of the four; it specifies the one surface where a reader meets the engine or an organism for the first time, and binds every organism that follows to the same discipline. Where a reading of this document contradicts FORGE-002, FORGE-200, FORGE-201, or FORGE-202, they govern.

Preamble

FORGE-201 and FORGE-202 finished a physical separation: the engine in projectforge.dk, the first organism in forge-mjolnir at mjolnir.projectforge.dk. That separation was architectural before it was ever visible — a reader arriving at either address had, until now, watched the same typed terminal recite the same words, “Initializing Project Forge…”, regardless of which one they had opened. An engine that is timeless and an organism that is a running cluster were introducing themselves identically. That was never a rendering bug; it was the split not yet reaching the one surface a visitor meets before anything else.

Capability 8A closes that gap. It gives each site a wake-up sequence that says what it actually is, and binds three things that must stay true as both evolve: the two sequences must feel related but be fundamentally different, in the same way FORGE-201 Part 1 draws projectforge.dk and mjolnir.projectforge.dk as answering two different questions; every value either sequence shows must be real, per FORGE-002 Principle 1, Truth Over Illustration; and the choice to see or skip either one must belong entirely to the visitor.

One sentence carries this document:

An introduction is architecture, not decoration — the engine wakes as an idea becoming executable; the organism wakes as a running instrument reporting on itself; and nothing either one shows may be invented.

Part 1 — Why the engine and the organism wake differently

FORGE-201 Part 1 already drew the line these two sequences dramatize: projectforge.dk answers “what is Forge?”; mjolnir.projectforge.dk answers “what is Mjolnir doing right now?” An introduction that answered both questions the same way would quietly undo that distinction on the one page every visitor sees first, regardless of what the two repositories’ READMEs said about themselves.

The engine’s sequence (Part 2) has nothing to report, because the engine has no runtime state — it is architecture, “not a computer, not an HPC cluster” in the brief’s own words, and its wake-up shows exactly that: a small number of ideas the constitution already names, in the order the constitution already gives them, with nothing that resembles a system initializing. The organism’s sequence (Part 3) has everything to report, because Mjolnir is a real, running instrument with a scheduler, a node count, and registered capabilities discovered from its own declaration — and its wake-up is a readout of that self-knowledge, not a demonstration of it.

Part 2 — The Project Forge introduction

The engine’s sequence (js/forge-intro-engine.js) is deliberately short and deliberately empty of system language: silence, a single pulse, then four calm words — “Project Forge,” “The Instrument,” “The Principles,” “The Architecture” — resolving to “Ready.” Every word names something the constitutional corpus already calls itself (FORGE-001’s “the instrument,” FORGE-002’s principles, FORGE-100’s architecture); none is a status message, and none simulates hardware.

This is why the previous sequence — a typed terminal listing “Loading ontology… OK,” “Loading truth engine… OK,” and so on — was replaced rather than kept for the engine and reused for the organism. It read as a BIOS: plausible-sounding subsystem names, resolving through dot-leaders to a synthetic “OK,” exactly the imitation FORGE-002 Principle 1 forbids when the thing being loaded does not, in fact, exist as a discrete boot stage. The engine does not “load a truth engine” at 09:14 on a Tuesday; it is a repository of code and prose that either exists or does not. Naming that fact calmly is the whole of what an engine’s introduction can honestly do.

Part 3 — The Mjolnir introduction

The organism’s sequence (forge-mjolnir/js/forge-intro-mjolnir.js) reads as a runtime identity readout: Project Forge Runtime / Loading organism…, then Mjolnir’s name, its institution, its scheduler, its node and GPU counts, its storage, its registered capabilities, closing on Identity established. / Runtime ready. / Entering organism. — established, not verified, because this is the organism stating its own identity, not authenticating against anything external. Presentation is quicker and more clinical than the engine’s — short fades measured in a few hundred milliseconds, monospace label/value rows, no blinking cursor, no character-by-character typing — because Mjolnir’s personality (per the brief) is Nordic, precise, industrial, and quiet, not cyberpunk and not a demo of hacking.

Every value in that readout is either fetched live from public/mjolnir/identity.json — the organism’s own runtime identity document (FORGE-200 Part 4) — or, where the runtime does not yet publish a fact, drawn from a verified static record checked into forge-mjolnir itself (Part 4, below). Nothing is fabricated in either case; the difference is only which system currently holds the truth.

Part 4 — Static identity: what it is, and what it is not

FORGE-200’s identity document today carries an instance’s id, name, organization, branding, and registered features — enough to answer “what is this organism, and what can it do?” It does not yet carry cluster topology: node counts, GPU counts, storage capacity, or an organisational unit below “University of Copenhagen.” Those facts are true of Mjolnir today, but no capability yet composes and publishes them.

The static identity object in forge-intro-mjolnir.js exists to hold exactly those facts, and no others, until a capability does. It is not a second source of truth alongside the runtime document; it is a fallback consulted only where the runtime document is silent. The lookup for every one of these fields is written the same way — instance.department || STATIC_IDENTITY.department — so that a future runtime publication is preferred automatically, without deleting anything, the moment the field exists. Capabilities list is not part of this fallback in the same sense: identity.json already publishes it today (instance.features), so that value is live now, not a future migration.

Nothing in this object may be a guess. Every value — GLOBE Institute, Slurm, 18 compute nodes, 3 GPU nodes, 1.8 PB of storage — is a fact about Mjolnir as it exists, supplied to this capability the same way FORGE-200’s identity fields were: as ground truth, not illustration.

Part 5 — Migration: from verified static identity to runtime publication

The wording a visitor reads never needs to change when a fact migrates from static to published. “Scheduler” stays the label; only whether its value comes from STATIC_IDENTITY.scheduler or instance.scheduler changes, and that change happens once, in the lookup line, not in every place the word “Scheduler” appears. This is the same discipline FORGE-200 Part 6 states for capabilities — “adding a capability means adding a manifest, never editing the engine” — applied to a single capability’s frontend instead of the runtime that composes it.

Symmetrically, if a capability is later withdrawn — a domain no longer enabled, a feature removed from forge-instance.json — the next composed identity.json will not list it, and the introduction’s capabilities readout will not either, because that list is generated from the document, never hand-authored. No future capability needs to remember to update this file for that case; it already doesn’t know Mjolnir’s capabilities except by asking.

Part 6 — Accessibility: Skip Introduction, and never trapped

Both sequences share one vendored module, js/forge-intro.js, which owns everything about how an introduction runs, so that what it shows (Parts 2–3) can differ freely without accessibility differing at all:

Part 7 — Performance

The introduction is never a blocking resource. Every script that composes it (forge-intro.js and its site-specific renderer) loads defer, after the document is parsed, exactly like the ambient and scroll-reveal scripts it now sits beside. With JavaScript disabled, #boot never renders (.no-js #boot { display: none !important; }, decided by the inline head script before first paint) and the normal page appears immediately — there is no degraded or partial introduction for a no-JS visitor, only its complete absence.

Part 8 — How future organisms inherit the experience

js/forge-intro.js is vendored verbatim into every organism, exactly like js/forge.js and js/forge-audio.js already are (FORGE-201 Part 3: “its vendored engine”). It knows nothing about Mjolnir, or any other organism — it exposes one contract, ForgeIntro.register(renderFn, options), and owns Skip Introduction, localStorage, focus handling, and reduced motion identically for whichever organism vendors it.

A new organism’s introduction is exactly one new file: its own js/forge-intro-<name>.js, calling ForgeIntro.register with a render function that reads its own public/<namespace>/identity.json, falls back to its own verified static identity where the runtime is not yet publishing a fact, and calls ctx.finish() when done. Nothing about creating that file touches forge-intro.js, and nothing about it is specific to HPC — a biology-domain organism’s introduction reads a biology-domain identity document the same way, following this Part exactly as FORGE-201 Part 4 already requires for creating the organism itself.

Part 9 — Emergence

Capability 8A gave the organism a wake-up sequence that reads its own runtime identity (Part 3). Capability 8C precedes that readout with a few seconds that read nothing: darkness, a single distant pulse, and a small number of geometric fragments locking into the shape of Mjolnir’s hammer before the first factual line — “Project Forge Runtime” — appears. This is not a second boot stage bolted onto the first. It is the answer to a question the readout alone never asks: what is the Runtime’s relationship to the organism it is about to describe?

The Runtime does not create Mjolnir. Mjolnir is a real, already-running cluster — a scheduler, eighteen compute nodes, a body of registered capabilities — whose existence does not depend on a browser tab being open. What the Runtime does, each time a visitor arrives, is synchronize with that organism and publish what it finds. Emergence dramatizes exactly that distinction, and no other: the Forge is not manufacturing an organism from nothing, it is revealing one that was already there. A boot sequence would show the opposite — components initializing into existence, one subsystem coming alive after the last, the exact BIOS grammar FORGE-002 Principle 1 and Part 2 above both already forbid. Emergence never claims a subsystem is loading; it claims nothing at all. The hammer assembling is not a diagram of Mjolnir’s architecture and is not a status report — it is symbolic, precisely because nothing about it is offered as fact.

That is also why the hammer must not resemble a boot log with different graphics. Nothing in the sequence carries a label, a value, a percentage, or a name; nothing resolves through a dot-leader to an “OK.” A visitor who has watched it cannot report anything Mjolnir-specific they learned from it, because it teaches nothing — it only sets a tone the factual readout then earns. Symbolism ends, absolutely, the instant “Project Forge Runtime” appears: from that first line onward every word is real, in the same sense Part 3 already established, and Emergence is never permitted to reappear or bleed into it within a single run of the sequence.

Emergence is organism-specific in exactly one respect and generic in every other. js/forge-emergence.js is vendored like js/forge-intro.js (Part 8): it owns silence, pacing, staggering fragment reveals, a single controlled impact, and cleanup, and it does not know what a hammer is. An organism supplies its own symbol — geometric fragments, an SVG, a small number of decorative sparks — through ForgeEmergence.run(ctx, { buildSymbol, cues, timing }); nothing about creating that symbol touches forge-emergence.js itself. A future biodiversity organism reveals a leaf; a future astronomy organism reveals a constellation; a future climate organism reveals atmospheric flow. In every case the runtime identity readout that follows is unchanged in kind, only in the facts it reports, per Part 3 and Part 5.

Emergence is also the one place in this document where prefers-reduced-motion does not mean “no sequence at all.” Part 6 makes reduced motion suppress an introduction entirely because, for the engine, the introduction is nothing but atmosphere — suppressing it costs a visitor nothing they needed. Mjolnir’s full sequence is not purely atmosphere: everything after Emergence is the same runtime identity a visitor would otherwise only get by sitting through an animation first, and suppressing that too would cost a reduced-motion visitor real information, not just motion. So forge-intro-mjolnir.js opts in (reducedMotionAware: true) to running at all under reduced motion, and receives ctx.reducedMotion so it can skip straight past the symbolic hammer to “Project Forge Runtime.” Reduced motion still removes every frame of Emergence itself, exactly as strictly as it always has for the engine; it only stops removing the facts standing behind it.

Part 10 — What this document binds