02-DECISIONS/0073-the-installer-carries-a-builder.md

@@ -7,7 +7,7 @@ reconstructed: false
 extends: 0070-the-catalogue-owns-the-module-graph.md
 ---
 
-# 73. The installer carries a builder, and the registry precedes the control plane
+# 73. The installer carries a builder, and the registry stays where it is
 
 ## Context
 
@@ -17,11 +17,8 @@ questions were left open, and the design record names them as the one gap that s
 from being able to produce anything at all: **how the builder arrives**, and **what it publishes
 into**.
 
-They cannot be answered apart. A builder that arrives with nowhere to publish has produced a file
-on a disk, and a place to publish with nothing to produce is an empty shelf.
-
 Today the installer carries the control plane's image inside itself. That works, and it is why
-genesis needs no registry: nothing is ever pulled, because the one image that matters is already
+genesis needs no registry: nothing is ever fetched, because the one image that matters is already
 present. The cost is that the mesh which results holds an artifact it did not make, cannot rebuild,
 and knows nothing about — no version, no source, no edges. That is the same shape as the fault
 [issue 044](../04-ISSUES/044-the-runtime-every-module-builds-on-cannot-be-built-by-the-mesh/00-report.md)
@@ -36,31 +33,36 @@ and produces the control plane from the same repository and path that any later
 use. What raises the mesh is therefore the same thing that will maintain it, and there is no second
 mechanism kept in step with the first.
 
-**The registry joins the substrate, and precedes the control plane.** Not because it became more
-fundamental, but because the answer to a stated question changed:
+**The registry does not move, and the argument for moving it does not survive being made.**
+
+It was put this way: a produced image has to be put somewhere before anything can fetch it, so the
+registry must now precede the control plane, and
+[ADR 0033](0033-the-substrate-is-a-store-and-a-broker.md)'s answer to that question has to flip.
+
+It does not, because the premise is false. **The thing that builds the image and the machine that
+runs it are the same machine.** A built image is already in that machine's container runtime, and
+the temporary control plane names it exactly as it names a carried one — by the digest of its own
+configuration, a local identity that requires nothing to have served it. Building changes where the
+bytes came from. It does not change where they are.
 
 | | is it substrate? | must it precede the control plane? |
 |---|---|---|
 | the store | yes | yes — there is nowhere else to put the control plane's state |
 | the broker | yes | yes — the control plane reaches a machine only over it |
-| the image registry | yes — it cannot grant itself a repository | **yes, now** — the control plane's image is produced here, and a produced image has to be put somewhere before anything can fetch it |
+| the image registry | yes — it cannot grant itself a repository | **still no** — the first machine neither fetches the control plane nor needs to, whether the image was carried in or made here |
 
-[ADR 0033](0033-the-substrate-is-a-store-and-a-broker.md) answered that last cell *no*, and was
-right at the time, for the reason it gave: the first machine fetched the control plane from
-upstream, so nothing needed a registry until there was already a control plane to install one. That
-premise is what this decision removes. The registry's role never changed; what changed is whether
-anything needs it before the control plane exists.
-
-**The substrate bundle therefore carries three services and no control plane**, where it carried
-two services and a control plane. It does not grow: an image comes out as one goes in.
+So the registry stays where [ADR 0033](0033-the-substrate-is-a-store-and-a-broker.md) put it:
+substrate by role, ordinary by delivery, installed by the temporary control plane as its first act.
+The bundle carries two services and a control plane, as it did. **What publishes into the registry
+is unchanged too** — the existing step that pushes the control plane's image into it, which is the
+moment that image first receives a digest assigned by something other than itself. It now pushes
+something this mesh built rather than something it was handed.
 
 ## Consequences
 
-**Genesis gains a step and loses one.** The registry is raised with the substrate rather than
-installed as the first act of a temporary control plane, and a build step appears before the
-control plane is raised at all. The pivot described in
-[ADR 0067](0067-genesis-is-a-pivot.md) survives unchanged in shape — a temporary control plane is
-still what installs the permanent one — but what it installs is now something this mesh built.
+**Genesis gains one step and changes no others.** A build happens before the image is loaded. The
+pivot described in [ADR 0067](0067-genesis-is-a-pivot.md) survives exactly as written, because the
+step it pivots on never cared where the image came from.
 
 **A fresh mesh can produce from the moment it exists.** The builder is present before the control
 plane is, so the core modules, the catalogue and the builder's own module can be built in the

02-DECISIONS/README.md

@@ -105,7 +105,7 @@ python3 00-META/checks/index.py            fail if stale
 - **0070** — [The catalogue owns the module graph, and genesis builds rather than carries](0070-the-catalogue-owns-the-module-graph.md)
 - **0071** — [Genesis clones from a mesh, and checks what it got](0071-where-genesis-gets-its-source.md)
 - **0072** — [Two graphs, and a build chain that orders itself](0072-two-graphs-and-the-build-chain.md)
-- **0073** — [The installer carries a builder, and the registry precedes the control plane](0073-the-installer-carries-a-builder.md)
+- **0073** — [The installer carries a builder, and the registry stays where it is](0073-the-installer-carries-a-builder.md)
 
 ### What runs on them, and how it gets there