Working vocabulary

These short definitions summarize how the book uses its terms. The linked chapters provide the examples and qualifications. They are aids to discussion, not a universal terminology standard.

Acceptance. A decision that the stated outcome has been supported by the agreed evidence within a defined scope. It is distinct from finishing code, passing a test, or merging a branch. See chapter 27.

Agent interface. The operations, discovery paths, descriptions, feedback, and observable environment through which an agent uses a system. It includes errors and recovery, not only schemas. See chapter 12.

Authority. The right to make a decision or perform an action within a specified scope. Possessing information or a technical capability does not automatically grant it. See chapter 15.

Boundary. A set of promises separating responsibilities. A useful boundary exposes the distinctions callers need and contains incidental implementation choices. See chapter 9.

Candidate. In the running example, locally present material that has not yet met the conditions for publication as ready. See chapter 6.

Capability. A behavior a component can provide under stated conditions. A version label may be evidence about capability but is not identical to it. See chapter 9.

Characterization test. An experiment or test used to establish current behavior, often before changing unfamiliar code. It may reveal what exists without deciding whether that behavior is desirable. See chapter 3.

Contract. The obligations and permitted expectations between a component and its callers, including success, failure, identity, lifetime, and recovery where relevant. See chapter 9.

Decision record. A compact account of a consequential choice, its context, alternatives, status, and consequences. Its purpose is to preserve useful rationale rather than reproduce the entire discussion. See chapter 5.

Deterministic control. Enforcement whose result follows defined rules for the relevant input and state. It guarantees only the properties those rules actually check. See chapter 15.

Discovery. The conversational and investigative work of establishing what should be built and why, including uncertainty that may require a prototype or later revision. See chapter 2.

Domain model. A representation of concepts, identity, relationships, and rules needed to explain the problem's behavior. It need not map one-to-one to classes or services. See chapter 6.

Evidence boundary. The limit on what an observation supports: a revision, environment, path, population, or fault class, for example. See chapter 27.

Higher-order conflict. An incompatibility that can survive a clean text merge, such as disjoint changes violating the same semantic assumption or causing an integration failure. See chapter 20.

Hypothesis. A proposition being considered or tested, rather than an established fact or binding requirement. See chapter 2.

Identity. What allows a system to refer to the same thing across relevant changes. Resource identity, attempt identity, and artifact identity can have different lifetimes. See chapter 6.

Independent review. A procedure that gives a reviewer a separate opportunity to challenge a change. Separate roles do not guarantee statistically independent mistakes. See chapter 24.

Intent. The purpose and desired consequences motivating a request. It may require interpretation and can develop through investigation and use. See chapter 1.

Intent-oriented operation. An interface operation that requests a domain outcome while its owner handles incidental choreography, preserving consequential caller choices. See chapter 13.

Invariant. A condition that must remain true across the relevant states and transitions of a system. Its scope and owner must be clear. See chapter 7.

Lifecycle. The meaningful states and transitions of an activity or resource, including the obligations that remain after a caller stops waiting. See chapter 7.

Material uncertainty. An unresolved question that can change intended behavior, design, scope, or acceptance. It is not measured by patch size alone. See chapter 2.

Operational responsibility. The obligation to complete, clean up, or reconcile work. It can outlive the caller and differs from permission to initiate the work. See chapter 7.

Outcome. The behavior or capability that should become possible for the intended person or consumer. An implementation step is not necessarily an outcome. See chapter 1.

Proportionality. Matching investigation, abstraction, coordination, and evidence effort to the decisions and consequences at stake. It supports both adding and removing process. See chapter 31.

Provenance. Attributable relationships connecting artifacts, activities, actors, and sources. It helps reconstruction but does not by itself prove correctness, completeness, or causal explanation. See chapter 16.

Publication. In the running example, the transition that makes a candidate available through the consumer's agreed ready reference. It is distinct from completing transfer. See chapter 13.

Readiness. The bounded promise that the resource satisfies the conditions required for the intended next use. Its meaning must be defined by the contract. See chapter 7.

Refactoring. A change intended to improve internal structure while preserving required behavior. In practice, mixed changes require care when attributing benefits or defects. See chapter 10.

Revision guard. A check that a proposal applies to the state or version against which it was prepared. Passing it does not prove the proposal serves the intended outcome. See chapter 15.

Running example. The explicitly illustrative resource-acquisition system developed through this book. It is not a reconstruction of any one implementation. See chapter 1.

Shared foundation. A layer whose responsibility serves demonstrated common needs across consumers, while preserving application-specific meaning where appropriate. See chapter 28.

Test oracle. The basis used to judge whether an observed result is correct. An oracle can encode the same mistaken assumption as the implementation. See chapter 23.

Uncertain outcome. A situation in which the observer cannot yet establish whether an operation's side effect occurred. It requires reconciliation or defined retry semantics, not an invented success or failure. See chapter 25.

Vertical slice. An end-to-end increment that lets a person or consumer achieve a bounded useful result through the necessary layers. See chapter 29.