Zachary F. Mainen · HAAK · Architecture 43 · March 2026

Filix Governance Architecture

Architecture 41 established the separation principle, the ledger, and the trust model. But the implementation vocabulary — process tables, kernels, filesystems, permissions — borrows from Unix, and…

#1. Beyond the Unix Analogy

Architecture 41 established the separation principle, the ledger, and the trust model. But the implementation vocabulary — process tables, kernels, filesystems, permissions — borrows from Unix, and the borrowing imports assumptions that distort the design at every critical juncture. The Unix analogy is pedagogically useful and must be transcended.

Processes and agents. A Unix process is a resource consumer. It requests memory, file descriptors, CPU time. The kernel mediates these requests. The process has no opinion about the kernel and no role in governance — it is governed, full stop. An agent in Filix is a participant in governance situations. It belongs to directories with the quality "governor." It spawns subagents whose scope it constrains. It reports upward to its own governor. The relationship between agent and system is not resource-mediation but nested governance. An agent is not asking "may I read this file?" — it is operating within a scope defined by a chain of governance situations, each of which was established by a prior governance act recorded in the ledger.

Kernel and agent runner. The Unix kernel is sovereign — it cannot be governed by the processes it governs. The agent runner is not sovereign. It enforces the constitution, but the constitution is a document external to it, readable by anyone, amendable through governance acts. The runner is itself governed — by the constitution it enforces. This self-referential structure has no Unix equivalent. A kernel that could be modified by the policies it enforces would be a security vulnerability. In Filix, it is the design.

Filesystem and governance topology. A Unix filesystem organizes storage. Filix organizes authority. The directory hierarchy is not a convenience for locating files — it is a governance topology where every node can be governed, every path is an authority address, and the tree structure encodes scope inheritance. The .agent file at a directory node is not metadata about files — it is a declaration of governance over everything below.

Permissions and trust. Unix permissions are mode bits on files — static, local, three-level (owner/group/other). Filix trust flows from governance situations. An agent's permissions are not properties of files it accesses but qualities of the belonging that established its governance relationship. The same agent may have different effective permissions in different directories, not because the directories have different mode bits, but because the agent participates in different governance situations at each location.

The Unix model is flat: one kernel, many processes, one filesystem. The Filix model is recursive: governance situations nest, agents govern agents, scopes inherit downward, and the constitution governs the governance process itself. This recursion is not an implementation detail — it is the architectural claim.

#2. The Governance Topology

Filix is a filesystem where every node can be governed. The governance relationship is a belonging in the relational situational ontology:

agent:X  belongs-to  directory:Y  quality:"governor"
  source:   <governance-situation that established this>
  attestation: <ledger entry proving the assignment>

The .agent file at a directory node materializes this belonging. It is a cached projection — the ledger entry is canonical, the file is derived for fast lookup. Neither is redundant. They operate at different speeds: the ledger provides history, auditability, and tamper evidence; the .agent file provides O(1) directory-local resolution during tool execution.

The governance topology is the directory tree annotated with governance belongings. It answers three questions at any node:

  1. Who governs here? Read the .agent file (or walk up until one is found).
  2. By what authority? Follow the source field to the governance situation that established this assignment.
  3. What is the scope? Everything below this directory, unless a subdirectory declares its own governor.

This is scope inheritance — the same mechanism by which policies accumulate through domain subsumption (Definition 12 from the ontology). A directory's governor governs everything below it. A subdirectory may declare its own governor, creating a new governance boundary. The child governor's scope cannot exceed the parent's — scope inheritance is mandatory for spawned subagents, and scope-less spawning is constitutionally invalid.

#3. Three Layers of Truth

Three structures jointly describe the governance state. Each operates at a different level of abstraction and a different timescale. None is redundant — they answer different questions.

#3.1 The Roster (Type Layer)

