Chapter 22

How a Role Becomes a Contract

Chapter 21 put a role on the graph as a Node. But labelling an Agent “handles search” is one thing; pinning down what it must read and what it must not do is another. A name only points at a role. It does not say what the role demands.

1. Mission comes first

Two Agents reading the same repository must behave completely differently if their purposes differ. Development implements and changes contracts. Verification confirms that the change meets what was asked, and changes nothing.

The difference is not a matter of wording the instructions differently. One has the authority to change something; the other must not change anything, only confirm. That distinction has to survive in the graph as a mission, so that later it is possible to trace why an Agent did, or did not, act as it did.

2. Reading order is part of the contract

Having access to a lot of material does not mean it may be read in any order. Some roles have a document to check first, a relation to look at next, and a condition to verify last.

That order is Chapter 21's reads. It is why different roles follow different paths through the same graph, and why reading lists stopped being retyped into prompt headers at every release. Before, the list was prose in a release document, and a document renamed between releases was found by nobody.

3. A gate to pass

Reporting that the work is done does not mean the work is finished. Each role has conditions to pass before moving on: its gates. Pass, and the work goes to the next step; fail, and it stays where it is to be fixed again.

Without this gate, “I did the work” and “the work is actually finished” are indistinguishable. Running the gates belongs to the verify tier, and that tier only reports.

4. Verifiers do not edit, and do not escalate

The most important split among the tiers is execute against verify. The verify tier never edits. That is why it can run on the cheapest model: its mistakes fail out loud. The reverse holds too. Work that can be wrong silently, a missed identifier, a dropped migration row, a line of Korean that reads as translation, goes to the strongest model. What sets the rung is not the size of the task but the cost of a wrong answer.

Escalation follows the tiers. Meet the same ambiguity twice, or see the same check fail twice, and the work moves one rung up. The verify tier does not escalate. It returns the work to its author.

5. Prohibitions are a denylist

never is a property, not prose, and in the execution shell it becomes a list of forbidden tools. It is a denylist, not an allowlist, because an allowlist would strip the MCP calls every role boots with.

And the roster states plainly what that list cannot enforce. Blocking a tool stops the tool from being called; it does not stop “do not widen the scope” or “do not write a decision in a person's name.” Those prohibitions are the reader's contract, and as Chapter 7 §7 said, providing memory and enforcing action are different things.

6. Three verbs keep the contract honest

There is a gap between a role existing in the graph and a runtime acting by it. What the runtime reads is a file, and CI cannot read the graph. Three verbs close the gap.

The graph is the source and the files are derived. The direction matters. Another part of this project once had a discipline saying its token files were generated from the graph, and no generator existed, so in practice the files were edited and copied into the graph. A rule that is physically impossible is not a rule. The generator is what makes the discipline hold, and the check was run once against a hand-edited shell to see it actually fail.

A fourth verb, install, puts the shells where the runtime looks for them. A person runs it after the merge, and running it again changes nothing.

7. A role needs a fence

Open every piece of material to an Agent and the boundary that defined its role stops meaning anything. paths and repos are the paths and repositories it may touch; reads is what it must read. The fence is not only for security. Letting an Agent read unrelated material widens what it has to judge for no reason, and the role itself blurs.

8. The graph is a contract, not a conductor

The graph preserves the role's contract, the runtime actually moves by it, and a person or a check confirms whether the next step may begin. Keeping this split is what lets changing a role's definition and changing the infrastructure that runs it move at different speeds. In the end, having many roles is not the point. What matters is that each role's responsibility, reading order, gates and prohibitions stay in the graph in a form that can be traced again.

Chapter 21 covered what a role exists as. This chapter covered what that existence holds it to. What remains is the relations these roles produce, and the evidence attached to each one.

Continue with Chapter 23, How Evidence Attaches to a Relationship.