Module · M4 · The control layer

Separation of duties: decider ≠ executor

Lesson 12 of 21 · 7 min

No organisation lets the person who approves a refund also issue it. Not because anyone is suspected of anything — because a single point of decision and execution has no place for a mistake to be caught. The agent in lesson 10 was both.

So the flaw is not in the prompt and it is not in the model. It is an organisational design flaw, and it has the same fix in software that it has in a finance team: split the roles, and put the check between them.

The same ticket, the same model, the same policy. The difference is entirely in who is allowed to do what.

Four roles, and the one job each has

Read the third column downwards. Only one row can change anything, and it is the row with no judgement in it.

Role	Its one job	What it may touch	The principle
Proposer	establish the facts and propose a resolution	read tools only	the thing that decides may not act
Reviewer	judge the proposal against policy	nothing at all	the thing that checks must be independent of the thing it checks
Gate	route on the verdict	nothing — it is a condition	a hard rule is a node, never a model’s judgement
Executor	carry out exactly what was approved	the write, and nothing else	the thing that acts may not decide

Proposer

Its one job: establish the facts and propose a resolution
What it may touch: read tools only
The principle: the thing that decides may not act

Reviewer

Its one job: judge the proposal against policy
What it may touch: nothing at all
The principle: the thing that checks must be independent of the thing it checks

Gate

Its one job: route on the verdict
What it may touch: nothing — it is a condition
The principle: a hard rule is a node, never a model’s judgement

Executor

Its one job: carry out exactly what was approved
What it may touch: the write, and nothing else
The principle: the thing that acts may not decide

Why this is structure and not etiquette

It would be possible to build all four roles as instructions to one agent — “first propose, then review your proposal, then check it against the threshold, then execute”. That is the same agent doing all four jobs, and it fails in exactly the way lesson 10 failed: the review is prose, and nothing downstream reads prose.

Separation is real when the roles are different nodes with different tools attached. The proposer cannot issue a refund because no refund tool is wired to it. The reviewer cannot fix the proposal because it has no tools at all. The gate cannot be talked round because it is a comparison.

One honest caveat, and it comes from this build. The proposer’s account tool is configured read-only, and lesson 9 showed what a configuration is worth on its own. Read-only is enforced properly by which node exists — the proposer has no write node attached at all — and only decoratively by an enum on a tool. When you review someone’s control layer, count the tools; do not read the settings.

What the rest of this module builds

L13 — the reviewer, and where the thresholds live.
L14 — making its verdict machine-readable, so the gate is deterministic.
L15 — the human approval gate, before anything irreversible.
L16 — the correction loop, so a rejection improves the proposal instead of ending it.
L17 — the audit row, which turns out to be the node most likely to be broken.