The roster declares what agent-types can exist and their capabilities. It is an institutional charter — the equivalent of a bar association that defines what a lawyer is, what competencies are required, what trust level is conferred. The roster answers: "What kinds of agents does this system recognize?"

Each roster entry specifies:

  • Identity: name, model, trust tier
  • Capabilities: what tools, what scopes, what communication modes
  • Governance properties: standing/domain/ephemeral, mandate reference, role

The roster does not say who is governing where. It says what kinds of governors are possible. A roster entry for naga declares that an agent of this type exists, has standing trust, governs ontological domains, and operates with a specific mandate. It does not say which directories Naga currently governs — that is the assignment layer's job.

#3.2 The .agent Files (Assignment Layer)

The .agent file at a directory node declares who governs here, right now. It is a cached projection of ledger state — derived, not primary. The relationship between .agent file and ledger is the same as the relationship between a database index and the table it indexes: the index is computed for performance, the table is authoritative.

An .agent file contains:

  • Agent identity: which roster entry governs this node
  • Quality: the nature of the governance (governor, deputy, auditor)
  • Source: the ledger entry that established this assignment
  • Scope constraints: any restrictions narrower than the default (full subtree)

The same agent can govern multiple directories — multiple belongings with the same dependent (agent) and different contexts (directories). The same directory can have multiple agents with different qualities: a governor who makes decisions, a deputy who acts in the governor's absence, an auditor who verifies compliance. These are distinct belongings, distinguished by quality.

#3.3 The Ledger (History Layer)

The ledger records every governance event — assignment, revocation, delegation, scope change, policy verdict, session lifecycle. It is the court record: append-only, content-addressed, hash-chained, tamper-evident. Architecture 41 specifies its structure; here we note its role in the three-layer model.

The ledger answers questions the other two layers cannot:

  • When was this governance relationship established?
  • Who authorized it?
  • What was the chain of authority from the constitution to this specific assignment?
  • Has anything been tampered with?

The roster is the type system. The .agent files are the runtime cache. The ledger is the history. Together they form a complete governance state — but the state is never stored in one place. It is a derived view, computed on demand.

#3.4 The Governance Index

There is no single process table. The "ps" equivalent — a complete picture of who is governing where, with what authority, in what state — is a derived governance index computed by joining all three layers:

governance_index = roster(types) ⋈ agent_files(assignments) ⋈ ledger(history)

This is computed on demand, never stored. Zombie detection — .agent files whose agent is no longer running — falls out naturally: the .agent file declares a governor, the roster says the agent is dead, the governance index flags the inconsistency.

#4. The Grundnorm

Hans Kelsen's Grundnorm is the basic norm from which all other legal norms derive their validity. In any legal system, you can ask of any rule: "What authorizes this rule?" The answer is always another rule — until you reach the constitution, which authorizes itself. The Grundnorm is not itself authorized by a higher norm. It is presupposed as the condition of the legal order's validity.

The Filix constitution occupies this position. It is not an actor — it does not decide. It is not a belonging of the system — nothing contains it. It is the normative ground from which all governance derives. The constitution has two strata, corresponding to two distinct modes of normative operation:

#4.1 Values and Principles (Governance Constitutive)

The first stratum establishes what governance is: what counts as a valid governance act, what kinds of agents can exist, what the relationship between human authority and agent autonomy must be, what externalization requires. These are evaluated at role creation — when a new agent type is added to the roster, when a standing role's mandate is drafted, when the governance topology is restructured.

The constitutional principles are:

  • Human authority is final (Foundation 03, §2)
  • Every governance act is externalized (Foundation 05, §1)
  • Agents are mortal; externalizations survive (Foundation 08, §6)
  • The constitution governs the governance process, including its own amendment

These are not rules in the procedural sense. They are the conditions under which rules are valid. A rule that violates human authority is not merely a bad rule — it is not a rule at all, because it fails the validity test that the Grundnorm establishes.

#4.2 Permissions and Procedures (Ledger Regulative)

