jochen
4a1b218706
Decided with the author: - A seat is held by one assignment, not claimed by a definition. A definition says which seats a module can hold; an assignment says which it does. The store module can run on every node and one assignment holds mesh-store; moving a role changes an assignment, never a definition. The foundation's seats name what the mesh itself uses and route no consumer — database and amqp consumers use co-location, the holder included. This replaces the wrong rationale that the foundation's store is "provider to nobody", which contradicted ADR 0078 and to-be 21. 0079's one-postgres rule becomes one mesh-store holder. - A module is assigned at most once to a node. The instance identity in 0112 and 27 is withdrawn, and the login-length problem with it. Review fixes to 0113: - The bottom of the stack: the vault is installed as soon as the shared runtime base exists, and genesis generates everything needed until then — including the permanent controller's, the control-node agent's, the builder's and the broker provisioner's bus accounts, and the controller's store login. Genesis creates those accounts until the broker's provisioner runs and adopts them. - Genesis's values are delivered recorded as the mesh's own, so 0092's never-replace rule for operator values does not make them unrotatable. - Backend-issued secrets (a forge's once-only API token) enter through the vault. Non-module parties (the controller's logins, node agents' accounts) are answered the same way, the controller asking on their behalf; an enrolment token reaches the controller only as what verifies it. - A secret with no provisioner to apply it is marked not rotatable by the mesh and refused, instead of a restart reported as done. Unused password generators in six provider clients are removed, and a catalogue scan checks no module mints. - Rotation's lock-out cases (offline reader, bus account owner, restarted provisioner) are recorded as open, with overlap and re-confirm-with-safeguards as the two answers, to be chosen before acceptance. 0110, 0111 and 26 are marked proposed: they changed in meaning and are under review, and an accepted record must not rest on proposed ones. To-be 23 and the glossary are restored to main; they change when these records are accepted.
00-META
The northern star. What the mesh is, the environment it runs in, and what changes when it works — plus the engineering practice that holds across everything Novox builds. Every research effort and design decision is checked against this folder.
| File / folder | Purpose |
|---|---|
mission.md |
Vision, mission, and the values that decide arguments |
context.md |
The environment — conditions, not aspirations |
effect.md |
What is different when the work is done |
how-we-build.md |
The rules that hold across the mesh, each one earned. The source of the mesh constitution — the governed page the mesh injects into design sessions is derived from it. |
glossary.md |
One name per thing — the authority on vocabulary, and the words that were retired |
repos.md |
Where implementation lives, and what each repository owns |
process/ |
The playbooks — how work moves through this repository, for engineers and agents alike |
Rules
- Markdown only.
- Stable by nature. Changes here reflect a genuine shift in intent, not iteration. The one
exception is
how-we-build.md, which changes whenever a rule is earned — and only through its amendment process. - Research and design must be traceable back to what is written here.
- Instance-agnostic. These documents describe the mesh as a concept. No machine names, no counts, no topology.
On the architecture overview in the code repository
The code repository carries an architecture overview predating this folder. It is a useful
description of how the mesh works, and its content now lives — anonymised and checked against
the implementation — in 03-DESIGN/00-as-is/. GENESIS answers why;
that document answered how, which is the design layer's job.
It had also drifted from the implementation in ways worth recording, since both were found by comparing it against the code rather than by anyone noticing:
- It described the pipeline as having a separate builder process and a build stage that packages. Neither was true after 2026-08-04; the documents stayed stale until 2026-08-06 (ADR 0010).
- It listed the mesh as spanning a fixed number of named machines, which is exactly the content this repository cannot carry.
It also lists "symlinks, not copies" as a key design principle, and that is a genuine contradiction rather than a stale detail. The mesh's stated intent is that it creates no symlinks at all — the rule is not merely "only the installer may link", and a founding document elevating linking to a principle points the opposite way from where this is going.
What exists today is that the installer owns and reconciles every link
(ADR 0012) — an as-is fact, recorded in
03-DESIGN/00-as-is/05-runtime-and-installation.md.
Centralising who may link narrowed the incident class; it did not close it. The intent is to
remove the mechanism, recorded as ADR 0012.
A founding document contradicting the direction of travel is precisely the failure this folder exists to prevent.