CDF Quick Start – From Context to Practice

“CDF 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:

• HCS (Human Cooperation System) explains cooperation stability and breakdowns at a universal level.
• 3SF (3-in-3 SDLC Framework) runs software delivery commitments across Client–Vendor–Product coherence.

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.

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