Self-Modification

HAAK is a self-modifying system. Its domain forest, method inventory, engagement population, and foundations change over time. Three claims govern how: (1) all self-modification is engagement-mediated, (2) the distinction between structural and configurational change is level-relative, and (3) governance intensity scales with the level at which a modification is configurational. Human authority is the constitutional anchor at every level.

#All self-modification is engagement-mediated

Creating a new domain token (a new paper project), a new engagement (a new review cycle), or a new method (a documented procedure) — all require an engagement. There is no mechanism for the system to modify itself outside of deliberate, governed work.

This is not a design preference but a consequence of three constitutional requirements:

• Without an engagement, self-modification would be unauditable — no record tracking who proposed the change and who approved it
• Without a work point, it would be ungoverned — no constraints resolved, no human authority exercised
• Without externalized state, it would be invisible — no before-and-after captured

Concretely, creating a new paper project follows the standard pattern:

method:      architect
domain:      mainen-lab (the parent scope)
engagement:  "stand up neural-coding-review"
output:      new domain token, added to the forest as a child of mainen-lab

The parent domain scopes the creation. The method provides the procedure. The engagement is where agency, deliberation, and governance converge. The output — a new node in the domain forest — is a modification to the system's self-description, produced through the system's own governance.

#Level-relativity of structural change

It is tempting to distinguish "structural" modification (changing what the system can express) from "configurational" modification (adding instances within existing vocabulary). Creating a paper project feels configurational — the paper type exists; you add a token. Creating a new domain kind (say, "consortium") feels structural — you expand what domain types are possible.

This distinction is real but not fundamental. It is relative to the level of description.

The key insight: types at level n are tokens at level n+1.

The "paper" domain kind is a type at L₀ (relative to paper instances like face-states) but simultaneously a token at L₁ (an element in the collection of domain kinds). Creating a new domain kind is adding a token at L₁ — configurational at that level, even though it is structural at L₀.

Level	Example modification	What changes	Configurational at
L₀	Create face-states paper project	Token population of paper kind	L₀
L₁	Create consortium domain kind	Type vocabulary of domain kinds	L₁
L₂	Create a new organizational axis	Axis vocabulary	L₂
L₃	Change what "axis" means	Meta-structure of the model	L₃

Each row is structural at the level below and configurational at its own level. There is no absolute boundary between "changing the population" and "changing the grammar." The boundary shifts with the level of description. What looks like a constitutional amendment from inside the system looks like a routine parameter update from one level up.

The hierarchy is shallow in practice — three or four levels deep for HAAK. But the principle is unbounded: at every level, structural change is configurational change viewed from above.

#Governance scales with level

Because the structural/configurational boundary is level-relative, the governance question is not "is this structural or configurational?" but "at what level is this configurational?" The answer determines blast radius, which determines appropriate governance intensity.

Level	Blast radius	Governance	Examples
L₀	Local — one project	PI decision, routine	Start a paper project, begin a review
L₁	Moderate — affects future instances	Deliberative; requires architecture doc	Add a domain kind, create a method type
L₂	System-wide — restructures coordination	Constitutional; explicit process	Add an organizational axis, change level hierarchy
L₃	Foundational — changes self-description	Rare; philosophical justification	Redefine what "axis" means

Most activity occurs at L₀: creating projects, starting engagements, instantiating methods. This is the system operating normally — self-modification in the strict sense, but routine, governed by standing authority.

The highest levels are where the system's identity is at stake. Changing what "axis" means should not happen as a side effect of a Tuesday afternoon engagement. It requires the kind of deliberation that produces foundations — documents articulating why before how, reviewed carefully, with explicit arguments.

The intermediate levels — creating new domain kinds, method types, engagement templates — are where the system grows its vocabulary. This is where the most interesting governance questions arise. The blast radius is real but bounded. Appropriate governance: write an architecture doc, update relevant indices, review with the PI.

#Insertability

Insertability is a special case of configurational self-modification: inserting a new level in the method hierarchy adds a token at L₁; inserting a new intermediate domain adds a token at L₀. Both preserve existing relationships while growing the structure.

This holds on all three axes:

• Method axis: Insert "conventions" between policies and methods. The total order accommodates it; existing inheritance paths gain an intermediate step but don't break.
• Domain axis: Insert computational-neuroscience between mainen-lab and specific collaborations. The tree gains depth.
• Engagement axis: Insert sub-phases into a review round. The phase graph gains nodes; existing edges reconnect.

The formal property: each axis defines a partial order that admits refinement. Given any two comparable elements a < b, a new element c can be inserted such that a < c < b, without contradicting inherited constraints. The system grows without redesign.

#The self-referential problem

This foundation describes how the system modifies itself. The system can also modify this foundation — changing the rules of self-modification. This is the L₃ case: meta-structural change.

HAAK's current answer is simple and sufficient: the PI resolves. Human authority is the constitutional anchor that prevents infinite regress. The system can propose changes to its own governance; the human decides whether to accept them. This is not a formal solution to the self-reference problem — it is a practical one that works because there is a human in the loop.

If HAAK were fully autonomous, the self-reference problem would be acute. For an externalized reasoning system with human oversight, it is manageable: the human is the fixed point.

#Historical development

Self-modification theory was developed in the three-axis model (v1/14, Feb 23 2026) as part of the type/token analysis. It was split into its own foundation because:

1. The three-axis model was 697 lines — exceeding the 500-line convention
2. Self-modification is a foundation-level concern independent of the three-axis decomposition
3. The governance-scales-with-level principle informs the constitution directly

#Constitutional implications

This foundation grounds two constitutional requirements:

1. Human authority (Constitution §2): "The PI has final authority over all system decisions." This is the resolution of the self-referential problem — human authority is the fixed point that prevents governance from modifying its own anchor.

1. Self-amendment (Constitution § "Itself"): "Amendments require PI approval." This is the L₃ governance rule: changes to the constitution are engagement-mediated and require the highest level of human authorization.

---

haak · foundation · 2026-02-24 · zach + claude

Foundations 09 — Self-Modification — 2026 — Zachary F. Mainen / HAAK