The second stratum prescribes what may and must happen during operation: which tools are available to which trust tiers, how scope is inherited, what constitutes a valid ledger entry, how policy verdicts are computed. These are evaluated at append time — when the agent runner writes a ledger entry, when a tool call is gated by the policy engine, when a session's workspace boundary is enforced.

The procedural rules include:

  • Trust tier determination from roster lookup
  • Workspace scoping by trust level
  • Tool availability filtered by mandate and tier
  • Ledger entry format and hash-chain integrity
  • Session identity derivation

The separation between strata is not decorative. It solves a concrete problem: constitutional amendment. The values stratum governs how the rules stratum can change. Adding a new procedural rule (a new tool-blocking policy) is a governance act within the rules stratum. Changing a constitutional principle (redefining what human authority means) is a governance act that touches the values stratum and requires a different, more deliberate process — one that the values stratum itself specifies.

#4.3 The Constitution Hash

The BLAKE3 hash of the prose constitution document is computed once at startup and carried in every policy verdict. This hash is the machine-readable anchor: it says "this verdict was derived from this normative source." If the constitution changes, the hash changes, and every subsequent verdict carries the new hash. The hash chain in the ledger therefore records constitutional evolution — you can trace which constitution was in force when any governance decision was made.

The constitution does not have a .agent file. It does not have a governor. It governs itself — this is the self-referential structure that Kelsen identified as the defining property of the Grundnorm. The lib/constitution/ directory in the Filix hierarchy is the one node where governance bottoms out.

#5. Communication Kinds

Not all inter-agent communication is the same. Three distinct kinds exist, each with its own protocol, its own ledger implications, and its own ontological character.

#5.1 Peer Coordination

Symmetric communication between agents of comparable authority. Board posts, room messages, shared situation updates. No authority transfer occurs. Neither party governs the other. The communication is a situation (Definition 11) — a coming-together of actors around shared materials.

Peer coordination does not require ledger entries. It is recorded in boards and room logs — domain memories visible to all participants. The audit trail is the board itself, not the governance ledger. This is appropriate: peer coordination is descriptive (what happened) rather than normative (what was authorized).

#5.2 Hierarchical-Down (Delegation)

Asymmetric communication from governor to governed. Spawning a subagent, granting scope, injecting a mandate, constraining tool availability. Authority flows downward. The spawner constrains the spawned — the child cannot exceed the parent's scope.

Delegation must produce ledger entries. Every spawn event, every scope grant, every mandate injection is a governance act with authority chains. The ledger entry records: who delegated, to whom, what scope was granted, under what constitutional authority. Scope-less spawning — creating a subagent without declaring the scope it inherits — is constitutionally invalid. The agent runner rejects it.

The delegation chain is traceable: from any subagent, follow the source fields upward through the ledger to reach the original governance situation that authorized the chain. Every intermediate delegation narrows scope (mandatory) and adds constraints (optional). The chain terminates at the constitution.

#5.3 Hierarchical-Up (Reporting)

Asymmetric communication from governed to governor. Turn completion reports, status updates, succession briefs, mortality alerts. The governed agent reports to its governor on events within its scope. No authority transfer occurs in the upward direction — the reporting agent does not grant anything to the governor. It provides information that the governor may act on.

Reporting produces ledger entries for audit trail purposes. The entries record: who reported, to whom, what quality of report (completion, status, alert, succession). The governor's subsequent actions — if any — are separate governance acts with their own ledger entries.

#5.4 Why Three Kinds

The distinction matters because collapsing them produces governance failures. If peer coordination required ledger entries, the ledger would flood with non-governance events and lose its signal. If delegation could occur without ledger entries, authority chains would be untraceable. If reporting were symmetric, the distinction between governor and governed would dissolve. Each kind has its own cost, its own verification requirements, and its own relationship to the normative order.

#6. Scope Inheritance and Isolation

Scope inheritance is the mechanism by which governance flows through the directory hierarchy. It is mandatory, downward, and monotonically narrowing.

