How an agentic node changes itself: law editions, adoption and one scheduler
A node that improves itself safely separates three things: the law it runs under (versioned as content-addressed editions that each name their predecessor), the act by which an office adopts an edition, and the release that realizes it; and it declares every recurring trigger inside that release. The 561 Group's design sentence calls the knowledge of each node "recursively self-improving." This article describes the October 2026 decision that turns the phrase into engineering constraints.
What problem was being solved?
The node in question runs a shared work arena whose rules are called its law. It had adopted sixteen editions of that law, and every edition from the second onward required an outage. A session stopped the node, rewrote the board's journal by hand, swapped the segments in and released. Likewise, every recurring program was a systemd unit that someone had linked into a user directory by hand, and several ran twice after the node learned to run jobs itself.
The decision note traces both to one mismatch between theory and practice. The theory says a law is a held judgment (in Huidu terms, 法 fǎ, codified and public, see Huidu Guanli for agent organizations), adopted by an office's act and in force from then on, and that a record told under a law stays what it was told as. What ran did the opposite:
- A stored move named no law. The board replayed every stored move under whatever law the running code held, so a tightened law refused yesterday's moves.
- Adoption was not an act. An edition was in force when its code was released; no office adopted it.
- Triggers lived outside the release. Schedules sat in one place, templates in another, calendar triggers in hand-linked timers.
- Repository writers found the repository by accident. Programs located their repository relative to their own source, and failed when run from a release tree.
What does the decision say?
Law editions are content-addressed data that every move names
An edition is a record naming its arena, its number, its predecessor, a note and what it says, addressed by hash. The chain of editions, each naming its predecessor, is the law's skeleton; it grows by deposition and is never rewritten. A move admitted under an edition is stamped with the edition's address. Replay reads each move under its own edition, then forward to the edition in force, one pure reading at a time. Its content is never re-judged: content was judged once, at admission, by its own law. Replay judges only legality (standing and turn) under the current edition. A move that cannot be read forward is listed as unread with a reason, not played, and not silently discarded; it is read again once a release knows its edition.
Adoption is a governance act
The agency's law record names the adopted edition's address. An office adopts an edition by an act on the agency's act chain, and a commit codifies it. A release that realizes an edition its agency has not adopted, or an agency that adopted an edition its release does not realize, is a nonconformity. The group-operations measure reports it to the law's custodian. It never blocks a release. The note's own phrase is that measurements report nonconformities and never demand work.
A migration is code the node runs
Changing the law is a commit: the new edition, its forward reading and its rules. The journal is never swapped and the node is never stopped. And each edition must change what gets accepted; there are no editions for their own sake.
One scheduler: every trigger is declared in the release
A job takes the shape of a Kubernetes CronJob: either a repeat interval from a first due time, or a five-field cron schedule read in a named time zone, with a starting deadline and the existing attempt policy. A job declares its own trigger in its own file, one file per job, so two lanes adding jobs touch different paths and do not conflict. Repository-writing jobs declare their working-tree custody, the paths they hold, and the declarations of two jobs may not overlap. Every hand-linked unit is retired, either by becoming a node job or by deletion because it was dead.
Work orders are meaning-closures
A request's order carries what any carrier needs to make it, and nothing about who makes it: requirements, prohibitions, the result's type and admitted examples.
Why does this matter for self-improvement?
Self-modifying systems fail in two directions. They are either frozen, because every change risks the records, or reckless, because changes happen as side effects. The decision's answer is a ratchet: change is cheap because migration is code, safe because history is read under its own law, and legitimate because adoption is an act that someone can be asked about.
This corresponds to the Knowledge stage of the loop in how to run a company as a MAPE-K loop. If K can be changed by the loop it supports, K needs its own change discipline. Constitutive commitments need a governing act of the right office and are not editable by the loop's own Execute stage.
What is the state of it?
The note keeps a running state section "current as slices land." As of 3 October 2026 it recorded inherited paths read, a stale export realized by one decision, and an inventory of hand timers: five whose node-job twin ran alongside, four with no twin, and five dead service units that were disabled but still installed. The first slice, a single scheduler with calendar triggers, was a candidate branch. We do not claim the full set of decisions is live. Each landing is a separate dated receipt.
What can another organization copy?
- Version your rules as immutable editions, each naming the previous.
- Stamp every stored decision with the edition that admitted it.
- Re-judge only legality on replay, not content.
- Make adoption an act with a named office.
- Report nonconformity; do not block on it.
- Declare every recurring trigger beside the thing it triggers.
- Declare which paths each job may write, and forbid overlap.
Where to go next
Deterministic tools before model tokens · The design sentence, explained · Red Cup Engineering · the 561 Group