jschoubben 918dc04916 What this actually is, and three things that were assumed
Four things settled by talking them through, all of which had been true in
somebody's head and written nowhere.

It is not a mesh in the peer-to-peer sense and will not become one. 0001 now
says what it is instead: machines linked by a private network, one node holding
knowledge of all of them, modules as the way anything is built and delivered,
and agents hired onto nodes to do the work. The word describes what machines
can reach, not how they are governed. "Master" overstates it the other way --
nothing needs that node to keep running, only to change.

0006 gains the option that would make it a real mesh, recorded as considered
rather than rejected by silence: every node holding the whole inventory, a
replication process, an elected master with promotion on failure. What settles
it is not the complexity but that it still would not deliver the name, because
application databases are not replicated -- so a genuine peer-to-peer mesh
means becoming a replicated database system for every consumer's data too. That
is a larger product than the thing it would support.

Also in 0006: three central roles, not one. Losing the control plane costs
change, losing the broker costs being told anything, and losing the hub costs
nodes in different places reaching each other at all -- which is operation, not
administration. Whether they are one node is not decided.

And SSH access is identity's. It appeared three times as something that uses
the overlay and never as something the mesh provides, which reads as settled
when nothing decided it. Nobody else could: the mesh is the only thing that
knows which humans and agents exist and which nodes they may reach. Node to
node SSH stays out -- the host has no inbound control surface by decision, and
nodes reaching each other that way is a second control path through the back
door.

0007 gains the requirement underneath all of it. Reachability was recorded as a
fact to track and never as a thing some node must have. The broker's node and
the hub must be dialable by every node at a stable address, or nothing can join
and a disconnected node cannot return. A mesh entirely behind NAT cannot be
raised. That is a precondition and it belongs with the others.

The link staying on the underlay is also argued now rather than asserted. At
join time it is forced; afterwards it is a choice, and the reason is that a
repair channel carried over the thing being repaired is not one. Moving it onto
the overlay, with fallback, is recorded as open with what it would have to get
right -- a WireGuard interface has no link state to test, and a silent fallback
is this repository's recurring fault in a new place.

0010 says in one line what was the intention throughout: the module system is
the CI/CD. Not a pipeline beside the mesh. Build, test, publish and deploy are
one reconciliation seen at four points, which is why a thing that cannot be a
module cannot be delivered.
2026-08-29 13:01:36 +02:00

Novox HQ

The single source of truth for what Novox builds — what it is, what it is becoming, and why. Today that is almost entirely Novox Mesh, the substrate everything else runs on. Implementation lives in modules/; the reasoning behind it lives here.

Structure

Folder Purpose
00-META Mission, foundational context, the rules that hold across the mesh, the repository map, and the process playbooks. The northern star for every decision.
01-RESEARCH Active and historical investigations, before they harden into design.
02-DECISIONS Numbered decision records, in the order the decisions were taken — what was chosen, and what was rejected.
03-DESIGN The authoritative specification, in two layers: 00-as-is — the mesh that exists — and 01-to-be — the one being built toward.
04-ISSUES The front door for "something is wrong" at the level of design or governance.

The numbering is the flow. Research produces a decision; the decision authorises a design. That is why decisions are 02 and design is 03 — a reader following the numbers walks the process in the order it happens.

The flow

idea ──► 01-RESEARCH ──► decision (02-DECISIONS/) ──► 03-DESIGN/01-to-be ──► built (code repo)
 │            │                                      │
 │            │                                      └─► 03-DESIGN/00-as-is once shipped
 │            └────► abandoned (recorded, kept)
 └─(small/obvious, still recorded in 02-DECISIONS)──────────► 03-DESIGN directly

symptom ──► 04-ISSUES ──► diagnosis ──► code-repo fix and/or design amendment

00-META/how-we-build.md ──► sync ──► the constitution the mesh injects into design sessions

Implementation lives in the code repositories — see 00-META/repos.md. Every workflow is a playbook in 00-META/process/; agents operate through them and not outside them.

Rules

  • Markdown only.
  • No new top-level folders without explicit confirmation.
  • Knowledge flows GENESIS → RESEARCH → DESIGN. Research graduates into design only after analysis against GENESIS confirms alignment, and only through a recorded decision.
  • Status lives in frontmatter, never in a central status file. Cross-cutting views are generated on demand, never hand-maintained.
  • GENESIS and DESIGN are instance-agnostic. They describe the mesh as a concept — no machine names, no counts, no topology. A reader must not be able to tell how many nodes the author happened to have.
  • RESEARCH describes real observations, but never identifies the mesh it observed. Evidence is what makes research worth reading, and the shape of a finding survives anonymisation intact — a node publicly named but behind a household NAT carries the whole lesson without naming anything.
  • The as-is layer records what is, not what should be — including behaviour nobody would choose again. A layer that keeps only the good decisions is a brochure.
  • A document that states a rule about the mesh should say how that rule is checked. This repository has a rule requiring every capability-exposing module to declare the core runtime as a dependency; zero modules do. An unenforced rule is indistinguishable from a wrong one.

This repository is public

Written for a reader who is not its author and has no access to the mesh it describes. Concretely, nothing here may contain:

  • routable addresses, real domain names, hosting providers, or node names — use the documentation ranges (RFC 5737 203.0.113.0/24, RFC 1918) and role names such as anchor, home-server, workstation, laptop
  • absolute paths from anyone's machine, usernames, home directories, or email addresses
  • credentials in any form, including lengths or hashes of live secrets
  • operational detail that is only useful to an attacker — which host is the VPN hub, on which port, which node is reachable only through a forwarded port

Private-range addresses and the overlay plan are fine: they describe a pattern, not a target.

The test is whether a paragraph would still teach something to a stranger running an entirely different mesh. If it would, it belongs. If it only makes sense to someone who knows this particular installation, it is either a note in the wrong place or a disclosure.

Why this is its own repository

It began inside the code repository, on the reasoning that the mesh already has a mesh-native knowledge store and that adding a fourth knowledge system would repeat the mistake this folder was created to fix.

That objection was about a fourth knowledge system, and the answer offered was indexing rather than location — that these documents would be indexed into the knowledge base, so a symptom search returns them beside everything else. One source, many surfaces. Where the source is authored is then a separate question.

That indexing does not exist. It was checked on 2026-08-23 and returns nothing; it appears never to have existed. Until it does, the objection stands unanswered and this repository is the fourth knowledge system it was argued not to be. Recorded as 04-ISSUES/006, and left standing here rather than quietly reworded, because a claim that held up a decision and was never checked is precisely the failure this repository exists to name.

Answered separately, a repository of its own is the better home:

  • The cadence is different. A decision changes when thinking changes, not when code changes. Tying documents to a code branch means they merge on the code's schedule.
  • The reviewers are different. A design argument is not reviewed the way an implementation is, and it should not queue behind a build.
  • The scope is wider than one repository. ADR 0001 sends most modules out of the monorepo entirely. Documentation that governs several repositories cannot live inside one of them.

The trade is real and worth naming: a change to a document and the change to the code it describes can no longer land in one commit. Keeping them honest is a discipline now rather than a mechanism — which is why every decision is recorded in 02-DECISIONS as it is taken, and why a document that states a rule should say how the rule is checked.

Recorded as ADR 0019.

S
Description
Novox HQ — mission, research, decisions, design. The reasoning behind what we build.
Readme
4.6 MiB
Languages
Python 100%