The catalogue owns the module graph, and genesis builds rather than carries #34

2026-09-12T20:03:30Z

jschoubben commented

2026-09-12 20:03:30 +00:00

The module graph had no owner — what modules are, what they require, what they claim, what they were built against — and it sat in the control plane because that is where it was written first. The control plane's own test says otherwise: anything a single machine could answer alone is not its work.

So the catalogue becomes a core module beside the control plane and the builder, owning the graph and serving tools over it: install a module, query what is available and what it needs, query the graph, query and update settings. One per mesh, expressed as a claim scoped to the mesh — no new mechanism. The control plane consumes it, which is the opposite of what the tiers suggest and is therefore stated.

That makes the catalogue a fourth thing that cannot arrive through the ordinary path, so this also corrects the claim I wrote this morning that the list was closed at three. All four are now answered by one mechanism rather than three special cases: the installer carries an init builder, which clones the source and builds the control plane, catalogue and builder on the machine. What is carried is a builder rather than a result, which is what finally gives the builder and the catalogue a route.

Two things are open and named rather than assumed, both worth settling before this is built:

Where the init builder clones from. ADR 0067 rejected building from source at genesis partly because the source lives in a forge that runs on the mesh, so a total rebuild would need the mesh it is rebuilding. Carrying a builder answers the toolchain half of that objection, not this half.
What it publishes into. Building produces artifacts that must be pinned by a digest a registry assigned, and the registry is installed after the machine joins in today's order. If the core modules are built first, that order has to change.

The raising-a-mesh document is marked rather than rewritten: it still describes what the installer actually does today, because replacing it with the intention would leave nothing describing the program anyone runs.

The module graph had no owner — what modules are, what they require, what they claim, what they were built against — and it sat in the control plane because that is where it was written first. The control plane's own test says otherwise: anything a single machine could answer alone is not its work. So the catalogue becomes a core module beside the control plane and the builder, owning the graph and serving tools over it: install a module, query what is available and what it needs, query the graph, query and update settings. One per mesh, expressed as a claim scoped to the mesh — no new mechanism. The control plane consumes it, which is the opposite of what the tiers suggest and is therefore stated. That makes the catalogue a fourth thing that cannot arrive through the ordinary path, so this also corrects the claim I wrote this morning that the list was closed at three. All four are now answered by one mechanism rather than three special cases: the installer carries an **init builder**, which clones the source and builds the control plane, catalogue and builder on the machine. What is carried is a builder rather than a result, which is what finally gives the builder and the catalogue a route. **Two things are open and named rather than assumed**, both worth settling before this is built: - Where the init builder clones from. ADR 0067 rejected building from source at genesis partly because the source lives in a forge that runs on the mesh, so a total rebuild would need the mesh it is rebuilding. Carrying a builder answers the toolchain half of that objection, not this half. - What it publishes into. Building produces artifacts that must be pinned by a digest a registry assigned, and the registry is installed *after* the machine joins in today's order. If the core modules are built first, that order has to change. The raising-a-mesh document is marked rather than rewritten: it still describes what the installer actually does today, because replacing it with the intention would leave nothing describing the program anyone runs.

jschoubben added 1 commit 2026-09-12 20:03:30 +00:00

The catalogue owns the module graph, and genesis builds rather than carries 64ae75a480

The graph had no owner: what modules are, what they require, what they claim and
what they are built against all sat in the control plane because that is where it
was written first. The control plane's own test says otherwise — anything a single
machine could answer alone is not its work, and what a module needs requires no
knowledge of any node.

So the catalogue becomes a core module beside the control plane and the builder,
owning the graph and serving tools over it. The control plane consumes it, which
is the opposite of what the tiers suggest and is therefore stated rather than
inferred.

That makes the catalogue a fourth thing that cannot arrive through the ordinary
path, so the claim written this morning that the list was closed at three is
corrected. All four are answered by one mechanism instead: the installer carries
an init builder and the core modules are built on the machine, so what is carried
is a builder rather than a result and nothing is left without a route.

Two things are open and named rather than assumed: where the init builder clones
from, given the forge normally runs on the mesh it would be rebuilding, and what
it publishes into, given the registry is installed later in the order today.

Claude-Session: https://claude.ai/code/session_01D6qtiYU3P9jk3pnAXyAFyx

jschoubben merged commit 03c73e7698 into main

2026-09-12 20:09:39 +00:00

jschoubben deleted branch feat/the-catalogue-owns-the-module-graph

2026-09-12 20:09:39 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#34