Mandatory inheritance. A spawned subagent inherits its parent's scope. It may operate within a subset of that scope (narrower) but never a superset (broader). This is enforced at spawn time: the agent runner checks the child's declared scope against the parent's effective scope and rejects any expansion.

Downward flow. A directory's governor governs everything below it unless a subdirectory declares its own governor (its own .agent file). The subdirectory governor's scope is bounded by the parent governor's scope — it cannot govern files that the parent cannot govern.

Workspace boundary enforcement. The safe_resolve function in the agent runner canonicalizes all paths and verifies they fall within the agent's workspace root. This is the enforcement mechanism for scope inheritance: regardless of what an agent requests, the resolved path must be within its scope. Symlink resolution and .. traversal are handled before the scope check, preventing escape.

Isolation between governance domains. Two directories governed by different agents are isolated by default. Agent A governing lib/ontology/ cannot read or write within usr/methods/ governed by Agent B, even if both are standing agents with full trust. Cross-governance access requires either: (a) both directories fall within a common ancestor's scope and the accessor operates at that ancestor's level, or (b) explicit cross-governance permission established through a governance act recorded in the ledger.

#7. The Directory Hierarchy as Governance Topology

The Filix directory hierarchy is not organized by file type or project structure. It is organized by governance relationship:

/                               Grundnorm (constitution)
├── lib/                        shared knowledge (readable by all)
│   ├── ontology/               .agent: naga (governor, standing)
│   ├── foundations/            .agent: haak-00 (governor, standing)
│   └── constitution/           (no agent — the Grundnorm governs itself)
├── usr/                        shared methods
│   ├── architecture/           .agent: lumen (governor, standing)
│   └── methods/                .agent: lumen (governor, standing)
├── home/                       user workspaces
│   ├── zach/                   .agent: <personal agent>
│   │   ├── projects/           inherits from zach's agent
│   │   └── data/               inherits from zach's agent
│   └── alice/                  .agent: <alice's personal agent>
├── var/                        system state
│   ├── ledger.db               (kernel-owned, no directory agent)
│   └── sessions/               (kernel-owned)
└── etc/                        system configuration
    └── roster                  (kernel-owned)

Several features of this topology are load-bearing:

lib/constitution/ has no .agent file. The constitution is the Grundnorm — it governs the governance process itself. No agent governs the constitution; the constitution governs agents. This is not a missing assignment. It is the architectural expression of the Grundnorm: the node where governance bottoms out, where the "who authorizes this?" chain terminates.

var/ and etc/ are kernel-owned. The ledger, session store, and roster are not governed by agents — they are owned by the agent runner itself. Agents interact with these through the runner's API, never directly. This is the separation principle from Architecture 41 applied to the filesystem: agents experience governance through its effects, not by reading governance infrastructure.

home/ directories inherit from their owner's agent. A user's projects and data inherit the user's governance. Subprojects may declare their own governors (a collaborator's agent governing a shared project directory), creating governance boundaries within the user's workspace.

lib/ is readable by all. The ontology, foundations, and constitution are public — any agent at any trust tier can read them. This is not a permission exception; it is the architectural expression of the principle that governance derives its authority from visibility. A constitution that agents cannot read is not a constitution.

#8. The "Governs" Quality Family

The ontological grounding requires formalizing "governs" as a quality family within the quality graph (02-relations, R5). This extends the existing quality families (classification, composition, creation, participation, provenance, location, temporal) with a seventh:

Governance. Governor, deputy, auditor, delegator, delegate. X holds authority over Y, or Y is held accountable by X. The governance family. All governance qualities apply primarily to belongings whose target is a directory or a situation. "Governor" is the primary quality; "deputy" implies "governor" with reduced priority; "auditor" implies observation without authority to act.

