Glossary¶
This glossary defines key CDS terms and common acronyms used across the documentation. Definitions are intentionally practical and optimized for consistent usage.
Acronyms¶
CDS — Commitment Design System
A system model for discovering meaning, refining intent, and formalizing commitments.
HCS — Human Cooperation System
A system model for designing, sustaining, and diagnosing human cooperation in complex work.
3SF — 3-in-3 SDLC Framework
A meta-framework for software delivery that maintains coherence across the Client–Vendor–Product triangle and the Engagement–Delivery–Value lines.
JTBD — Jobs To Be Done
A lens for expressing needs as desired progress in a context, including obstacles and success criteria.
DDD — Domain-Driven Design
An approach to designing software around domain language, boundaries, and models, emphasizing shared understanding and explicit context boundaries.
RFI — Request for Information
A pre-procurement request used to gather information from vendors/providers to shape options and assess fit.
RFP — Request for Proposal
A procurement request asking vendors/providers to propose a solution, scope, pricing, and approach against stated needs and constraints.
SoW — Statement of Work
A formal document defining deliverables, scope boundaries, responsibilities, and commercial terms for a commitment.
NFR — Non-Functional Requirement
A requirement describing quality attributes and constraints (e.g., reliability, security, performance), not feature behavior.
SLO / SLA — Service Level Objective / Service Level Agreement
Targets (SLOs) and contractual commitments (SLAs) for service performance and reliability.
RBAC — Role-Based Access Control
A mechanism for managing system access based on roles and permissions.
Core CDS Concepts¶
Meaning
Shared understanding of the situation: conditions, needs, frictions, stakes, evidence, and uncertainty. Meaning is not solutions.
Meaning Discovery
The CDS step that discovers and aligns meaning without jumping to solutions. Output: Meaning Handshake.
Meaning Handshake
The canonical CDS artifact that captures meaning in an inspectable form so intent refinement starts from shared reality.
Intent
Decision-grade clarity about what should change and under what rules: outcomes, success signals, boundaries, constraints, tradeoffs, assumptions, decision rights, and revisit triggers.
Intent Refinement
The CDS step that turns meaning into decision-grade intent. Output: Intent Package.
Intent Package
The canonical CDS artifact that captures refined intent in a commitment-ready form.
Commitment
A binding agreement to pursue an intent under stated rules: ownership, governance, change protocol, acceptance evidence, and revisit triggers.
Commitment Formalization
The CDS step that freezes intent into an accountable commitment. Output: Commitment Envelope.
Commitment Envelope
The canonical CDS artifact that defines the commitment object and serves as the handoff contract into an execution runtime.
Quality, Change, and Governance¶
Decision-grade
Clear enough that reasonable people can commit, disagree, or trade off explicitly. Not perfect certainty—sufficient clarity.
Decision rights
Explicit authority to decide specific categories of decisions (scope, tradeoffs, constraints, acceptance, change).
Governance cadence
A recurring forum and rhythm for reviewing signals, risks, dependencies, and making/recording decisions.
Change protocol
The defined mechanism for proposing, evaluating, approving, and recording changes to a commitment (including an urgent path).
Revisit trigger
A defined signal or event that forces re-entry into Meaning Discovery or Intent Refinement rather than silently drifting.
Expiry / renewal
A defined point where a commitment must be re-confirmed, renewed, or replaced.
Common CDS Quality Terms¶
Must / Should / Smell
CDS check types: “Must” blocks progress if missing; “Should” is recommended; “Smell” is a warning signal requiring investigation.
Inspectable
Structured so future teams can reconstruct why a decision or commitment was reasonable at the time (conditions, tradeoffs, decision rights, evidence).
Tradeoff
A consciously accepted sacrifice made to commit under constraints (e.g., speed over completeness, cost over performance).
Constraint
A non-negotiable rule that shapes what is acceptable (e.g., security policies, data residency, budget ceiling). Distinct from a preference.
Evidence
Signals and artifacts used to evaluate whether a commitment is producing value (distinct from shipping deliverables).
Software Delivery Profile Terms¶
Software Delivery Profile
A CDS extension that adds software-specific fields and checks so commitments are executable in real delivery environments.
Quality attributes
Operational and technical properties that define “acceptable” beyond features (reliability, security, performance, observability, operability).
Reversibility
How costly it is to undo a decision or change. Often categorized as easy, costly, or effectively irreversible.
Feasibility probe
A timeboxed learning action (spike/prototype/validation) designed to reduce a major unknown and unlock a decision.
Dependency obligation
An explicit commitment from a party or team to provide something required for delivery (access, environment readiness, approvals).
Operational posture
Agreed expectations for running and supporting the delivered system: support model, monitoring, runbooks, incident response posture.
3SF Mapping Terms¶
Client–Vendor–Product triangle
A 3SF coherence model describing the three parties that must remain aligned for delivery to succeed.
Engagement–Delivery–Value lines
A 3SF coherence model describing the three contracts that must remain stable during execution: relationship mechanics (Engagement), execution integrity (Delivery), and value validation (Value).
Runtime
The execution system that runs a commitment (methods, governance, teams, tools). CDS produces the commitment; the runtime executes it.