# Who does what

> Three parties do the work in this method: the tooling, the model and me, as the developer.

Page: Methodology · Start
Canonical: https://banes-lab.com/disciplined-methodology#who-does-what

This section is stop 2 of 102 in the learning route. Previous: [01 - The loop](https://banes-lab.com/disciplined-methodology/start/the-loop.md). Next: [03 - The stance](https://banes-lab.com/disciplined-methodology/start/the-stance.md).

Three parties do the work in this method: the tooling, the model and me, as the developer. The tooling detects problems and repairs the ones it can, the model repairs what the tooling leaves, and I decide what the work is for and what finished means. The split is shown in [B1·a three parties](https://banes-lab.com/disciplined-methodology#who-does-what-panel-a), and the parts do not swap. I treat it as the second thing to learn, because every later chapter assumes it, and every failure the method knows turns out to be one party doing another party's job. The architecture page reaches the same three parties from a different starting point, that [the author is probabilistic](https://banes-lab.com/software-architecture/scale/the-author-is-probabilistic.md).

### Three parties, three jobs

When you don't name the roles, you end up doing work a check should do, and the model ends up guessing what you want. You review the code for style, the model reviews it for [correctness](https://banes-lab.com/records/arch/correctness.md), and both of you miss the architectural drift because neither of you owns it. A developer cannot pay attention to every line, and a model cannot tell a rule from a preference unless something outside it enforces the rule.

For this reason I treat quality as a property of the tooling, not of how much attention the developer or the model pays. Detection goes to the tooling and governance stays with the developer, rather than to a review that reads what a check could enforce. In practice, detection is a check that runs the same way every time, with its fixer switched on by default. The findings the fixer cannot close go to the model one at a time, each with its location and the value that was expected. The developer keeps the decisions about what the work is for, and hands nothing else down.

To check this on your own work, read the last ten findings your tooling raised. Each of them should name a check; a finding that a developer had to raise by hand points to a check that does not exist yet.

Detection is mechanical because it has to give the same result on every run. A reviewer who applies a rule from memory applies it differently on a tired day, and a model that applies a rule from a prompt applies it differently once its context fills up. A check, by contrast, is [static analysis](https://banes-lab.com/records/arch/static-analysis.md): it returns the same verdict for the same tree. The chapters [one correct answer](https://banes-lab.com/disciplined-methodology/verify/one-correct-answer.md) and [scale follows determinism](https://banes-lab.com/software-architecture/scale/scale-follows-determinism.md) work out what follows from that. Repairs that have exactly one correct answer belong to the tooling for the same reason: the fixer applies them in the same run that found the fault, without asking the developer or the model.

Repair belongs to the model because a finding is small and specific, and a model handles small, specific tasks well; what a finding contains is described in [detect, log, fix](https://banes-lab.com/disciplined-methodology/build/detect-log-fix.md). The model is not trusted to decide that its own work is finished, because reading an edit is not the same as running the checks, and [it looked right](https://banes-lab.com/disciplined-methodology/verify/it-looked-right.md) covers that failure. Governance stays with the developer because nothing in the method computes whether work is worth doing. What the work is for, what finished looks like and which of two acceptable approaches to take are decisions I make and write down before the work starts. When I correct the model, the correction is meant to become a rule rather than something I remember; a rule that lives only in my head is [manual-only governance](https://banes-lab.com/records/arch/manual-only-governance.md), and it decays.

B1·a three parties

```mermaid
flowchart TB
subgraph tooling["The tooling"]
detect["Detection · every rule, on every change, the same way"]
heal["Healing · what a fixer can restore, it restores"]
end
subgraph ai["The model"]
repair["Repair · what the fixers left, one finding at a time"]
end
subgraph operator["The developer"]
govern["Governance · what the work is for, and what finished means"]
end
detect --> heal
heal -- the findings left --> repair
repair -- a changed tree --> detect
govern -- rules and objectives --> detect
govern -- corrections --> repair
repair -. questions .-> govern
```

## Links to

- [The author is probabilistic](https://banes-lab.com/software-architecture/scale/the-author-is-probabilistic.md)
- [Correctness](https://banes-lab.com/records/arch/correctness.md)
- [Static Analysis](https://banes-lab.com/records/arch/static-analysis.md)
- [One correct answer](https://banes-lab.com/disciplined-methodology/verify/one-correct-answer.md)
- [Scale follows determinism](https://banes-lab.com/software-architecture/scale/scale-follows-determinism.md)
- [Detect, log, fix](https://banes-lab.com/disciplined-methodology/build/detect-log-fix.md)
- [It looked right](https://banes-lab.com/disciplined-methodology/verify/it-looked-right.md)
- [Manual-Only Governance](https://banes-lab.com/records/arch/manual-only-governance.md)

## Linked from

- [The developer and the model](https://banes-lab.com/disciplined-methodology/collaborate/the-human-and-the-ai.md)
- [The author is probabilistic](https://banes-lab.com/software-architecture/scale/the-author-is-probabilistic.md)