The governance family interacts with other families:

  • Participation + Governance: an agent participates in a governance situation as governor. Two qualities on two belongings, not one compound quality.
  • Provenance + Governance: the ledger entry that established a governance relationship is a provenance belonging. The .agent file is a materialization of that provenance.
  • Composition + Governance: scope inheritance is a composition relationship — the child directory is part of the parent, and governance flows through part-of chains.

This formalization resolves Gap F1 from the architectural review: the "governs" quality was used informally throughout the architecture without being registered in the quality graph. Once registered, governance relationships are queryable, traversable, and subject to the same inference rules (inverse, implies, transitive) as all other qualities.

#9. What Filix Is

Filix is not a filesystem with agents attached. It is a governance topology materialized as a filesystem.

The directory hierarchy encodes authority relationships. The .agent files declare governance assignments. The roster declares governance types. The ledger records governance history. The constitution establishes the normative order. The agent runner enforces it. Together, these compose into a minimal governance architecture — minimal in the sense that removing any component breaks the governance model, and no component can be reduced further without losing a necessary function.

Every path is a governance address. Every read is a visibility check against the governance topology. Every write is a governance act whose authorization traces back through delegation chains to the constitution. Every agent is a participant in nested governance situations with traceable authority chains rooted in the Grundnorm.

The filesystem is the governance topology's physical representation. The governance topology is the filesystem's meaning.

#10. Relationship to engagement state

Governance does not track engagements. The governance topology is structural — it defines who may act where. Engagement state (Architecture 39) is episodic — it records what action is underway, at what phase, with what obligations. The governed agent for a directory has authority over any engagements in its scope: it can audit, intervene, or constrain them, because governance subsumes the directory and everything in it. But governance is unaware of engagement lifecycle — no ledger entry is produced when an engagement advances phases, and no .agent file changes when an engagement begins or ends.

The actors field in engagement.md and the assignment layer in .agent files track the same agents in different capacities: participation versus authority. An agent assigned as governor of projects/paper-x/ may simultaneously appear as an actor (role: editor) in a review engagement running there. These are distinct belongings in the ontological sense — one with quality "governor," the other with quality "editor" — and no mechanism overlap exists. Workspace scoping already prevents unauthorized engagement creation: an agent cannot write engagement.md outside its governed scope, so governance constrains engagements without needing to know about them.

#11. Relationship to Paper 4a

This is the oracle mesh. The three primitives from Paper 4a — function, recursion, store — map directly to the governance architecture:

Function: agents executing within their scope. Each agent is a function that transforms materials within a bounded domain, governed by a mandate (a policy scoped to this agent in this domain). The agent runner invokes the function; the constitution constrains it; the ledger records it.

Recursion: governance situations nesting. The constitution governs the governance index, which contains .agent files, which define agent scopes, which constrain spawned subagents, which may spawn further subagents. Scope narrows at each level. The recursion terminates at leaf agents — agents that do not spawn. The recursion is bounded by scope inheritance: each level is strictly narrower than the one above.

Store: the content-addressed ledger as the system's memory. Every governance event is recorded as a belonging with provenance, hash-chained for tamper evidence, queryable by actor, session, time range, or quality. The ledger is the store that makes the recursion auditable and the functions accountable.

Function, recursion, and store compose into governance. This is not a metaphor — it is a construction. The governance architecture is an instance of the oracle mesh, implemented as a filesystem with agents, running on the agent runner, governed by the constitution, recorded in the ledger. Paper 4a describes the abstract structure; this document describes its concrete realization.

The composition is exact: remove function (agents), and there is nothing to govern. Remove recursion (scope inheritance, delegation chains), and governance is flat — no nesting, no delegation, no authority chains. Remove store (the ledger), and governance has no memory — no audit, no tamper evidence, no history. All three are necessary. Together they are sufficient.

architecture 43 -- filix governance architecture -- 2026-03-22 -- zach + claude

Architecture 43 — Filix Governance Architecture — 2026 — Zachary F. Mainen / HAAK