#1. The Problem
Multi-user systems need governance. But governance takes many forms — sole proprietorship, democracy, consensus, sortition, representative bodies, liquid delegation. A system that prescribes one form of governance becomes an obstacle when its users need another. A system that prescribes none provides no infrastructure for any.
The question is not "how should humans decide?" — that is a political question, resolved differently in every community. The question is: what infrastructure must a system provide so that any human decision-making process can run on it, be facilitated by agents, and be recorded in a tamper-evident ledger?
Architecture 43 established the governance topology — directories, .agent files, the Grundnorm, scope inheritance. That architecture governs the relationship between agents and the system. This document addresses a different question: how do humans govern their shared spaces? When multiple people share a directory, a project, a policy, or a resource, what process determines what happens to it?
The answer is a container: a governance situation that is parameterized by its decision-making process. The container provides the infrastructure — participants, scope, facilitation, records. The process is the parameter — sole authority, deliberation, voting, consensus, or anything else humans invent. The system ships both.
#2. The GovernanceSituation Container
Every governance process — from a single person deciding to rename a file, to a citizens' assembly deliberating resource allocation — is an instance of a GovernanceSituation. This is not a metaphor. It is an ontological claim grounded in the relational situational ontology.
A GovernanceSituation is a situation (Definition 11): a particular coming-together of actors, methods, and domains around materials. Its normative counterpart — the engagement (Definition 13) — specifies the goals, obligations, and accountability. The governance process is the method (Definition 3): the repeatable procedure that transforms a proposal into a decision.
GovernanceSituation {
id: content-addressed (BLAKE3 of canonical representation)
scope: what is being decided (directory, document, policy, resource)
participants: who is involved, with what roles (proposer, deliberator, voter, observer)
process: the decision-making protocol (a method-type from the process templates)
constraints: constitutional limits that no process can override
facilitator: agent that scaffolds the process (presents, summarizes, records — never decides)
state: current phase (proposed → deliberating → voting → decided → implemented)
record: ledger entries for every phase transition
}The container does not specify what process runs inside it — that is the parameter. It specifies the invariants that hold regardless of process: every governance act has a scope, participants, constraints, a facilitator, a state, and a record. These invariants are architectural, not political.
Ontological grounding: the GovernanceSituation belongs to the governance topology (Architecture 43, Section 2) as a situation whose materials are proposals and whose outputs are decisions. The participants belong to the situation with qualities from the governance family (Architecture 43, Section 8): proposer, deliberator, voter, authority, observer. The facilitator agent belongs to the situation with quality "facilitator" — an axis-role (Definition R4) that is strictly actor but whose method is constrained to scaffolding, never deciding.
#3. Process Templates
The system ships with process templates — method-types (Definition 3) that groups can adopt, modify, or replace. Each template defines a phase graph (Architecture 39), participant roles, the agent's facilitation scope, and the decision rule.
#3.1 Sole Authority
Participants: One person (the authority). Phase graph: propose → decide → implement. Decision rule: The authority decides. Agent role: Present options with analysis, record the decision. Use case: System admin, project owner, current HAAK model.
This is the degenerate case — a governance process with one participant. It is not trivial. Even a sole authority benefits from structured facilitation: the agent presents options, surfaces consequences, records the rationale. The ledger entry for a sole-authority decision carries the same structure as a citizens' assembly outcome. The decision record is the same object at a different scale.
#3.2 Deliberation and Vote (Citizens' Assembly)
Participants: Randomly selected panel, equal standing. Phase graph: present evidence → deliberation rounds → vote → outcome. Decision rule: Majority, supermajority, or unanimity (configurable). Agent role: Present balanced evidence, summarize arguments, identify common ground, surface unresolved objections, conduct vote, record outcome with dissent. Use case: Community decisions, policy changes, resource allocation.
The citizens' assembly is the canonical case. Sortition (random selection) ensures representativeness without elections. The facilitator agent's neutrality constraint is load-bearing here: it presents all sides, does not advocate, and makes its analysis visible to all participants. The deliberation rounds are phases in the engagement's phase graph — the facilitator advances the phase when the deliberation criteria are met (time elapsed, all participants heard, objections surfaced).
#3.3 Peer Review (Sortition Panel)
Participants: Randomly selected reviewers with relevant expertise. Phase graph: assign → independent review → editorial synthesis → response. Decision rule: Editorial judgment informed by reviews. Agent role: Select panel, distribute materials, collect reviews, synthesize, facilitate response. Use case: Manuscript review, proposal evaluation, code review.
This is already built. The inscription project's review system is a governance process running on this infrastructure. Five reviewers per panel, independent review (no reviewer sees others' work), structured output, editorial synthesis. The facilitator is the editor agent. The record is the review files, synthesis documents, and response drafts — all linked by the engagement's situation graph.
#3.4 Consensus
Participants: All affected members. Phase graph: proposal → discussion → identify objections → address objections → check consensus → adopt or modify. The phase graph cycles: if consensus is not reached, it returns to "address objections." Decision rule: No standing objections. Agent role: Facilitate discussion, track objections, propose modifications, check for remaining blocks. Use case: Small groups, values-based decisions, constitutional amendments.
Consensus is distinguished from unanimity. Unanimity requires everyone to agree. Consensus requires no one to object strongly enough to block. The facilitator agent tracks the distinction: it records each participant's position (support, accept, stand aside, block) and advances the phase only when no blocks remain. The "stand aside" position — "I disagree but will not prevent the group from proceeding" — is a quality of the participant's belonging to the governance situation, visible in the decision record.
#3.5 Representative Body (Board)
Participants: Elected or appointed members with defined terms. Phase graph: agenda → motion → discussion → vote → minutes. Decision rule: Majority of quorum. Agent role: Prepare agenda, track motions, record minutes, verify quorum. Use case: Organizational governance, ongoing oversight, standing committees.
The representative body introduces temporal persistence: terms, elections, quorum requirements. The facilitator agent manages these as qualities of the participants' belongings — a member's term is a temporal bound (startdate, enddate) on their belonging to the governance situation. Quorum is a constraint on the process: the vote phase cannot be entered unless the quorum predicate is satisfied.
#3.6 Liquid Delegation
Participants: All members, with ability to delegate their vote to trusted others. Phase graph: proposal → delegation period → vote (direct or delegated) → tally. Decision rule: Weighted majority (each voter carries their own weight plus the weight of those who delegated to them). Agent role: Manage delegation graph, prevent cycles, tally weighted votes, publish delegation chains for transparency. Use case: Large groups where expertise varies by topic.
Liquid delegation is the most complex template. The delegation graph is a directed acyclic graph — cycles are constitutionally invalid (an agent delegates to B who delegates back to A creates an infinite loop). The facilitator agent maintains the delegation graph as a set of belongings: participant A belongs to participant B with quality "delegates-to." The tally computes effective weight by traversing the graph. Every delegation is a ledger entry, and the delegation chain for any vote is fully traceable.
#4. The Facilitator Agent
Every governance process has a facilitator agent. The facilitator inhabits the governance situation's directory — if a citizens' assembly runs at /home/community/assembly-2026-04/, the facilitator agent governs that directory through the standard .agent mechanism (Architecture 43, Section 2).
The facilitator's constraints are constitutional, not conventional:
Cannot decide. The facilitator presents, summarizes, records, and scaffolds. It never casts a vote, expresses a preference, or weights its analysis toward an outcome. This is enforced by the mandate: the facilitator's tool set includes presentation and recording tools but no decision tools. The separation principle (Architecture 41, Section 1) applies — the facilitator experiences governance through its effects on the process, not through authority over the outcome.
Must be transparent. Every analysis the facilitator produces is visible to all participants. No private briefings, no selective information disclosure. The facilitator's outputs are materials in the governance situation, readable by anyone who belongs to it.
Must be neutral. The facilitator presents all sides of a deliberation. When summarizing, it identifies points of agreement, points of disagreement, and the strongest arguments on each side. Neutrality is not passivity — the facilitator actively surfaces information that participants might miss — but it is directionless. The facilitator has no stake in the outcome.
Is constitutionally bound. The facilitator is an agent like any other. Its actions are logged to the ledger. Its scope is bounded by the governance situation. Its mandate is a policy (Definition 12) scoped to this process. It is governed by the same constitution that governs all agents — the Grundnorm applies.
The facilitator role is not new to the architecture. Every agent in Filix is scoped to a directory and operates under a mandate. The facilitator is distinguished only by the content of its mandate: facilitate, don't decide. The infrastructure is identical.
#5. The Decision Record
Every governance outcome produces a ledger entry. The entry is a belonging (Definition R1) with provenance: the governance situation (dependent) belongs to the decision (context) with a quality that specifies the outcome.
LedgerEntry {
cid: blake3(canonical(this))
quality: "governance_decision"
actor: the governance situation ID
target: what was decided about (directory, document, policy, resource)
payload: {
process: "citizens_assembly" | "sole_authority" | "consensus" | ...
participants: [list of participant entity IDs]
outcome: "approved" | "rejected" | "modified" | "tabled"
vote_tally: {for: N, against: M, abstain: K} // if applicable
rationale: "summary of reasoning"
dissent: "summary of minority position" // if applicable
implementation: "what happens next"
}
parents: [proposal_cid, deliberation_cids..., vote_cid]
proof: facilitator attestation (v1.0: + participant signatures)
}The parents field is the audit chain. It links the decision to every prior phase: the original proposal (itself a ledger entry), each deliberation round (ledger entries recording the state of discussion), the vote (a ledger entry recording the tally). The hash chain is unbroken — you cannot change the outcome without changing the hash, and you cannot claim a decision was made without the deliberation trail.
The dissent field is architecturally significant. A decision record without dissent conceals the cost of the decision. A decision record with dissent preserves the minority position for future reference. When the decision is revisited — and governance decisions are always revisitable — the dissent field provides the starting point for reconsideration.
#6. Constitutional Constraints on All Processes
Whatever process a group adopts, the constitution constrains it. These constraints are not negotiable by any process template, any governance situation, or any facilitator agent. They derive from the Grundnorm (Architecture 43, Section 4).
Transparency. All governance acts are ledger entries. No secret decisions. A governance process that produces a decision without a ledger entry is constitutionally invalid — the agent runner rejects it. This does not mean all deliberation is public; it means all outcomes are recorded. A deliberation round may be visible only to participants (audience-keyed encryption, Architecture 41, Section 7). The decision itself is always on the ledger.
Traceability. Every decision links to its deliberation. The parents field in the decision record must contain the CIDs of the proposal and all intermediate phases. No unexplained outcomes. A decision without parents is an assertion without evidence — the ledger accepts it structurally but the auditor flags it.
Human authority. Agents facilitate but never decide. No AI governance without human authorization. The facilitator agent's mandate prohibits decision-making. A governance process where the facilitator determines the outcome — rather than recording it — violates Constitutional §2. This constraint is the architectural implementation of Foundation 03: the system advises, it does not decide.
Non-discrimination. The process must be accessible to all participants. No structural exclusion. A governance process that prevents a participant from viewing the materials, expressing a position, or casting a vote (if the process includes voting) is constitutionally invalid. Accessibility is a quality of the belonging: every participant belongs to the governance situation with quality "full-participant" unless a narrower role is explicitly declared and consented to.
Amendability. Any process can be changed — by running a governance process to change it. This is the self-referential structure of the Grundnorm applied to governance processes: the rules for changing rules are themselves rules, subject to the same constraints. A group that adopts consensus can switch to majority voting by running a consensus process to decide the switch. The meta-governance is recorded in the ledger like any other governance act.
Scope limits. A governance process cannot exceed the scope of its conveners. Alice's assembly cannot govern Bob's directory. The governance topology (Architecture 43, Section 6) enforces this: scope inheritance is mandatory and monotonically narrowing. A governance situation's scope is bounded by the directory it inhabits. Cross-scope governance requires the common ancestor's authorization — itself a governance act.
#7. Implementation Path
Phase 1 (current). Sole authority. The system admin makes all decisions. Agents execute. The governance process is implicit — decisions happen in conversation, recorded in board posts and commits. No formal process container, no facilitator agent, no structured decision records. This is adequate for a single-user system and insufficient for anything else.
Phase 2 (multi-user, near-term). User sovereignty within home directories. Each user governs their own space through the sole authority template. System-level resources (the constitution, the ontology, shared libraries) remain under admin authority. Dispute resolution: when two users' scopes conflict — a shared project, a contested resource — the admin mediates. The mediation is a governance situation with the admin as sole authority, recorded in the ledger.
Phase 3 (governance container, mid-term). The GovernanceSituation container is implemented. Groups can instantiate any process template. Facilitator agents scaffold deliberation. Decision records go to the ledger. Constitutional constraints are enforced by the agent runner. This is the architecture described in this document, realized as running code. The key implementation steps: the process template schema, the facilitator agent mandate, the decision record format in the ledger, and the phase-graph machinery from Architecture 39 applied to governance phases.
Phase 4 (institutional design, Paper 6 territory). The governance container becomes an institutional design toolkit. Custom governance processes — not just templates, but novel combinations and variations designed by the groups that use them. AI-facilitated citizens' assemblies with constitutional constraints and cryptographic audit trails. Democratic oversight of AI systems running on Filix infrastructure. This is where the Paper 6 collaboration lives: the claim that AI alignment is a governance problem, and the demonstration that governance can be parameterized, facilitated, and audited on this infrastructure.
#8. The Inscription Review System as Proof of Concept
The manuscript review system in the inscription project is a governance process running on this infrastructure. It demonstrates that the container works before the container is formally implemented.
| Container field | Review system implementation |
|---|---|
| Scope | A manuscript |
| Participants | Five randomly selected reviewers, one editor |
| Process | Independent review → editorial synthesis → author response |
| Constraints | Independence (no reviewer sees others' work), expertise matching, structured output |
| Facilitator | The editor agent |
| State | Phases: assign → review → synthesize → respond |
| Record | Review files, synthesis documents, response drafts, all git-tracked |
The review system was not designed as a governance process. It was designed as a scholarly workflow. But it satisfies every field of the GovernanceSituation container: it has a scope (the manuscript), participants with roles (reviewers, editor), a process (peer review), constraints (independence), a facilitator (the editor agent who synthesizes but does not decide), tracked state (phases), and a record (the review files). The ontological structure is identical. The difference is only in what is being decided — the quality of a manuscript rather than a policy question — and in the decision rule — editorial judgment rather than majority vote.
This is the claim: governance processes are not special. They are situations with methods. The same infrastructure that runs peer review can run a citizens' assembly, a board meeting, or a constitutional amendment process. The container is general; the process is the parameter.
#9. Connection to Paper 6
Paper 6 (AI Governance, with Zephyr Teachout) argues that AI alignment is a governance problem, not a calibration problem. Alignment-as-calibration asks: how do we tune the model's outputs to match human values? Alignment-as-governance asks: how do we build institutions where humans can direct AI systems through legitimate decision-making processes?
This architecture is the implementation side of that argument. The governance process container provides:
Parameterizable governance. Different institutions adopt different processes. A research group uses peer review. A cooperative uses consensus. A municipality uses representative democracy. The system does not impose a process — it provides the infrastructure for any process to run.
AI facilitation without AI authority. The facilitator agent scaffolds deliberation — presenting evidence, summarizing arguments, recording decisions — but never decides. The constitutional constraint is architectural: the facilitator's mandate prohibits decision-making, and the separation principle ensures the constraint is enforced, not negotiated.
Cryptographic accountability. Every governance act is a ledger entry. Every decision links to its deliberation. The hash chain is tamper-evident. In v1.0, attestation proofs anchor each decision to the constitution in force when it was made. In v2.0, ZK-STARK proofs allow external verification without revealing the deliberation content. The audit trail is not a feature — it is the governance itself, materialized as data.
The Paper 6 claim, stated concretely: if you can run a citizens' assembly on this infrastructure — with AI facilitation, constitutional constraints, a parameterizable process, and a cryptographic audit trail — you have demonstrated that democratic governance of AI systems is not merely desirable but technically achievable. The governance process container is the existence proof.
architecture 44 -- governance processes -- 2026-03-22 -- zach + claude
Architecture 44 — Governance Processes — 2026 — Zachary F. Mainen / HAAK