FORGE-100 — Architecture of the Living Scientific Instrument

FORGE-100 — Architecture of the Living Scientific Instrument

Project Forge — First Engineering Document Status: Architectural Constitution (normative). Supersedes nothing; implements FORGE-001, FORGE-002, FORGE-003. Where this document and FORGE-002 disagree on meaning, FORGE-002 governs. Where they disagree on construction, FORGE-100 governs. Meaning has precedence over construction; construction has precedence over wishful thinking. Commitment 1 below — “Mjolnir is the first implementation, not the subject” — was a rule about how to read code and documents sharing one repository. FORGE-201 and FORGE-202 made it a rule about repositories themselves: the engine (this repository) and Mjolnir (forge-mjolnir) now physically live apart. Nothing in this document required revision to make that true; it only had to stop being aspirational.

Preamble

The founding trilogy established that Project Forge is not a website but the maintained public record of a scientific instrument, expressed as a small ontology of Objects, Events, and Measures, published as durable documents. Those documents proved that the vision is coherent. This document exists to answer a colder question: whether it is constructable — and if so, by what structure, with which decisions made irreversibly and which held deliberately open.

I write here as Chief Systems Architect, Chief Information Architect, and Chief Software Architect, and the three roles do not always agree. Where they conflict, this document records the conflict rather than hiding it. My loyalty is not to the vision. My loyalty is to the future readers and maintainers of whatever gets built — the person at 01:40 in FORGE-003 Part 2, and the maintainer in year five in FORGE-002 Principle 11. Architecture that flatters the vision at their expense is malpractice.

Two commitments frame everything below:

  1. Forge is an architecture, not an application. It describes how the digital presence of any scientific instrument may be constructed. Mjolnir is the first implementation, not the subject. Nothing in Parts 1–16 may name Mjolnir except as an illustration explicitly marked as such. If a decision here only makes sense for one HPC centre in Denmark, it is in the wrong layer (see Part 13).

  2. Forge is a truth-maintenance system before it is anything else. Presentation, search, analytics, and narrative are all derivations. The hard part — the part that earns the trilogy’s promises — is keeping one timestamped, provenanced, single-homed account of a changing physical reality, and publishing it so that it survives the team. Everything visually memorable in FORGE-003 is a cheap consequence of getting that one thing right, and impossible without it.

Terminology (RFC-2119 sense)

MUST / MUST NOT — a constraint whose violation makes the artifact not-Forge. SHOULD / SHOULD NOT — a strong default; departures are recorded in the Record with a reason (per FORGE-003 Part 10’s closing rule). MAY — genuinely optional.

Defined terms used throughout are collected in Part 2 and Part 10; the load-bearing ones are Object, Event, Measure (FORGE-002 §3.1), Facet, Provenance Stamp, System of Record, Truth Store, Snapshot, Projection, View, Contract, and Adapter.

Part 1 — Executive Architecture

1.1 The one-sentence architecture

Forge is a pipeline that materialises a changing physical reality into one canonical, timestamped, single-homed body of truth, freezes that truth into immutable addressable artifacts, and derives every human-facing surface — pages, search, reports, narratives — as pure functions of those artifacts, gated only by identity.

Every noun in that sentence is a layer. Every verb is a boundary with a contract. The remainder of this document is that sentence, expanded and defended.

1.2 The conceptual shape

