jschoubben
77f3a4cea7
Every remaining cluster merged. Each was one design that had been split across
several records because it was worked out over days rather than at once.
the node host 8 -> 1 applies not decides, depends on nothing,
per operating system, root service, the
launcher, episodic, what a declaration is,
actions from the bundle only
a node and how it joins 4 -> 1 what a node is, joining, the link as
security boundary, the enrolment token
modules and the graph 7 -> 1 everything is a module, no domain modules,
three edges, provisioning, the core library
substrate and control 6 -> 1 the test, seven contexts, one control plane,
plane the authority is not a database, the named
products, the pinned bundle
connectivity 3 -> 1 a route is a grant, reachability declared,
filter rules
delivery 5 -> 1 reconciliation not a pipeline, artifacts,
the three silos, a failed step, the verdict
the lab 5 -> 1 (earlier)
how this repository 10 -> 1 (earlier)
works
Nothing was dropped. Each consolidated record carries the reasoning of the ones
it absorbs -- the measurements, the incidents, the alternatives rejected --
because that reasoning is the only reason to keep a record at all. What is gone
is the fragmentation: eight files to read to understand tier 0, when tier 0 is
one component.
The four superseded records went too. They existed to point at their
successors, and the successors now contain what they said.
The checker made this safe. Each merge left dangling links -- 38 files after
the host merge alone -- and it named every one. Nothing was found by reading,
and a manual pass would certainly have missed some, including references inside
AGENTS.md which every session loads.
3.1 KiB
3.1 KiB
status, initiated, touches, became
| status | initiated | touches | became | |||
|---|---|---|---|---|---|---|
| active | 2026-08-23 |
|
007 — Provisioning as the mesh's core mechanism
What is being investigated
Provisioning is the mechanism the whole mesh rests on: a module declares what it needs, and the mesh makes it exist, generates the credential, records the grant, and puts the values where the module will read them. ADR 0044 calls it the mesh's core concern rather than its plumbing.
Research 006 then asks it to carry more: the control plane becomes a consumer with its own requirements — a source of record, an image registry, a package registry — satisfied by the same mechanism. That generalisation is only safe if the mechanism is sound, and the as-is record says it is not, in named ways.
Why now
Four weaknesses are already documented in
03-DESIGN/00-as-is/03-provisioning.md, each
observed rather than theorised:
- Rotation has no fan-out. A shared credential can be rotated without telling the peers holding the old one. This has locked the mesh out of its own broker.
- A grant is not a check. The record says a resource was provisioned. Nothing verifies it still exists, still has that credential, or is reachable from where the consumer runs.
- A frozen password outlives its generation. A generated secret written once diverges from a persistent data directory initialised earlier, and presents as an authentication error.
- No requirements is indistinguishable from provisioning that did not run. A module that declares nothing skips the stage, which is correct, and looks identical to failure.
Generalising a mechanism with these properties to the control plane's own dependencies would make each of them fatal rather than annoying.
The questions
| Question | Why it matters |
|---|---|
| What does a grant mean, exactly — a record that a resource was created, or a claim about the world that is continuously reconciled? | The difference between the current model and one where "provisioned" is checkable. Almost every weakness above is a symptom of the first answer. |
| How is a credential rotated with fan-out to every holder? | The mechanism grants easily and regrants not at all. This is the most damaging gap and it has taken the mesh down. |
| Can the control plane hold requirements, and what satisfies them before anything is installed? | The generalisation research 006 needs. Ties directly to the self-hosting transition. |
| What happens when a requirement cannot be satisfied — no provider, provider on an unreachable node, provider not yet installed? | Today this is silent or a stall. It should be a stated, visible state. |
| Does a requirement belong to a module or to one of its parts? | Research 006 splits feature into artifact and part. A part-scoped requirement means a database is not provisioned where the part that needs it is not installed. |