Files
hq/03-DESIGN/01-to-be/README.md
T
jschoubben 333356cff3 Order the records the way the system is learned
Jochen asked whether the order made sense. It did not -- it followed when
things happened to be decided, which after consolidation is fictional anyway
since record 5 alone folds decisions taken across a week.

Concretely wrong before: the domain statement sat at 8, after five engineering
rules; the constitution was scattered across 5, 12 and 17; the tiers landed at
15, 16, 21 and 22 with process records in between.

Now it walks: what the mesh is (1-3), its tiers from the bottom up (4-8), what
runs on them and how it gets there (9-10), how it is built (11-16), how it is
checked (17-18), how we work (19-23).

Two things made this safe rather than free. It is a permutation, not a
compaction, so the renames go through temporary names -- otherwise two files
want one slot and one is lost. And the reference rewrite is a single
simultaneous pass, because almost every number moved into a slot another number
was vacating; replacing one at a time would have cascaded and pointed things at
the wrong record while still resolving.

Verified: 284 [ADR NNNN](path) links across the repository, all with matching
text and target.

The ordering principle is now stated in 19 rather than left implicit -- the
repository already said "the numbering is the flow" about its folders, and
there was no reason for the records to be the exception.
2026-08-28 23:30:42 +02:00

3.5 KiB

03-DESIGN / 01-to-be

The mesh being built toward. Every statement here traces to a record in 02-DECISIONS/; nothing arrives by drafting.

A document here describes an intention. What currently runs is in 00-as-is/, and the two are never merged — when something ships, the as-is document is written and this one's status becomes implemented.

Document Covers Rests on
00-work-breakdown.md How the decomposition gets built, in what order, and where a human must look ADR 0001
01-end-to-end-testing.md The lab: a real mesh a change can be run against before it reaches nodes ADR 0016, 0029
02-scenario-declaration.md What a scenario declares — the underlay, and what to place on it ADR 0016
03-scenario-lifecycle.md What happens to a scenario — raise, snapshot, restore, move, destroy ADR 0016
04-lab-installation.md Getting the lab onto a clean machine, and why it verifies capability rather than installation ADR 0010
05-the-node-host.md Tier 0 — the one thing installed by hand, and the only thing that changes a machine ADR 0005
06-the-control-plane.md Tier 2 — what the term means, and the test for what belongs in it ADR 0005
07-the-substrate.md Tier 1 — what the control plane consumes and cannot grant itself ADR 0004, 0048
08-connectivity.md One context in full — overlay, resolution, exposure, filtering, certificates ADR 0007, 0050, 0051, 0055
09-the-node-lifecycle.md How a machine becomes a node, stays one, and stops being one ADR 0004, 0051
10-delivery.md Modules, the three edges, and how a change becomes a running thing ADR 0010, 0064, 0065

Not yet written

  • The remaining six contexts. ADR 0006 settles the list at seven; connectivity is the first written in full (08) and the other six do not exist yet. The work breakdown says in what order they are needed.
  • Domain grouping outside the core. Not needed. ADR 0009 is superseded by ADR 0009: there is no domain module to group into, so there is no domain list to settle. Relationships are edges, and grouping is a tag and a query.