Forge is not a request/response system with a database behind it. It is a unidirectional flow from reality to reader, in which truth moves in exactly one direction and is transformed, never duplicated, at each step:

        SYSTEMS OF RECORD                 (reality's own authorities — external)
   Slurm · CMDB · LDAP · TSDB · procurement · CI · publication registries
                │
                │  adapters (Implementation Layer)   ── the only Forge code that
                ▼                                        knows a specific instrument
        ┌───────────────────┐
        │   ONTOLOGY LAYER  │  the language: object/event/measure types, relations
        └─────────┬─────────┘  (definitions only — depends on nothing)
                  │  conforms-to
                  ▼
        ┌───────────────────┐
        │    TRUTH LAYER    │  one canonical instance of every fact, deduplicated,
        │  (mutable store)  │  provenance-stamped, single-homed
        └─────────┬─────────┘
                  │  freeze
                  ▼
        ┌───────────────────┐
        │ PUBLICATION LAYER │  immutable, content-addressed, time-stamped snapshots
        │   (the record)    │  — the durable artifact that survives the team
        └─────────┬─────────┘
                  │  project (pure, deterministic, regenerable)
      ┌───────────┼───────────────────────────┐
      ▼           ▼                            ▼
 ┌─────────┐ ┌─────────┐                 ┌───────────┐
 │  VIEWS  │ │ SEARCH  │   KNOWLEDGE ──▶ │ ANALYTICS │   (derivations — own nothing)
 └────┬────┘ └────┬────┘   (curated,     └─────┬─────┘
      │           │         bound to            │
      ▼           ▼         objects)            ▼
        ┌───────────────────────────────────────┐
        │           PRESENTATION LAYER           │  design system, the six worlds
        └───────────────────┬───────────────────┘
                            │
                            ▼
        ┌───────────────────────────────────────┐
        │           INTERACTION LAYER            │  walk · ask · scrub time
        └───────────────────────────────────────┘

   ┌───────────────────────────────────────────────────────────────┐
   │  IDENTITY LAYER  — orthogonal. Gates read-time occlusion of     │
   │  private facets at every layer above Truth. Never forks         │
   │  structure; only varies what is emitted. (FORGE-002 §3.6)       │
   └───────────────────────────────────────────────────────────────┘

1.3 The three properties this shape buys

The unidirectional flow is not aesthetic. It is chosen because it is the only shape that structurally guarantees the trilogy’s three hardest promises:

1.4 What this architecture deliberately is not

1.5 The governing invariant

One sentence, to be quoted in every architecture review the way FORGE-002’s principles are quoted in design review:

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.

If any proposed component stores a second copy of a fact, or shows a reader something that is not derivable from stored facts + identity, it violates the invariant and is presumed wrong until the review records why (Part 15, ADR-003).

Part 2 — System Layers

Each layer is specified as: Purpose · Responsibilities · Owns · May depend on · MUST NOT depend on. The dependency rule is global and absolute:

Dependencies point downward only. A layer may depend on the layers below it and MUST NOT depend, in any form — code, schema, assumption, or vocabulary — on any layer above it. The Identity and Implementation layers are orthogonal and specified separately.

Downward dependency is what makes the architecture reusable: the Truth Layer cannot be contaminated by a presentation decision, so a second university reusing Forge inherits the truth machinery untouched and rebuilds only what is genuinely theirs (Part 13).

2.0 Layer 0 — Source Layer (Systems of Record)

Purpose. The external, authoritative systems where facts about the instrument are born: the scheduler, configuration-management database, directory, time-series metrics store, procurement/asset records, CI, publication and grant registries.

Responsibilities. To be authoritative for their own domain. That is all. They owe Forge nothing and are not modified by Forge.

Owns. The origin of observed truth. A System of Record is authoritative for its domain; Forge is authoritative for the published account. These are different authorities and the distinction is load-bearing (Part 3.2, ADR-004).

May depend on. Nothing in Forge. The Source Layer predates and outlives any Forge implementation.

MUST NOT depend on. Forge, in any way. If a source system must be changed to accommodate Forge, that change lives in the Implementation Layer as an adapter concern, never as a demand on the source.

This layer is drawn to make one thing explicit: Forge does not own the birth of truth, only its canonical keeping and publication. Pretending otherwise is the mistake that turns a presence layer into a second operational system nobody asked for.

2.1 Layer 1 — Ontology Layer

Purpose. To define the language: the object types, event types, measure types, relation types, and facet classifications of FORGE-002 Part 3, expressed as machine-readable, versioned schema.

Responsibilities. Hold the canonical vocabulary and its constraints (which relations are legal between which types; which facets exist on which object; each facet’s classification and expected provenance shape). Enforce FORGE-002 §3.6 rule 5 (amendment, not accretion): changing this layer is a constitutional act.

Owns. Meaning. Nothing else. The Ontology Layer contains no instances — no actual node, no actual job — only the definition of what a node and a job are.

May depend on. Nothing. This is the root. It is pure definition and MUST be expressible with zero reference to any storage technology, rendering technology, or specific instrument.

MUST NOT depend on. Everything above it, and the Source Layer below it. The ontology does not know that Slurm exists; that knowledge lives in adapters.

2.2 Layer 2 — Truth Layer

Purpose. To hold exactly one canonical instance of every fact — the deduplicated, provenance-stamped, single-homed materialisation of reality in the ontology’s language.

Responsibilities. Deduplicate (one home per object, §3.6 rule 2); stamp every fact with provenance and time (Principle 3); maintain object identity across source churn (Part 4); reject facts that do not conform to the Ontology Layer; retain history append-only where feasible (Part 4.8, Part 9).

Owns. The single source of truth within Forge. This is the referent of FORGE-002 Principle 2. Every value a reader ever sees traces to exactly one fact here.

May depend on. The Ontology Layer (it stores instances of those types). It receives data from adapters (Implementation Layer) but does not depend on them — it defines an ingestion contract they must satisfy, and remains ignorant of which source satisfied it.

MUST NOT depend on. Publication, Knowledge, Views, Search, Analytics, Presentation, Interaction. Truth does not know it will be shown. This is the single most important forbidden dependency in the system: the moment the Truth Layer knows about a view, views stop being free and truth stops being neutral.

2.3 Layer 3 — Publication Layer

Purpose. To freeze the mutable Truth Store into immutable, content-addressed, time-stamped Snapshots — the durable artifacts that constitute the public record and survive the team.

Responsibilities. Produce append-only, self-describing snapshots; guarantee permanent addressability (a citation to an object or a moment resolves forever, Principle 2 / §3.6 rule 1); expose the stable data contracts (Part 10) at its boundary; carry each snapshot’s own build time so freshness is intrinsic, not asserted (Part 3.6).

Owns. The durable record. If everything above vanishes, the latest snapshot is Forge — complete, readable, citable, offline-capable (Part 12).

May depend on. The Truth Layer (it freezes it) and the Ontology Layer (snapshots are self-describing in ontology terms).

MUST NOT depend on. Anything above it. A snapshot MUST be interpretable with no running Forge service — only the published ontology schema it references. A snapshot that requires a live server to be read has violated FORGE-001 Principle 8 and is not a snapshot.

2.4 Layer 4 — Knowledge Layer

Purpose. To hold the human-authored content the ontology cannot generate — Documents and Stories (FORGE-002 §3.2 Knowledge/Science layers) — bound to the objects they are about / draw-on.

Responsibilities. Store curated prose whose judgment is human but whose changeable facts are transcluded from published truth, never typed (Principle 9); declare each document’s object bindings so knowledge arrives (Principle 6); version prose independently of the truth it cites (Part 7).

Owns. Intent, judgment, narrative, warning — the things telemetry cannot produce.

May depend on. Publication (for transcluded facts), Ontology (for bindings). It is deliberately placed above Publication and below Views: knowledge is a first-class input to projection, not a projection itself.

MUST NOT depend on. Views, Search, Analytics, Presentation, Interaction. A document does not know how it will be displayed or found. (Search indexes documents; documents do not know about search.)

2.5 Layer 5 — Derivation Layer (Views, Search, Analytics)

Purpose. To compute every derived artifact — pages/views, search indices, aggregated measures, reports — as pure, deterministic Projections of published snapshots plus knowledge.

Responsibilities. Be regenerable from scratch at any time; own no truth; be freely creatable and freely deletable (§3.3: objects are permanent and expensive, views are temporary and free); label every derived measure as derived, with method (Principle 3, §3.3 on carbon).

Owns. Nothing durable. Every projection is disposable and reproducible. Deleting the entire Derivation Layer and rebuilding it MUST yield byte-equivalent output from the same snapshot (determinism), which is the property that makes views safe to invent.

May depend on. Publication, Knowledge, Ontology.

MUST NOT depend on. Presentation, Interaction. A projection produces structured derived data (a view model, an index, a report model); it does not know about fonts, colours, or the six worlds. Search ranking is derivation; search appearance is presentation.

2.6 Layer 6 — Presentation Layer

Purpose. To render view models into the visual medium — the design system, typography, the atmospheres of the six worlds (FORGE-002 Part 4), the calibrated-instrument aesthetic (FORGE-002 Part 7).

Responsibilities. Translate structured view models into accessible, responsive, theme-aware surfaces; enforce the visual grammar at every depth (Principle 10); ensure every ambient signal has a textual truth beneath it and every visualisation is readable as structured data (FORGE-001 §15 accessibility; FORGE-002 Principle 1).

Owns. The look. No truth, no derivation logic.

May depend on. The Derivation Layer’s view models, and the Ontology (to render an object’s five-question anatomy uniformly, §3.6 rule 3).

MUST NOT depend on. Truth, Publication, or Source directly. Presentation MUST NOT reach past Derivation to fetch a fact — if it needs a fact, the fact belongs in a view model. This prevents the classic rot vector where a template hard-codes a number.

2.7 Layer 7 — Interaction Layer

Purpose. The reader’s live acts: walking edges, asking (search), scrubbing time, and surfacing private facets after sign-in.

Responsibilities. Compose already-published, already-projected artifacts at read time; degrade with dignity when a live pipeline is unavailable (Principle 12); never create truth — a reader’s interaction reads the record, it does not write it (with the sole, bounded exception of authored events, Part 9, which is an operator act mediated back through the Source/Truth path, not a reader act).

Owns. Session state and navigation state only. Nothing durable, nothing truthful.

May depend on. Presentation, and through it the layers below.

MUST NOT depend on. Anything writing back into Truth on a reader’s behalf. Reading is public and free; writing is an authored, authorised, recorded act that does not originate in the Interaction Layer.

2.8 The Identity Layer (orthogonal)

Purpose. Authentication, authorisation, and the enforcement of per-facet privacy classification (Principle 8, §3.6 rule 4) — the transparency gradient made mechanical.

Responsibilities. Determine, for a given reader and a given facet, whether the facet is emitted or occluded; guarantee that occlusion happens by omission from the projection the reader receives, never by delivering private data and hiding it in the client; keep the public path entirely free of authentication (the public instrument MUST be readable with no identity at all).

Owns. The mapping (reader, facet) → {emit, occlude, aggregate}.

Relationship to the stack. Orthogonal: it gates what every layer above Truth may emit, without altering structure. There is one structure; identity varies only occlusion (Principle 10). Architecturally, Identity is a filter over projections, and the public projection is simply the projection under the null identity.

May depend on. The Ontology (facet classifications) and an external identity provider (Source Layer).

MUST NOT depend on. Presentation or Interaction deciding privacy. Privacy is decided at classification time in the ontology and enforced at projection time; the UI never decides who sees what.

2.9 The Implementation Layer (orthogonal)

Purpose. To bind a specific instrument into the generic architecture: the Adapters that map its Systems of Record into ontology facts/events/measures, plus instance configuration and instance-specific assets.

Responsibilities. Satisfy the Truth Layer’s ingestion contract; own every fact that is true of this instrument and false of others (its scheduler’s quirks, its node names, its grid’s carbon-intensity feed); contain all instrument-specific code, so that Layers 1–7 remain instrument-neutral.

Owns. Everything Mjolnir-specific, BioHPC-specific, telescope-specific. This is the only layer a second adopter substantially rewrites (Part 13).

May depend on. The Ontology (the language it must speak) and its own Systems of Record.

MUST NOT depend on. Presentation, Views, Search. An adapter does not know how its data will be shown or found. If an adapter contains a colour, a page title, or a ranking rule, the layering has failed.

2.10 Reading the dependency rule as a test

For any file, module, or decision, ask: which layer is this? Then: does it reference anything from a higher layer, or (for L1–7) from the Implementation Layer’s specifics? If yes, it is misplaced. This single test, applied in review, is what keeps a growing Forge implementation from collapsing into the mud of mutual dependency that every “unified platform” eventually becomes.

Part 3 — The Single Source of Truth

FORGE-002 Principle 2 and §3.6 rule 2 demand that truth exist once. This part specifies exactly what that means in construction, and resolves the two apparent contradictions the principle contains.

3.1 The definition

Truth exists once means: for every fact the platform can state, there is exactly one canonical storage location — one Object’s one Facet, in the Truth Layer — from which every appearance of that fact is derived by reference or by pure computation. There are no second copies. A “second copy” includes a hand-typed number in prose, a denormalised value in a view that is not recomputed, and a cached figure that can outlive its source.

3.2 First apparent contradiction: “external sources” vs “one truth”

If Slurm owns job facts and LDAP owns people, how can Forge’s Truth Layer be the single source of truth?

Resolution — two authorities, one canonical home. A System of Record is authoritative for its domain: Slurm decides what a job did. Forge’s Truth Layer is authoritative for the published account: it holds the one canonical, ontology-shaped, provenance-stamped representation that the platform publishes. These never compete, because they answer different questions. The rule (ADR-004):

So there is one source of truth for the platform, sitting downstream of many sources of truth for reality. “Single source of truth” is a statement about Forge’s internal topology, not a claim that Forge is the origin of all facts. Claiming the latter would be the arrogance that makes presence layers rot into shadow operational systems.

3.3 Second apparent contradiction: derived values

Carbon is energy × grid carbon-intensity (FORGE-002 §3.3). Utilisation is busy-cores ÷ total-cores. If these are “facts,” are they stored — and if stored, are they not second copies?

Resolution — the observed/derived split. Every value is exactly one of two kinds:

Duplication is therefore impossible by construction: an observed value lives in one home; a derived value has no home — it is a function, evaluated when needed. Carbon is not a stored number that could drift from energy; it is energy × intensity, recomputed, labelled derived, method stated. When the grid-intensity method changes, every carbon figure changes at once, because none of them was ever a copy.

Rule (ADR-003): If a value can be computed from other stored values, it MUST be derived, not stored. Storing a derivable value creates a second truth that can drift, and is the cardinal data bug (§3.6 rule 2) wearing an optimisation costume. (Performance caching of derivations is permitted only under the strict conditions of Part 12.4, where the cache is provably invalidated by input change.)

3.4 How truth is created

  1. An event in reality (a job ends, a node is racked, a maintenance is performed) registers in a System of Record.
  2. An Adapter (Implementation Layer) reads the source and emits candidate ontology facts/events/measures against the Truth Layer’s ingestion contract.
  3. The Truth Layer resolves identity (Part 4.2) — is this a new object, or a new fact about an existing one? — deduplicates, stamps provenance and time, validates against the ontology, and appends. Observed history is append-only; corrections are new provenance-stamped facts, not overwrites (Part 3.7).
  4. Authored events (maintenance, incidents — Part 9) enter by the same path, with a human author as the “source.” This is the one place a person, not a machine, is the System of Record — which is exactly why authorship is mandatory: it names where that truth came from.

3.5 How truth is published

The Truth Layer is mutable working state — always the latest known reality. It is never read directly by any reader-facing layer. Instead, the Publisher periodically freezes it into an immutable, content-addressed Snapshot (Part 4.8, Part 9.9):

3.6 How truth is consumed, and what “live” honestly means

Everything above Publication consumes snapshots. This forces an honest reconciliation of the trilogy’s central tension — ambient live state (FORGE-001 §7) versus static publication (FORGE-001 Principle 8) versus show the age of every fact (Principle 3):

“Live” means “as of the last published snapshot,” and the platform always shows which snapshot. A value refreshed every N minutes is honestly “live (updated every N minutes; as of 14:32),” never “live” unqualified.

This is not a compromise of the vision; it is the vision’s own Principle 3 applied ruthlessly. FORGE-002 §1.1 already retired the breathing aurora precisely because it implied a continuity the data does not have. The snapshot model makes the honest thing the only expressible thing: a surface cannot claim to be more current than the snapshot it was projected from, because that is all the data it has. Freshness is intrinsic, not asserted by someone remembering to add a caveat.

3.7 How duplication is prevented — structurally, not procedurally

The deep point: FORGE-002 treats “two disagreeing descriptions of one thing” as the cardinal bug. This architecture makes that bug unrepresentable for observed and derived values alike, rather than merely forbidden. A principle you cannot violate is stronger than one you must remember.

Part 4 — Canonical Objects

The sixteen objects of FORGE-002 §3.2 are the expensive, permanent citizens of the system. This part specifies their architectural behaviour. The unifying idea: an object is a stable identity wearing a time-ordered set of provenance-stamped facets, events, and measures.

4.1 Identity

Every object has a permanent, opaque, instrument-scoped identifier and a permanent URL derived from it. The identifier form (normative):

forge:<instrument>:<type>:<local-id>
    e.g.  forge:mjolnir:node:c042     forge:mjolnir:software:gromacs

4.2 Identity resolution (the hard part)

Sources do not hand Forge stable identifiers; they hand it natural keys that drift (hostnames get reused, usernames get recycled, a software is renamed upstream). The Truth Layer MUST maintain an identity map from source natural keys to Forge identifiers, and this map is itself provenance-stamped, append-only truth. Rules:

This is unglamorous and it is where real implementations bleed. It is specified here, in the constitution, precisely because it will be tempting to skip.

4.3 Lifecycle

Objects have exactly three lifecycle states, marked by events (§3.4):

4.4 Versioning

Two distinct kinds of change, kept architecturally separate:

The Ontology Layer itself is versioned (schema evolution). A snapshot names its ontology version; a reader of a 2027 snapshot reads it under the 2027 ontology. Ontology changes are the constitutional amendments of §3.6 rule 5.

4.5 Relationships

The thirteen relations of FORGE-002 §3.5 are first-class, bidirectional, and typed by the ontology. Architecturally:

4.6 Ownership

“Ownership” of an object’s truth is assigned per object type, not per instance, and recorded in the ontology as the object’s authoritative source(s):

4.7 Permanent URLs, extensibility, private facets

4.8 Historical snapshots

Because the Publication Layer is a growing chain of immutable snapshots (Part 3.5), an object’s state at any past published moment is directly addressable: the object as of snapshot S. This gives, for free:

Snapshot storage growth is a real cost, addressed honestly in Part 12.5 and the Final Review — the architecture buys durability and time with disk, and must bound that bill deliberately.

Part 5 — Views

Views are the safety valve of the whole architecture. FORGE-002 §3.3 states the doctrine — objects are permanent and expensive; views are temporary and free — and Part 5 makes it structural, so that all product invention can happen without ever touching truth.

5.1 What a view is

A View is a Projection: a pure, deterministic function from a published snapshot (plus knowledge) to a structured view model. A page, a report, a dashboard-shaped surface, a queue, the homepage, the six worlds’ landing surfaces, the executive altitude view — all are views. None is an object; none is stored as truth; each is regenerable and disposable.

5.2 How infinitely many views coexist with one truth

Because a view is a function of truth and never a copy of truth, there is no upper bound on how many may exist. A thousand views of one snapshot are a thousand readings of one instrument — they cannot disagree with each other or with the truth, because each is derived, at build time, from the same frozen source (Part 3.6 consistency). This is the precise architectural cash-out of “one world, many depths” (Principle 10): depth and altitude are view parameters, not separate datasets.

The only cost of a new view is its own upkeep (Principle 11) and its computation — never a risk to truth. This is why the architecture can be generous with views and miserly with objects.

5.3 How views are added

5.4 How views evolve

Views evolve freely and independently, because nothing depends on them (they are top of the stack, Part 2.5–2.7). A view’s model may be reshaped, its ranking retuned, its presentation redesigned, without any change below the Derivation Layer. This is the property that lets Forge’s look be redesigned every few years while its truth — and therefore its citations and its trust — remain stable for decades. FORGE-002 §8 foresaw exactly this: “interfaces can be redesigned; a language, once spoken everywhere, cannot.”

5.5 How views disappear

A view is retired by deleting its projection and presentation. Because it owned no truth and nothing below depended on it:

Part 6 — Search Architecture

Search is the platform’s primary instrument (FORGE-002 Part 5, correcting FORGE-001’s “search is the entire interface”). Architecturally, search is a Projection like any other (Part 2.5) — which is what keeps it truthful and implementation-independent.

6.1 What search indexes

Search indexes the ontology’s citizens in their published form, not web pages:

Because the index is a projection of a snapshot, the index cannot contain anything the truth does not — no phantom results, no stale entries surviving their objects. When an object ends, the next index build reflects it. Search rot is a build failure, like all rot here.

6.2 How search returns things, not lists

The index maps a query to typed answers (object / state / how-to / event / exploratory map — FORGE-002 §5.1), and to an explicit fork when a query legitimately means several things (§5.2). Architecturally this means the search projection emits a typed answer model, not a ranked list of URLs; the Presentation Layer renders that model as an object card, a reading, a document opened in place, or a small map of responding regions. Ranking and forking are derivation concerns; their appearance is presentation — the two are separated by the Part 2.5/2.6 boundary, so ranking can be retuned without redesign and vice versa.

6.3 Contextual intelligence, honestly bounded

Search answers wear the machine’s current condition (§5.3) — but only by joining published measures and events to the answer at projection time, each carrying its own age (Principle 3), each vanishing rather than going stale if its pipeline breaks (Principle 11). Context weights the fork; it never hides a tine (§5.2), because silent guessing trains distrust. All of this is expressible as pure projection over a snapshot plus the reader’s context — no hidden model, no unaccountable ranking.

6.4 The honest zero

The zero-result state is a designed projection (FORGE-002 §5.5; FORGE-003 Part 9’s exhibited poster): nearest real objects, a plain admission that the platform may not hold the answer, and a human door. It MUST be produced by the same search projection, so it cannot be forgotten — an empty result is a rendered outcome, not an unhandled case. Zero-result queries are themselves recorded (as aggregate, privacy-respecting telemetry) because they are the platform’s most valuable errata list (§5.5).

6.5 How search stays implementation-independent

This is the architecturally decisive property. Search is kept independent of any particular engine by three rules:

  1. The index is a published artifact with a stable contract (Part 10.5). Whatever builds it — a static client-side index for small instruments, a search service for large ones (Part 12.3) — MUST produce the same contract. The rest of the system depends on the contract, never the engine.
  2. Search consumes only snapshots. It has no privileged access to truth. Swapping the engine changes how the index is built and queried, never what truth it reflects.
  3. Ranking is a projection, not a black box. Its inputs are published facts; its method is stated. An unaccountable relevance model that cannot explain its ordering violates Principle 1 (truth over illustration) applied to search, and is rejected.

Consequently a small instrument may ship a fully static, in-browser search over a partitioned index (no server at all — Part 12.3), and a national infrastructure may run a query service behind the same contract, and neither the ontology, the truth, nor the presentation changes. That is implementation independence, demonstrated at the hardest layer.

Part 7 — Knowledge Architecture

Living documentation (FORGE-002 Principle 6, 9; §3.2 Document; FORGE-003 Part 6) is the feature most prone to rot in every prior system, and the architecture’s job is to make rot impossible, not merely discouraged.

7.1 The split that prevents rot

Every Document is divided, mechanically, into two kinds of content:

A transclusion is a binding to an object’s facet, resolved at projection time against the current snapshot. Because the fact is a reference, not a transcription, it cannot be stale: it is whatever the snapshot says, or the build fails (Part 7.4). This is the entire anti-rot mechanism, and it is structural.

7.2 How documentation attaches to objects

Every Document declares its about bindings (§3.2, §3.5) — the objects it concerns. Two consequences:

Binding is the architecture of “the checklist mounted on the instrument” (FORGE-003 Part 6). The document does not go anywhere; its bindings make it appear wherever its subject lives.

7.3 How documentation is versioned

7.4 How documentation survives software changes — and cannot rot

7.5 Why this survives the software itself

Because Documents live in the Knowledge Layer above Publication and below Views (Part 2.4), and their facts are transclusions from snapshots, a document is readable from any snapshot with no running service (Part 12): the prose is text, the facts are in the snapshot, the bindings are in the snapshot. The operator’s handbook survives the platform that displayed it — which is the durability FORGE-001 Principle 8 demands, extended to knowledge.

Part 8 — Analytics Architecture

FORGE-002 §8 and Part 7 retire the dashboard as a genre and the word from the vocabulary. Architecturally: analytics is not a layer, a module, or a section — it is the Measure third of the triad, surfaced on objects and composed by projections. There is one measurement system and zero analytics sections (FORGE-001 §8).

8.1 Measurements belong to objects

A Measure is never free-floating (§3.1): every measurement is measured-on exactly one object, carries its unit, method, and time, and is stored once in the Truth Layer with provenance. There is no “metrics store” separate from the object it describes. Utilisation lives on the Partition; energy on the Job; temperature on the Node; adoption on the Software. This is the structural cure for the dashboard, which FORGE-002 diagnoses precisely as measures torn away from their objects.

8.2 How derived metrics work

Per Part 3.3, a metric that is a function of observed measures is derived, never stored: computed by a named projection, labelled derived, method stated, age of inputs shown. Carbon = energy × grid-intensity is the canonical derived metric (§3.3) and MUST always be labelled derived with its method. Utilisation, efficiency, cost-per-result, adoption trends — all derived projections over stored measures. Because they are functions, they cannot drift from their inputs, and changing a method changes every dependent figure at once.

8.3 How reports become views

A report is a View (Part 5): a projection composing measures across objects at a chosen altitude and time-window. The executive report is “the same objects viewed from higher altitude” (FORGE-001 §8) — literally, a projection with an altitude parameter, not a separate product. The annual report is a projection over a snapshot range, which is why it is a bookmark in time (Part 4.8) rather than an assembled document: anyone can regenerate it, reproducibly, from the snapshots (Part 2.5).

8.4 How dashboards disappear

They disappear the way any view disappears (Part 5.5): delete the projection. But more deeply, the need for the dashboard-as-container disappears, because its contents were only ever measures that belong on their objects. Once every measure lives on its object (8.1) and every cross-cutting figure is a report-view (8.3), there is nothing left for a dashboard to be except a lens — and lenses are free, disposable, and owned by no truth. “Dashboards disappear” is not a deletion event; it is a category that the triad dissolves, exactly as FORGE-002 §3.1 promised.

8.5 The Ledger as proof

FORGE-002’s Ledger world (Part 4) is the demonstration that analytics needs no home: it “has no objects of its own” — it is energy and carbon facets gathered from every object into one accountable view, always labelled with method and age. Architecturally the Ledger is a pure projection over the measure-facets of many objects, decomposable back to each object it read from (§ “the Ledger is the one world made entirely of edges”). It is the existence proof for Part 8’s thesis: a whole world of analytics, owning zero truth.

Part 9 — Event Architecture

Events are first-class citizens (FORGE-002 §3.1, §3.4). They are the platform’s entire sense of history and, during outage, the world that steps forward (Principle 12; FORGE-002 Part 4 “The Record”).

9.1 The common shape

Every Event shares one structure (§3.4): when · what happened · to which objects (affected) · recorded by whom (author). This uniform shape is what lets the Record be one homogeneous, filterable body rather than a dozen bespoke feeds. The canonical kinds (§3.4) are architecturally subtypes of one Event type, distinguished by a kind facet, not separate systems:

9.2 Events have authors (non-negotiable)

Every event carries an author (§3.4). For machine-detected events (a node fault from the TSDB) the author is the detecting system; for human acts (a maintenance, an incident resolution) the author is the person. Authorship is mandatory because:

9.3 How events relate to objects

Via affected edges (§3.5), bidirectional (§3.5 rule). Therefore:

9.4 Past and future in one substrate

Both are made of the same triad (§3.4), so time-scrubbing across the horizon (FORGE-001) is one continuous mechanism: choose a moment; the Record shows inked events before it and pencilled events after it. The architecture never dresses expectation as fact — an outlook is a labelled projection over historical patterns (§1.2), not a stored prophecy, honouring FORGE-002’s demotion of the forecast to honest historiography.

9.5 Historical snapshots and events

The two mechanisms compose: snapshots capture state over time (an object’s facets/measures as they were); events capture transitions (what happened, authored). Together they answer both “what was true then” (snapshot) and “what changed, when, by whom” (events). Neither alone is sufficient; the architecture keeps both, append-only, so that memory is complete and corrections are visible (Part 4.4).

9.6 Why the Record steps forward during outage

When live pipelines break (Principle 12; FORGE-003 Part 4 maintenance), the derived live surfaces honestly show their staleness or vanish (Principle 11), but the Record remains fully readable because it is published, immutable, and needs no live source (Part 2.3, Part 12). This is by design: the world that depends least on live data is the world the platform leans on when live data is gone. Fail-with-dignity is not a special mode bolted on; it is what the layering produces automatically when the top layers lose their inputs.

Part 10 — Data Contracts

A Contract is the stable, versioned interface at a layer boundary. Per the brief, this part defines architectural contracts, not schemas — the promises each boundary makes, which schemas must later satisfy. Contracts are what let each layer be reimplemented independently (Part 13) and what a second university programs against.

The contract stability rule: a published contract is versioned and additive-by-default. Breaking changes require a new contract version; old versions are supported through a declared deprecation window recorded in the Record. Consumers depend on a contract version, never on an implementation. This rule is what makes every “implementation-independent” claim in this document true rather than aspirational.

10.1 The Object Contract

Every object, at its permanent URL, exposes: identity (permanent identifier + URL), the five-question anatomy (§3.6 rule 3: what it is · state now with age · history · readings · relations), its facets with per-facet provenance and classification, and its lifecycle state. Promise: this shape is uniform across all sixteen object types and stable across redesigns. This uniformity is what makes the platform learnable in one visit (§3.6 rule 3) and is the contract every view relies on.

10.2 The Relationship Contract

Every relation exposes: typed, directional, bidirectionally-traversable edges conforming to the ontology’s legal-relation constraints (§3.5). Promise: from any object you can enumerate its edges and traverse them; the inverse is always available; sparse edges are legitimately empty, never errored (Part 4.5). This is the contract the walkable world (Principle 7) is built on.

10.3 The Measure Contract

Every measure exposes: value · unit · method · measured-on object · time · observed-or-derived flag (and, if derived, its inputs and method). Promise: no measure without unit and time; every derived measure declares its derivation (Principle 3, Part 3.3). This is the contract the Ledger and every reading rely on.

10.4 The Event Contract

Every event exposes: kind · time (instant or interval) · affected objects · author · body. Promise: no unauthored events; every event is filterable by object and time; the Record is the complete, append-only set (Part 9). This is the contract the history-as-query mechanism relies on.

10.5 The Search Contract

Search exposes: a query in → typed answer out interface (object / state / how-to / event / exploratory-map / fork / honest-zero), independent of engine (Part 6.5). Promise: answers are ontology citizens in published form, ranked by stated method; the interface is identical whether backed by a static index or a service. This is the contract that makes search implementation-independent.

10.6 The Documentation (Knowledge) Contract

A Document exposes: prose · about bindings · transclusion points resolving to object facets. Promise: changeable facts are references, not text; unresolved transclusions fail the build; bindings surface the document on its objects (Part 7). This is the contract that makes rot a build failure.

10.7 The Receipt Contract

A Job exposes a Receipt (§3.2; FORGE-001 §”The Receipt”): a human-readable, self-contained account of what ran, how long, on what hardware, consuming what energy, at what derived carbon and cost, with every figure carrying provenance and time, and public/private facets classified. Promise: a receipt is complete and readable on its own, offline, forever — because researchers attach them to papers and funders ask for them (FORGE-002 Part 8). The Receipt is elevated to a named contract here because it is the artifact FORGE-003 Part 9 exhibits under glass; it deserves a stability guarantee.

10.8 The View Contract

A View exposes a view model: structured, presentation-free derived data with a declared upkeep owner and a declared degraded state. Promise: views consume only published truth + knowledge; they own nothing; they are regenerable and deletable without affecting truth or citations (Part 5). This is the contract that keeps invention safe.

10.9 The Identity Contract

Identity exposes: (reader, facet) → {emit, occlude, aggregate}, with the public projection defined as the null-identity case. Promise: privacy is enforced by omission from the delivered projection, never by client-side hiding; the public path requires no authentication; classification is decided in the ontology, not the UI (Part 11). This is the contract that makes the transparency gradient trustworthy.

10.10 The Snapshot (Publication) Contract

A Snapshot exposes: immutable, content-addressed, self-describing (ontology version), self-timed artifacts constituting the complete published record. Promise: a snapshot is fully interpretable with no running service; prior snapshots are never destroyed; any object-at-a-moment is addressable and citable forever (Part 3.5, Part 4.8). This is the contract on which durability, time, and abandonment-grace all rest — and therefore the most important contract in the system.

Part 11 — Privacy

Privacy in Forge is architecture, not policy prose (Principle 8; §3.6 rule 4). The transparency gradient is mechanical: it is impossible, by construction, for a private facet to reach an unauthorised reader, because privacy is enforced where truth is projected, not where pixels are drawn.

11.1 Public and private facets

Every facet of every object is classified at definition time (in the ontology) as one of:

Classification is a required field of the ontology; a facet with no classification MUST NOT be projected (fail-closed — 11.5).

11.2 One structure, occluded — never forked

Per Principle 10 and §3.6 rule 4, there is exactly one structure. The public view is the projection under the null identity; an authorised view is the same projection with more facets emitted. There is no admin site, no researcher portal, no parallel dataset (Principle 10). Occlusion is subtraction from one projection, never a second building. This is what keeps the architecture reusable and honest: a minister and a student traverse the same objects; only facet visibility differs.

11.3 Aggregation and re-identification (the honest hard part)

FORGE-002 §1.2 and Principle 8 promise “aggregate in public, individual in confidence.” Aggregation is where that promise is quietly broken by careless engineering, because a sufficiently sliced aggregate re-identifies an individual (one project, one user, one night). The architecture MUST therefore treat aggregation as a privacy-bearing operation:

This is stated as a first-class privacy mechanism, not a footnote, because FORGE-002 §1.2 correctly identified the naive “anyone may look” as the vision’s most dangerous single error, and aggregation is where that error re-enters through the back door.

11.4 The transparency gradient as a projection parameter

The gradient (Principle 8) is implemented as the Identity Contract (Part 10.9): a function from (reader, facet) to emit/occlude/aggregate. The gradient is not a set of if-statements scattered through the UI; it is one enforcement point at projection time, testable in isolation. A reviewer can ask, of any facet, “who receives this, and where is that decided?” and the answer is always “at classification, enforced at projection” — never “somewhere in the template.”

11.5 Authentication, authorisation, and fail-closed

11.6 Privacy is implementation-independent

Because classification lives in the ontology and enforcement lives at the projection boundary, privacy travels with the architecture, not with any implementation. A second university inherits the classifications (which facet types are private) and supplies only its own identity provider and authorisation rules (Implementation Layer). The shape of privacy — per-facet, one-structure, fail-closed, aggregation-aware — is constitutional and unchanged. This is privacy as architecture, exactly as Principle 8 demands.

Part 12 — Performance Architecture

The performance thesis follows directly from the layering: because the reader consumes frozen, pre-projected artifacts, the fast path requires no computation at read time at all. Speed is credibility (FORGE-002 Principle 16), and the cheapest fast thing is a static file.

12.1 Static publishing as the default

The default execution model (ADR-007) is build-time projection, static delivery: snapshots and their projections (view models, indices, receipts, documents) are precomputed and served as static, cacheable, content-addressed files. This gives:

The static default is not a limitation to design around; it is the thesis (FORGE-001 §”the constraint is the soul”). The architecture treats any non-static component as an exception that must justify itself, never the norm.

12.2 Supporting large infrastructures and millions of objects

Static delivery scales in reads trivially (it is just files). It does not scale trivially in build and index size, and honesty requires naming the thresholds:

12.3 The query-service exception, bounded

For instruments that exceed static thresholds (a national infrastructure; a facility with tens of millions of public objects), Forge permits a read-only query service behind the Search Contract (10.5) and Object Contract (10.1). It is bounded by strict rules so it never contaminates the constitutional core:

This is how Forge powers both a small telescope (fully static, no server) and a national infrastructure (static core + query service) with one architecture — the service is an optional accelerator behind stable contracts, not a fork.

12.4 Caching and incremental builds — without sacrificing truth

12.5 Snapshot storage growth (the honest cost)

Append-only snapshots (Part 3.5, 4.8) buy durability and time at the cost of monotonically growing storage. The architecture bounds this deliberately, not by discarding history (which would break Principle 2’s permanence):

12.6 Mobile, accessibility, offline — as first-class, not adaptations

None of these sacrifices truth, because all of them are projections of the same snapshots — different lenses, one record, consistent by construction (Part 3.6).

Part 13 — Implementation Independence

This part is the acceptance test for the entire architecture: could Forge power a supercomputer, a sequencing centre, and a telescope without changing its architecture? If not, Forge is a Mjolnir framework wearing a general name.

13.1 The test

An implementation of Forge consists of: (the invariant core: Ontology + Truth + Publication + Derivation + Presentation + Interaction + Identity mechanisms) + (an Implementation Layer: adapters + config + assets). Implementation independence holds if and only if adopting Forge for a new instrument requires changes only in the Implementation Layer (and, rarely, a constitutional ontology amendment — 13.5).

13.2 Why the core is instrument-neutral

Every layer above the Implementation Layer speaks only the ontology (Part 2), and the ontology’s sixteen objects are deliberately abstract: Cluster, Node, Partition, Storage, Job, Project, Software, Module, Person, Group, Publication, Dataset, Story, Document, Event, Measure. None of these is HPC-specific in essence — they are the general nouns of a shared scientific instrument that does work for people and produces science. That generality is not an accident of this document; it is the deliberate abstraction FORGE-002 §3 performed, and Part 13 simply cashes it in.

13.3 The four instruments, mapped

The mapping below is illustrative (and explicitly names systems only as illustration, per the Preamble). In every case, the ontology is unchanged; only adapters and vocabulary-labels differ.

In none of these does the Truth, Publication, Derivation, Presentation, or Search architecture change. What changes: which Source systems the adapters read, and the display labels for object types (a config concern — a “Node” may be presented as “Sequencer” without the ontology renaming its type).

13.4 The seam: adapters and configuration

The Implementation Layer (Part 2.9) is the entire seam. To adopt Forge, a new instrument:

  1. Writes adapters mapping its Systems of Record to ontology facts/events/measures against the Truth ingestion contract.
  2. Supplies configuration: instrument identifier, display labels for object types, its carbon-intensity data source, its identity provider, its aggregation floors (Part 11.3).
  3. Supplies instance assets: name, branding-within-the-design-system (the design system is shared; the wordmark is not), instance-specific Stories and Documents (Knowledge Layer content, authored — not architecture).

That is the whole adoption cost at the architecture level. Everything hard — truth-maintenance, provenance, privacy, search, anti-rot, durability — is inherited.

13.5 When the ontology must change (rarely)

If a new instrument has a genuinely new kind of thing the sixteen objects cannot express, that is an ontology amendment (§3.6 rule 5) — a constitutional act, shared back to Forge, benefiting all implementations. This is expected to be rare (the sixteen are abstract by design) and is the mechanism by which Forge grows without forking: instruments contribute objects upward, not sideways. A telescope’s “observing proposal” might justify such an amendment; the discipline is that it enters the shared ontology or not at all — no instrument gets a private object type, because that would fork the language FORGE-002 §3 exists to keep single.

13.6 Federation (the future the identifier scheme already permits)

Because identifiers are instrument-scoped (forge:<instrument>:..., Part 4.1), multiple Forge implementations can be federated — a national portal projecting across several instruments — with no collision and no redesign, because a cross-instrument view is just another projection over multiple snapshot sets behind the same contracts. The architecture does not build federation now (roadmap, Part 16 — deliberately open), but it refuses to preclude it, which is the most that responsible architecture should do for a future it cannot yet see.

13.7 The verdict

Forge is implementation-independent because its core knows only an abstract ontology, its instrument-specific knowledge is confined to one orthogonal layer, and its contracts are stable across the seam. A second university adopts Forge by writing adapters and configuration — not by changing the architecture. That is the goal the brief set, and the architecture meets it, with the single honest caveat that the sixteen objects must genuinely fit — and Part 13.3 is the argument that they do.

Part 14 — Repository Architecture

This repository is the constitutional home of Forge (the brief): no production code, only the founding documents, architecture, decisions, ontology, contracts, and governance. Every implementation references it rather than embedding these decisions locally. The structure mirrors the layers, so that a reader who understands Part 2 can navigate the repository without a map.

project-forge/
├── README.md               Entry point: what Forge is, how to read the trilogy + FORGE-100, how to adopt.
├── docs/
│   └── forge/              The founding documents (constitutional).
│       ├── FORGE-001.md            Vision.
│       ├── FORGE-002-...md         Principles & Ontology.
│       ├── FORGE-003-...md         Experience Bible.
│       └── FORGE-100-Architecture.md   This document.
├── principles/            The distilled, citable principles (extracted from FORGE-002 Part 2)
│                          as individual files, so "this violates Principle 3" links to a canonical page.
├── ontology/              The machine-readable language (Ontology Layer, Part 2.1):
│   ├── objects/               The sixteen object type definitions + facets + classifications.
│   ├── events/                Event kinds and their common shape.
│   ├── measures/              Measure types, units, methods.
│   ├── relations/             The relation types and their legal object-type endpoints.
│   └── VERSION                The ontology version; amendments bump it (§3.6 rule 5).
├── architecture/          Architecture beyond FORGE-100: layer specs, dataflow diagrams,
│                          the truth-maintenance model, the projection model, threat/privacy models.
├── contracts/             The stable public contracts of Part 10, one per boundary
│                          (object, relationship, measure, event, search, documentation,
│                          receipt, view, identity, snapshot), each versioned.
├── adr/                   Architectural Decision Records (Part 15). Append-only; superseded
│                          ADRs are marked superseded, never deleted (mirrors Part 4.4).
├── governance/            How Forge is amended: the amendment process, the design-review
│                          checklist (FORGE-003 Part 10), the review-record convention,
│                          ownership of truth-types, and the "who may say no" answer
│                          (FORGE-001 §23 Q7 — subtraction needs an owner).
├── roadmap/               The engineering roadmap (Part 16) and its living status.
├── templates/             Templates for ADRs, ontology amendments, contract versions,
│                          adapter specifications, and Story/Document authoring — so that
│                          implementations produce artifacts in the constitutional shape.
├── assets/                The shared design system's non-instrument assets: the visual grammar,
│                          type scale, colour semantics, motion discipline (FORGE-002 Part 7).
│                          Instrument wordmarks live in each implementation, not here.
└── governance/DECISIONS-OPEN.md   The deliberately-open decisions (Part 16.3), tracked so that
                                    "open" never silently becomes "forgotten."

Why every directory exists (the one-line justifications, so the structure itself obeys “subtract, don’t accumulate”):

The rule for this repository mirrors the platform’s own: objects (here: ontology, contracts, ADRs, principles) are permanent and expensive; views (here: roadmaps, status, narrative docs) are cheap and revisable. Amendments to the first kind are constitutional; edits to the second are routine.

Part 15 — Architectural Decision Records

ADRs record why, append-only (Part 4.4 discipline applied to decisions). Each is stated as: decision, and the principle/part it enforces. Superseded ADRs are marked, never deleted — a maintainer must be able to see not just what was decided but what was reconsidered.

ADR-001 — Canonical Objects & Permanent Identity. Every real thing is one object with one opaque, instrument-scoped, permanent identifier and permanent URL; objects end but never vanish; identifiers never encode mutable state. Enforces Principle 2, §3.6 rule 1; Part 4.1–4.3.

ADR-002 — The Triad as Schema. The data model is Objects, Events, Measures — not tables, not documents. Everything is one of the three; confusing them is forbidden. Enforces §3.1; Parts 4, 8, 9.

ADR-003 — Single Source of Truth & the Observed/Derived Split. Every fact is stored once (observed) or computed on demand (derived); derivable values MUST NOT be stored; TTL caches of facts are forbidden. Enforces Principle 2, §3.6 rule 2; Part 3, Part 12.4.

ADR-004 — Truth Ownership & Systems of Record. Sources are authoritative for their domain; Forge is authoritative for the published account; ownership is assigned per object-type and per facet; Forge never invents facts a source owns. Enforces §3.6 rule 2; Part 3.2, Part 4.6.

ADR-005 — Public vs Private Facets, One Structure. Facets are classified at ontology-definition time; privacy is enforced by occlusion from one projection, never by a parallel structure; fail-closed; the public path needs no authentication. Enforces Principle 8, Principle 10, §3.6 rule 4; Part 11.

ADR-006 — Views Are Projections, Not Objects. All pages, reports, queues, dashboards, homepages are pure deterministic projections owning no truth; freely created and deleted; citations point at objects and moments, never views. Enforces §3.3; Part 5.

ADR-007 — Static Publication as the Default Substrate. The default execution model is build-time projection, static delivery; non-static components are exceptions that must justify themselves and must degrade to the static record. Enforces FORGE-001 Principle 8; Part 12.

ADR-008 — Provenance & Freshness Stamping. Every fact carries source, method, measured-at, ingested-at; nothing ships without age; “live” means “as of the last snapshot,” always shown. Enforces Principle 3; Part 3.6.

ADR-009 — Immutable Snapshots & Time-Addressing. Truth is frozen into append-only, content-addressed, self-describing, self-timed snapshots; prior snapshots are never destroyed; any object-at-a-moment is citable forever. Enforces §3.6 rule 1, FORGE-001 §”Time”; Part 3.5, Part 4.8.

ADR-010 — Search as a Derived, Contract-Bound Projection. Search indexes ontology citizens, returns typed answers behind a stable contract, is engine-independent, and ranks by stated method. Enforces Principle 7, Part 5 of FORGE-002; Part 6.

ADR-011 — Knowledge Binds to Objects; Facts Transclude. Documents declare about bindings and transclude changeable facts by reference; typed changeable facts and unresolved transclusions are build failures. Enforces Principles 6, 9; Part 7.

ADR-012 — Identity as an Orthogonal Projection Filter. Authentication is delegated; authorisation maps readers to facets at the projection boundary; the public projection is the null-identity case; fail-closed. Enforces Principle 8; Part 2.8, Part 11.

ADR-013 — Implementation Independence via Adapters. All instrument-specific knowledge is confined to the Implementation Layer; the core speaks only the abstract ontology; adoption changes only adapters/config, save constitutional ontology amendments. Enforces Principle 20; Part 13.

ADR-014 — Degraded State Is a Designed Contract. Every living surface has a specified behaviour when its pipeline breaks or the machine is down; live surfaces vanish or show staleness rather than serving yesterday as today; the Record steps forward. Enforces Principles 11, 12; Part 9.6, Part 12.3.

ADR-015 — Contracts Are Versioned and Additive-by-Default. Layer boundaries expose versioned contracts; breaking changes require a new version with a deprecation window recorded in the Record; consumers depend on contract versions, never implementations. Enforces Part 10; the basis of Parts 6.5, 12.3, 13.

ADR-016 — Ontology Amendment, Not Accretion. New object types require amending the shared ontology (constitutional); new facets require a smaller amendment; new views require nothing; no instrument gets a private object type. Enforces §3.6 rule 5; Part 13.5.

ADR-017 — Aggregation Is Privacy-Bearing. Aggregate projections enforce a minimum group size, resist differencing, and default to group-level grain; finer grains are private or aggregate-only. Enforces Principle 8, §1.2; Part 11.3. (Listed last because it is the ADR most often forgotten, and therefore the one most worth numbering.)

The initial ADR set is deliberately seventeen and small, mirroring the ontology’s deliberate shortness (§3.2). Each ADR is a promise of upkeep (Principle 11); adding one is a considered act, not a reflex.

Part 16 — Roadmap

The roadmap sequences architecture, not features (features are views, and views are free — Part 5). It answers three questions: what to design first, what must never be postponed, and what to deliberately leave open.

16.1 What to design first (the foundation, in order)

The ordering follows the dependency rule (Part 2): design bottom-up, because higher layers are meaningless without the lower ones, and because the lower layers are the expensive, permanent ones.

  1. The Ontology, machine-readable — the sixteen objects, their facets and classifications, events, measures, relations, and the amendment process. Everything depends on this; it must be first, and it must be versioned from day one.
  2. Identity resolution & the Truth model — permanent identifiers, the identity map, provenance/time stamping, the observed/derived split, append-only history. This is the hardest and least glamorous work (Part 4.2) and it is second precisely so it is not skipped under deadline.
  3. Provenance & freshness — the stamp every fact carries. Second-and-a-half, inseparable from the Truth model: a truth store without provenance is a lie waiting to happen (Principle 3).
  4. Snapshots & the Publication contract — immutability, content-addressing, time-addressing, self-description. This is what makes durability and time real, and it constrains everything above, so it is designed before any view exists.
  5. The core contracts (Part 10) — object, relationship, measure, event, snapshot first; these are the seam the rest is built against.
  6. Privacy: facet classification & the Identity contract — designed with the ontology (facets are classified at definition), enforced at the projection boundary. Not later; privacy retrofitted is privacy failed (Part 11.5).
  7. The projection model — how views/search/analytics/knowledge are derived, deterministically, incrementally. Once this exists, invention (views) becomes free and safe.

Only after 1–7 does presentation, the design system, and the first implementation’s adapters begin. FORGE-002 §22 already ordered the product phases (Foundation → Presence → Memory → Knowledge → Narrative → Foresight); Part 16.1 orders the architecture beneath the first of those, and insists the architecture precede the product.

16.2 What must never be postponed

These are the decisions that are cheap now and catastrophic to change later, because everything else calcifies around them:

The through-line: everything that is permanent (identity, provenance, privacy classification, immutable history, contract versioning) must be correct in the first implementation, because these are the properties a second university inherits and a citation from 2027 depends on. FORGE-001 §23’s open questions Q1–Q5 are exactly these, and they are answered here as must-not-postpone, not nice-to-have.

16.3 What to deliberately leave open

Responsible architecture also names what it refuses to decide prematurely, so that “open” is a decision, not a drift (Part 14’s DECISIONS-OPEN.md):

Leaving these open is not indecision; it is refusing to spend the future’s option value on the present’s convenience. The decisions that are permanent are made now (16.2); the decisions that are replaceable are held open on purpose (16.3). Distinguishing the two is most of what architecture is.

Final Review — The Architecture’s Honest Account of the Vision

The brief asks for intellectual honesty, and instructs that the architecture protect the future, not the vision. Here is that account. It is organised as the brief requested: strongest ideas, weakest ideas, hidden assumptions, and the four classes of risk — with improvements where I have them.

The strongest ideas (which the architecture is built to amplify)

The weakest ideas (which the architecture constrains, bends, or honestly downgrades)

Hidden assumptions (that the architecture surfaces so they can be checked)

Architectural risks

Maintenance risks

Scaling risks

Human risks

Closing judgment

The Forge vision is constructable. The architecture in Parts 1–16 realises the trilogy’s hardest promises — truth once, nothing rots, built to be abandoned gracefully — not as aspirations but as structural properties of a unidirectional dataflow. The strongest ideas (the triad, projections, provenance, the receipt, publish-don’t-operate) are load-bearing and sound. The weaknesses are real but bounded, and every one of them has been named rather than hidden.

Three honest caveats remain, and they are not architectural:

  1. The largest risk is editorial staffing, not engineering. The architecture can make un-tended surfaces fail loudly; it cannot write the prose. Fund the writing or shrink the promises.
  2. The sharpest unsolved edge is aggregation-driven re-identification. The architecture makes it hard; adversarial review must keep it hard, forever.
  3. The most urgent unfinished work is FORGE-004 on AI assistance. Write it before someone demos a chatbot.

The architecture is designed to serve the unwatched hours (FORGE-003 §7): the Tuesday in November, the researcher at 01:40, the maintainer in year five, the second university that adopts Forge by writing adapters and inherits everything hard for free. It protects the future by making truth cheap to keep and lies expensive to tell — and by refusing, at every layer, to store a second copy of anything, including a second copy of the truth about its own limitations.

— End of FORGE-100. The architecture’s authority ends where the evidence begins; the first implementation is the first evidence.