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.
88 lines
4.7 KiB
Markdown
88 lines
4.7 KiB
Markdown
---
|
|
status: graduated
|
|
initiated: 2026-08-23
|
|
touches:
|
|
- 02-DECISIONS/0044-modules-and-the-graph.md
|
|
- 03-DESIGN/00-as-is/10-module-catalogue.md
|
|
- 03-DESIGN/00-as-is/02-modules-and-manifests.md
|
|
became:
|
|
- 02-DECISIONS/0044-modules-and-the-graph.md
|
|
- 02-DECISIONS/0044-modules-and-the-graph.md
|
|
---
|
|
|
|
# 005 — Which domains the catalogue groups into
|
|
|
|
[ADR 0044](../../02-DECISIONS/0044-modules-and-the-graph.md) settles
|
|
that modules outside the platform core are grouped by domain rather than by single function,
|
|
and deliberately does not settle the list. This effort settles the list — and, first, tests
|
|
whether the premise survives measurement.
|
|
|
|
## What is being investigated
|
|
|
|
Eighty-nine modules sit outside the platform core. The question is which of them belong
|
|
together, and the method is evidence rather than intuition: **which modules actually change
|
|
together**, measured across the full history of the code repository.
|
|
|
|
## Why
|
|
|
|
The argument in ADR 0017 is that the catalogue's shape records what was installed rather than
|
|
what anything is for — that four modules constituting "how a node is reachable" have no
|
|
relationship the mesh can see, so a change to connectivity is made four times.
|
|
|
|
That argument is testable. If those modules genuinely change together, the grouping is
|
|
justified by more than tidiness. If they do not, the premise needs revising before a list is
|
|
drawn from it.
|
|
|
|
## What it touches
|
|
|
|
The catalogue's shape, the manifest, and — for one candidate grouping — the provisioning
|
|
reference itself, since a requirement names a provider **module**. Grouping providers would
|
|
change what a consumer names.
|
|
|
|
## Status
|
|
|
|
Measurement is done and is in [`analysis.md`](analysis.md). It **partly contradicts the
|
|
premise**, in a way that narrows the effort usefully:
|
|
|
|
- Non-platform modules overwhelmingly change **alone** — 10% of commits touch more than one,
|
|
and 50 of 89 never co-change with anything.
|
|
- Two clusters do exist. One of them, reachability, holds up as a domain.
|
|
- The other, the provisioned infrastructure providers, co-changes for a reason that argues
|
|
**against** grouping rather than for it.
|
|
|
|
The remaining work is the list itself, for the modules where grouping is justified, plus the
|
|
open questions below.
|
|
|
|
## What it became
|
|
|
|
*Closed 2026-08-28.* Three of the four questions are answered, and by records that did not cite
|
|
this effort — which is why it stayed open after being resolved.
|
|
|
|
**Whether provider modules group at all** — *no.*
|
|
[ADR 0044](../../02-DECISIONS/0044-modules-and-the-graph.md):
|
|
there is no `networking` thing to install, there are concrete modules named individually. Folders
|
|
assert relationships; edges record them. *Provider* stops being a category at the same time.
|
|
|
|
**Whether "group or leave" is even the right pair of options** — *it was not*, and that is the
|
|
useful finding. [ADR 0044](../../02-DECISIONS/0044-modules-and-the-graph.md)
|
|
reframes it: things that change together share an **authority**, not a package. This effort's own
|
|
measurement is what that record rests on — reachability being the *only* place modules genuinely
|
|
co-change is why connectivity is a context and why nothing else needed one.
|
|
|
|
**What to do with the ~50 modules that co-change with nothing** — *nothing.* They are modules.
|
|
Grouping is a tag and a query over the graph, neither of which anybody keeps true by hand.
|
|
|
|
**What remains is a sequencing question, not a grouping one**, and it moves rather than closes:
|
|
*whether applications leave the monorepo before or after they group* is
|
|
[research 009](../009-migration/00-overview.md)'s, because it is about how to get from here to
|
|
there rather than about what the shape is.
|
|
|
|
## Open (superseded by the above) questions
|
|
|
|
| Question | Why it is open |
|
|
|---|---|
|
|
| Whether provider modules group at all, and if so what a consumer's requirement names instead of a module. | The provisioning reference is load-bearing; getting it wrong is expensive. Opinion and evidence in the analysis; not yet decided. |
|
|
| Whether applications group into domains now and leave the monorepo later as a unit, or leave first. | Decided in principle — group first, then split — but the migration order has real cost either way. |
|
|
| What to do with the ~50 modules that co-change with nothing. | The evidence gives no grouping signal for them at all. That may mean they are correctly sized already. |
|
|
| Whether "group or leave" is even the right pair of options. | [Research 006](../006-mesh-from-scratch/code-skeleton.md) finds a third fate — **absorbed into the node host**, ceasing to be a module at all — and argues it is the correct answer for the reachability cluster this effort measured. If so, the cluster this effort found is evidence for absorption rather than for grouping. |
|