Core Quality Checks

This page defines the core quality checks of the Commitment Design System (CDS). These checks provide simple, repeatable criteria for deciding whether CDS can safely progress from:

Meaning Discovery → Intent Refinement → Commitment Formalization

They also define when CDS should re-enter an earlier step instead of pushing forward with ambiguity.

How to use these checks

Use these checks as:

• Stage exit criteria (before moving to the next step)
• Ongoing drift detectors (during longer engagements)
• Re-entry triggers (when reality changes or new information appears)

The checks are intentionally lightweight. They aim to prevent premature commitment, not to enforce bureaucracy.

Check types

CDS uses three types of checks:

• Must — required for moving forward. If missing, CDS should not progress.
• Should — strongly recommended. If missing, progress is possible but risky.
• Smells — warning signals. If present, pause and investigate.

Meaning Discovery quality checks

Must

• Conditions are explicit: key constraints and context are written down and not mutually surprising.
• Needs are stated as needs: “must be true” statements, not solution proposals.
• Frictions are causal: the team can explain how frictions prevent needs from being met.
• Stakes are visible: at least the primary affected groups and their stakes are identified.
• Unknowns are declared: assumptions and unknowns are captured rather than embedded.

Should

• Evidence exists: at least one concrete signal supports the framing (qualitative or quantitative).
• Tensions are named: incompatible needs (speed vs safety, autonomy vs alignment, etc.) are explicit.
• Language is aligned: obvious semantic conflicts are identified (even if not resolved yet).

Smells

• Solution debate dominates and meaning cannot be summarized without feature talk.
• One perspective defines meaning “for everyone”.
• “We all agree” appears, but stakeholders are absent or evidence is missing.
• The “problem” is actually a label for a preferred project (“modernize”, “replatform”, “AI”).

Intent Refinement quality checks

Must

• Outcome is stated as change: what will be different if successful (without prescribing implementation).
• Success signals exist: at least one observable signal beyond “we shipped it”, and:
  • at least one signal is falsifiable (it could show “no improvement” or “worse”)
  • at least one signal/evidence source is independently observable by the acceptance owner (not solely produced/curated by a single party)
• Boundaries are explicit: in-scope, out-of-scope, and unknown areas are identified.
• Constraints are explicit: true non-negotiables are stated, with an owner where relevant.
• Tradeoffs are owned: at least one explicit sacrifice is named, and someone accepts it.
• Decision rights exist: someone can approve changes and resolve conflicts.
• Decision rights are operational: deciders are named individuals (not just roles), are empowered in practice, and can reliably exercise the decision (attend the decision forum or have a standing delegate).
  If decision rights are expected to rotate, continuity rules are defined and role-change triggers re-formalization.
• Revisit triggers exist: clear conditions that force re-evaluation are stated.

Should

• Assumptions have disconfirmation paths: the team knows how key assumptions could be proven false.
• Learning plan exists when uncertainty is material: a small plan to reduce uncertainty is defined.
• Stakeholder acceptance is understood: who will accept value/evidence is identified.

Smells

• Intent is still a feature list or a solution mandate.
• “Improve/optimize/modernize” with no boundary or signal.
• Constraints are deferred to later (“security will review at the end”).
• Tradeoffs are denied (“we can have all of it”).
• Decision rights are ambiguous (“we’ll align later”).

Commitment Formalization quality checks

Must

• Parties and accountability are explicit: who commits and who is accountable for what.
• Commitment statement is clear: outcome + boundary + horizon/checkpoints + quality bar.
• Deliverables and evidence are separated: what is produced vs how value is evaluated.
• Governance cadence exists: a forum/cadence for reviewing progress, signals, and risks.
• Change protocol exists: what counts as change, how it is proposed, who decides, what happens next.
• Risk posture is stated: key risks and escalation paths are identified.
• Revisit/expiry is defined: what triggers re-entry, and when commitment is renewed or re-confirmed.

Should

• Acceptance is operationalized: acceptance owner, acceptance method, and evidence format are clear.
• Dependency obligations are stated: external dependencies have named owners and expectations.
• Decision recording exists: decisions and changes are captured in a lightweight log.

Smells

• “Everyone is accountable” (which means no one is).
• Acceptance is “we delivered it” rather than evidence of value.
• Change control is escalation-by-default.
• Governance meetings exist, but decisions are not recorded.
• The commitment relies on implied shared understanding instead of explicit envelope fields.

Re-entry rules

Re-entry is not failure. It is the normal behavior of CDS under uncertainty.

Use these rules:

Re-enter Meaning Discovery when

• stakeholder stakes were misunderstood or newly revealed
• constraints changed materially (regulatory, org, budget, deadline, trust climate)
• disagreement shows meaning was not aligned
• the problem framing no longer fits observed reality

Re-enter Intent Refinement when

• success signals are disputed or no longer measurable
• scope boundaries shift materially
• new constraints appear
• tradeoffs become unacceptable
• assumptions are disproven
• decision rights change

Re-enter Commitment Formalization when

• governance or change protocol is not working in practice
• accountability changes (new sponsor/decider)
• commitments must be renegotiated due to material changes
• commitment expiry/renewal is reached

Minimum viable CDS (v0)

For low-stakes work, CDS can be run with a minimal set:

• Meaning Handshake (v0): situation, top conditions, top needs, top frictions, key stakeholders, unknowns
• Intent Package (v0): outcome, one success signal, boundary, one constraint, one tradeoff, decision right
• Commitment Envelope (v0): accountable owner, commitment statement, acceptance evidence, change protocol

Use v0 only when commitments are reversible and risk is low.

Outcome of “failing” a check

When a Must check fails, the correct action is:

• pause
• name what is missing
• choose re-entry
• reduce uncertainty
• then proceed

CDS is designed to prevent teams from “progressing” by silently converting ambiguity into downstream rework.