0 — Mutate: The Foundational Idea

Every interaction with Colibri is a state mutation. Not most interactions — all of them. Not in principle — in practice, as a first-class citizen of the system design.

This is what makes Colibri different from a conventional MCP server. A regular MCP server executes tools. It responds to requests. Colibri does execute tools and respond to requests. But Colibri also records the fact of execution as immutable, hash-chained state in the database before the response ever leaves the wire.

The Invariant

The invariant is simple: nothing happens without creating a ζ record and passing through the α chain.

When a client calls server_ping, it passes through the α middleware chain (5 stages), leaves a ζ thought record in the database, and returns. The ping mutates the system state. When a client calls task_create, it passes through α, validates the payload, writes a task row to SQLite, leaves two ζ records (one on entry, one on exit), and returns. The task creation mutates state. When a client calls task_list (a read-only operation), it still passes through α, still creates a ζ observation record. Even a read is a mutation in Colibri’s model.

This is intentional. It is the foundation.

Why Mutation Matters

In conventional systems, reads and writes are categorically different. Reads are cheap, fast, and invisible. Writes are expensive, coordinated, and logged. This distinction works when you trust the boundary between user and system — when you can cleanly separate the subject (who requested something) from the verb (what they requested) from the object (what they requested it about).

Colibri abandons this assumption. Colibri is designed to operate under the seven axioms of legitimacy (see constitution): append-only history, derived reputation, no absolute authority, consequence windows, subjective finality, right to exit, technical sovereignty. Under these axioms, the fact that someone called task_list is itself data. It’s data about the system’s execution, the caller’s engagement, the request that was made, and the response that came back. It belongs in the immutable record.

The phrase “state mutation” captures this exactly: every tool call, whether it reads or writes, mutates the observable state of the system. The ζ decision trail records every mutation. The η proof store, in proof-grade rounds, attests that the chain of mutations is valid.

The Three Axes Converge on Mutation

Execution axis (α): 19 Phase 0 tools, each one a mutation handler. The α chain validates every mutation before dispatch and records its outcome.
Intelligence axis (ζ, δ, ε): The ζ decision trail is the complete log of every mutation. The δ router makes routing decisions based on ζ history. The ε skill registry records when skills are invoked, which is a mutation event.
Legitimacy axis (η, constitution): The η proof store creates a Merkle tree of mutations. The constitution (7 axioms) defines what mutations are legitimate.

All three axes depend on the fact that mutation is the fundamental unit of work.

Structure of a Mutation

Every mutation follows the same 5-stage path through the α chain:

tool-lock: Serialize access. One tool call at a time.
schema-validate: Zod schema verification on inputs.
audit-enter: Create a ζ observation record (the fact of the call).
dispatch: Execute the tool handler. Most mutations write to SQLite here.
audit-exit: Create a ζ reflection record (the outcome).

For proof-grade mutations, a 6th step happens asynchronously:

merkle-attest: Append a leaf to the η Merkle tree (deferred Phase 1.5).

The output of a mutation is:

A JSON-RPC response to the client.
One or more ζ records (SHA-256 hash-chained).
Optionally, a row in SQLite (for data mutations like task_create).
Optionally, a Merkle leaf (for proof-grade work).

Phase 0 Mutations: The 19 Tools

Phase 0 implements exactly 19 tools, grouped into four families:

8 β Task tools (task pipeline): task_create, task_list, task_next_actions, task_update, task_apply, task_block, task_unblock, task_plan
6 ζη Audit + Proof tools: thought_record, audit_session_start, audit_verify_chain, merkle_attest, merkle_finalize, merkle_root
1 ε Skill tool: skill_list
4 System tools: server_ping, unified_init, unified_vitals, unified_set_project

Each tool is a mutation. Each mutation either creates or modifies SQLite state, or records a proof-grade observation. There are no side effects outside the α→ζ→η→SQLite loop.

Next: How Mutations Happen

See lifecycle.md for a complete walkthrough of a single mutation (task_create) from client request to final ζ record. See where-truth-lives.md for how the database and the four-surface topology preserve the integrity of the mutation log.