Skip to main content

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

Party

Consequence 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

Act

Doing 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

Party

A 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

Structure

One 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.

See also Practice and application, Declaring an application

Capability

Work type

An 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

Act

Recording 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 type

Upkeep 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

Property

A 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

Record

To 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

Output

One 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

Act

Authorising 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

Party

A 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 type

Correcting 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 type

A 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

Role

The 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

Party

A 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

Act

Writing 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

Structure

The 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

Act

Making 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 type

A 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

Item

Whatever 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

Party

An 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

Act

Ruling 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

Output

An 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

Act

Writing 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

Constraint

A 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

Structure

The 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

Property

What 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

Act

Judging 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

Act

Judging 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

Item

The 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