Skip to content

CDS Quick Start – From Context to Practice

“CDS is not another delivery method — it’s the commitment layer that makes methods work.”

⚠️ ATTENTION: You may be viewing a downloaded version.
The living, latest version of this documentation is always available online: CDS Official Documentation

A commitment-design system for turning meaning into decision-grade intent and formal commitments — without drifting into delivery theater.

⏱️ 30-Second Summary
The Commitment Design System (CDS) defines a simple lifecycle:
Meaning Discovery → Intent Refinement → Commitment Formalization.
It produces three canonical artifacts — Meaning Handshake, Intent Package, Commitment Envelope — plus quality checks and re-entry rules that prevent teams from “starting work” without a real commitment.

What Is CDS

CDS is a commitment formation system.

Where most frameworks focus on how teams execute work, CDS focuses on the step before execution becomes expensive:
making sure the commitment is real, inspectable, and governable.

CDS exists because many failures attributed to delivery (Agile, Scrum, “bad requirements”, “slow engineering”) are actually upstream commitment problems:

  • meaning was never aligned
  • intent was never decision-grade
  • commitment was never formalized (accountability, change protocol, acceptance evidence)

CDS replaces “just start and iterate” with a more disciplined stance:

  • Discover meaning
  • Refine intent
  • Formalize commitment
  • then run delivery with fewer surprises and less escalation

Where CDS sits in the 3in3.dev stack

CDS is designed to connect two layers:

CDS sits between them as the commitment-design layer:

  • narrower than HCS (focused on a specific commitment)
  • upstream of 3SF (prepares a commitment that delivery can actually run)

Who It’s For

CDS is designed for practitioners who routinely translate between:

  • business meaning ↔ product intent ↔ delivery commitments
  • multiple stakeholders with different stakes and language
  • uncertainty that cannot be “estimated away”

Typical roles:

  • Product leaders and product-facing discovery practitioners
  • Project / delivery leads (internal or vendor-side)
  • Business analysts and solutioning practitioners (RFI/RFP)
  • Engineering leaders who keep inheriting ambiguous commitments

What CDS Is — and What It Is Not

What CDS Is

CDS is a system model and artifact discipline for:

  • discovering and aligning meaning
  • shaping decision-grade intent
  • formalizing commitments that can be governed and inspected over time

It is designed to prevent drift and escalation by making:

  • tradeoffs explicit
  • decision rights explicit
  • change routable
  • acceptance evidence explicit

What CDS Is Not

CDS is not:

  • ❌ a delivery methodology (Scrum/Kanban replacement)
  • ❌ a requirements format or ticketing standard
  • ❌ a strategy framework
  • ❌ a tool stack recommendation
  • ❌ a substitute for leadership or decision-making

CDS ends when the Commitment Envelope is formalized.
Execution belongs to a runtime (e.g., 3SF, Agile/Kanban, or your org’s delivery system).

The CDS Core Model (Meaning → Intent → Commitment)

CDS is intentionally simple:

  • Meaning Discovery
    Align on conditions, needs, frictions, stakes, evidence, and uncertainty.
    Output: Meaning Handshake.

  • Intent Refinement
    Convert meaning into decision-grade intent: outcomes, signals, boundaries, constraints, tradeoffs, assumptions, decision rights.
    Output: Intent Package.

  • Commitment Formalization
    Freeze intent into a governable commitment: accountability, governance cadence, change protocol, acceptance evidence, revisit triggers.
    Output: Commitment Envelope.

CDS User Onboarding Checklist

Start here before you apply any delivery method.

Step Action Why This Step Is Necessary
1. Orient Read Vision, Principles, and Beliefs. Aligns stance: CDS is a commitment system, not a method war.
2. Choose profile Start with Core Model, then apply Software Delivery Profile only if your runtime is delivery. Keeps CDS universal, profiles additive.
3. Discover meaning Produce a Meaning Handshake. Prevents solution-first commitments.
4. Refine intent Produce an Intent Package. Makes intent decision-grade: signals, boundaries, constraints, tradeoffs.
5. Formalize commitment Produce a Commitment Envelope. Makes commitment executable and governable.
6. Run quality checks Use Core Quality Checks (Must / Should / Smells + re-entry rules). Prevents “progress by assumption.”
7. Hand off to runtime Hand the Commitment Envelope into your runtime (e.g., 3SF). CDS prepares the input contract; runtime executes.

How to Navigate CDS

CDS documentation is structured for fast, non-linear use:

Section Purpose
Core Model The universal Meaning → Intent → Commitment lifecycle, artifacts, and quality checks.
Software Delivery Profile Adds delivery-grade fields and gates; maps Commitment Envelope into 3SF-style runtime coherence.
Reference Glossary, schemas, sources, practices map, versioning/licensing.

Where to Start

  • Vision, Principles, and Beliefs
    The stance and purpose of CDS.

  • Core Model
    The overview page that links Meaning Discovery → Intent Refinement → Commitment Formalization.

  • Software Delivery Profile (if applicable)
    Start with the overview, then use the mapping and stage extensions.

When You’re Ready

If you want to apply CDS immediately, start with:

  • Meaning Handshake (template)
  • Intent Package (template)
  • Commitment Envelope (template)

Then use Core Quality Checks to decide whether you can progress — or should re-enter an earlier stage.

CDS begins with meaning, not method. Make the commitment real — then choose how to run it.