Disciplines
A party that acts on the change. The counterpart to the persona, and the source of every actor that takes a role in the track.
A discipline is a type, never a business title and never an individual — which is what lets it survive people rotating, changing hats, or leaving. Who supplies the actor is a deployment detail, so a discipline may be filled from outside the organisation entirely and nothing about the role changes.
| Discipline | Acts on the change by |
|---|---|
| Product | Deciding what should exist, and why |
| Design | Shaping how it is experienced |
| Development | Building it |
| Technical | Setting the technical direction it must fit |
| Delivery | Sequencing it, releasing it, getting it into hands |
These are examples. The practice names no disciplines. Specifying the actual set is a required act of applying the practice to a system — until it exists, roles in the track have no party above them. The practice supplies only the test: does the party act on the change?
Disciplines exist to guarantee the questions get asked, not to guarantee different people ask them. Naming them is what makes was the technical voice heard before we committed? a question with an answer, at any size of team. One actor may cover several disciplines; each still has to be genuinely consulted rather than assumed.
Discipline and role are different questions. A discipline says which party you are acting as; a role says what position you hold on this subject. The same developer is a discipline supplying an actor, and that actor may hold Worker on one item and Verifier on another. Neither answer constrains the other.
The same word can land on either branch. A developer building the system is a discipline; a developer consuming what it publishes is a persona. Nothing about the person changed — the object did, and that is the only test there is.
Where a bare name could be read as either, it is not precise enough. Qualify it until it can only be one — Development and Consuming developer, never Developer twice.