Declaring an application
The practice ends here. How a system actually runs it — the trackers, the pipelines, the templates, the agents, and everything the practice deliberately leaves open — is declared by each application, and is not the practice's to state.
What a system must declare
| Declaration | Without it |
|---|---|
| Personas — the parties the running system serves | Not one capability can be stated |
| Disciplines — the parties that act on the change | Roles in the track have no party above them |
| Standards — the floors it holds itself to | There is nothing for a Verifier to check against |
| Subtypes — whatever work types its tooling and people actually use | The tracker's vocabulary and the practice's cannot be reconciled |
Specifying the personas and the disciplines is a required act of applying the practice to a system. The practice supplies only the tests that sort them: does the running system serve them? and does the party act on the change?
What else an application settles
The practice names no tool, so everything below belongs to the application rather than to it:
- Which tracker is the door, and how it carries an item's type, state and commitment
- What a commitment names — a release, a version, a date
- What calls an item to action — an assignee, a label, a column, a notification
- How a persona is given something real to validate — a preview, a staged environment, a limited release
- Whether capture carries a quality bar, and what it is
An application may add or constrain, never contradict. A narrower layer contradicting a wider one is a defect in the application, not a variant of the practice.