Terminology
Every word the practice reserves, and the page that owns it. An entry here is short by rule: a lead clause, a sentence or two, and a pointer. The long treatment lives on the page named beside it, never in the glossary.
A word not listed here is not reserved, and carries its ordinary meaning.
31 terms
Accountability
PartyConsequence landing on a human. Distinct from attribution, which says only what acted. Where an agent holds a role, accountability is derivative — it attaches to the human who delegated.
See also Accountability
Action
ActDoing the work. A Worker act, like the sift, the specifying and the plan before it — what differs is only what it leaves behind: the change itself, and a result for every criterion that was set. Every criterion is driven, not assumed.
See also Action
Actor
PartyA human or an agent — the thing that actually holds a role. Every actor must be distinctly identifiable. Identity is not bureaucracy; it is what makes accountability traceable.
See also Actors
Application
StructureOne technology-specific instantiation of the practice — the trackers, pipelines, templates and agents through which a system actually runs it. An application is replaceable; changing tracker, language or pipeline leaves the practice untouched.
Capability
Work typeAn outcome a named persona can achieve. Stated as the outcome — "a support agent can reissue an invoice" — never as the thing built. The only work type that adds to what the system can be said to do, and it is generated from a passing specification, never written by hand.
See also Capability
Capture
ActRecording a request at the door. Capture does nothing else: it does not type the request, judge it, or agree to it. It is open to any party and carries no quality bar by default.
See also Capture
Chore
Work typeUpkeep of the system and its supporting machinery that changes no capability — documentation, build scripts, tooling, dependency updates. It may still affect the release; the type says why the work exists, not how much rigour it carries.
See also Chore
Commitment
PropertyA promise that the work will be delivered by a named point. Made by a Decider, who is answerable for it. A property of the work, not a state of it — the two axes move independently.
See also Commitment
Concession
RecordTo concede is to state that a standard has not been met, name who accepted that, and proceed anyway. The record is attributable, scoped, expiring and counted. A concession is not an exception to the practice — it is the practice working.
See also Concessions
Criterion
OutputOne statement of what would make the work right, written at Specify before anything is built. A step, a measure or a marker — whatever can be driven and shown to hold. Every item has criteria.
See also Specify
Delegation
ActAuthorising a given actor to hold a given role, for a given scope. It is recorded, because it is where accountability lands. Bounded by a ceiling — nobody delegates a role they do not hold — and by least privilege.
See also Accountability
Discipline
PartyA party that acts on the change (e.g. product, design, development, technical, delivery). The counterpart to persona, which is a party the running system serves. A type, never a business title.
See also Disciplines
Fix
Work typeCorrecting something previously completed. Attaches to an existing capability; never creates one. If you cannot name the capability it attaches to, it is not a fix.
See also Fix
Initiative
Work typeA body of intent spanning capabilities and time. The only type that contains other work, and the only one never worked directly. Containment is exclusive at every level, so the result is a tree.
See also Initiative
Permission
RoleThe entitlement to do something to the system — to merge, to release, to alter a contract, to accept a concession. A permission attaches to the role, never to the actor, which is what makes two actors in the same role interchangeable.
See also Roles
Persona
PartyA party the running system serves (e.g. customer, administrator, operator, support agent, auditor, consuming developer). Defined once, system-wide. Not a job title; one human may be several.
See also Personas
Plan
ActWriting the actions, in order. A Worker act answering one question — how will it be actioned? — and declaring what the change touches. A plan is a route, not a promise; revising it is not failure.
See also Plan
Practice
StructureThe interface — what must hold, who may act, and how work travels. Normative and technology-agnostic: it names no tool, and nothing in it may depend on a capability only one tool happens to have. The practice is durable.
See also Practice and application
Publish
ActMaking the result available, and confirming it arrived. The confirmation is done by looking — a report that something shipped carries no evidence, so the practice does not accept one. Complete is the state that follows.
See also Publish
Question
Work typeA request for information. It produces an answer, not a change. How it resolves is diagnostic: the answer was findable, lived only in someone's head, or did not exist. Answers routinely produce further work.
See also Question
Request
ItemWhatever arrives at the door. A request has been recorded and nothing more: no type, no agreement that it will be done, no promise to anyone. At the sift it is typed and ruled on.
See also Capture
Role
PartyAn interface — Worker, Verifier, Sentinel, Decider — of which the actor is the implementation. There are four, and the practice fixes them. Eligibility turns on access, not on actor kind.
See also Roles
Sift
ActRuling on a request — the first act on the change, and the first that requires a role. Two things settle and no more: what type the request carries, and whether it will be done at all.
See also Sift
Specification
OutputAn executable statement of what the system should do. The only thing that can prove a capability. It states intent, so it can never be recovered from the implementation — which says only what the system does.
See also Specify
Specify
ActWriting what would make the work right, before anything is built. A Worker act producing specifications that fail — one that has never failed has never demonstrated that it tests anything.
See also Specify
Standard
ConstraintA statement of what must hold, expressed as a floor. A standard states how its own conformance is determined. Standards stack by union: a layer may add or constrain, never contradict.
See also Standards
System
StructureThe thing being built, and the boundary the practice is declared within. A system names the personas it serves, declares the standards it holds itself to, and is where all work lands. Not a repository, a codebase or a deployment.
See also Overview
Touch
PropertyWhat a change reaches — the parts of the system it alters, and whatever depends on them. Declared by the plan. Touch decides what a change must satisfy, and it is derived from the change itself, never judged.
See also Plan
Validate
ActJudging the outcome against what was actually needed. Verification asks whether the work matches what was asked; validation asks whether what was asked was right — and it is the only check able to find that a criterion was missing altogether.
See also Validate
Verify
ActJudging work against what was asked of it. A Verifier act, held by someone who did not do the work, at the exit of every act that produces something. Two outcomes only: it verifies, or it returns the work.
See also The process
Work
ItemThe collective term for anything the practice acts on. All work carries exactly one type — capability, fix, chore, question or initiative — assigned at the sift. An application may add subtypes of these, never new types alongside them.
See also Work types