Two graphs, and a build chain that orders itself #36

2026-09-12T21:09:36Z

jschoubben commented

2026-09-12 21:09:36 +00:00

Corrects ADR 0070, written an hour earlier, which had the control plane consuming the catalogue in order to compose a declaration. That was written before the two graphs had been told apart, and it creates a dependency that need not exist — a catalogue that is down would leave the control plane unable to compose the thing that would repair it.

The catalogue links module-versions to each other and does not know nodes exist. The control plane links module-versions to nodes, and holds capabilities and claims. They meet only when something is installed.

Everything between them travels as events over the broker, on durable queues declared by the mesh, so nothing is lost when a receiver is away. The builder announces what it built; the catalogue registers it and announces an upgrade; the control plane reacts to that rather than to build output.

Build order is not computed anywhere. The builder never consults the graph and builds what it is asked for, one at a time. The catalogue asks for the next build only after the previous registration, so "do not start this until that is registered" holds by construction rather than by levels somebody maintains. Its rule is a condition rather than a schedule — rebuild once everything a module was built against is current — which covers a chain and a diamond with one rule. It must refuse a cycle, and must not announce an upgrade for a rebuild whose artifacts are identical.

Left open: whether an upgrade is applied or merely noticed (today's system deploys automatically; this design notices and waits, and the difference should be a setting with a chosen default), and whether a module on several machines upgrades on all of them at once.

Corrects ADR 0070, written an hour earlier, which had the control plane consuming the catalogue in order to compose a declaration. That was written before the two graphs had been told apart, and it creates a dependency that need not exist — a catalogue that is down would leave the control plane unable to compose the thing that would repair it. The catalogue links module-versions to each other and does not know nodes exist. The control plane links module-versions to nodes, and holds capabilities and claims. They meet only when something is installed. Everything between them travels as events over the broker, on durable queues declared by the mesh, so nothing is lost when a receiver is away. The builder announces what it built; the catalogue registers it and announces an upgrade; the control plane reacts to that rather than to build output. Build order is not computed anywhere. The builder never consults the graph and builds what it is asked for, one at a time. The catalogue asks for the next build only after the previous registration, so "do not start this until that is registered" holds by construction rather than by levels somebody maintains. Its rule is a condition rather than a schedule — rebuild once everything a module was built against is current — which covers a chain and a diamond with one rule. It must refuse a cycle, and must not announce an upgrade for a rebuild whose artifacts are identical. **Left open:** whether an upgrade is applied or merely noticed (today's system deploys automatically; this design notices and waits, and the difference should be a setting with a chosen default), and whether a module on several machines upgrades on all of them at once.

jschoubben added 1 commit 2026-09-12 21:09:36 +00:00

Two graphs, and a build chain that orders itself 58ad0742d8

Corrects ADR 0070, written an hour earlier, which had the control plane consuming
the catalogue in order to compose a declaration. That was written before the two
graphs had been told apart and creates a dependency that need not exist: a
catalogue that is down would leave the control plane unable to compose the thing
that would repair it.

The catalogue links module-versions to each other and does not know nodes exist.
The control plane links module-versions to nodes, and holds capabilities and
claims. They meet only when something is installed, and everything between them
travels as events over the broker, on durable queues, so nothing is lost when a
receiver is away.

Build order is not computed anywhere. The builder never consults the graph and
builds what it is asked for; the catalogue asks for the next build after the
previous registration, so ordering holds by construction. Its rule is a condition
rather than a schedule — rebuild once everything a module was built against is
current — which covers a chain and a diamond alike.

Left open: whether an upgrade is applied or merely noticed, and whether a module
on several machines upgrades on all at once.

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

jschoubben merged commit a4866ca899 into main

2026-09-12 21:09:43 +00:00

jschoubben deleted branch feat/two-graphs-and-the-build-chain

2026-09-12 21:09:43 +00:00

jschoubben referenced this pull request

2026-09-21 11:50:02 +00:00

Issues 031, 035 and 054 name their merges, the branch being gone #61

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#36