Intent Refinement¶

Intent Refinement is the second step of the Commitment Design System (CDS). Its purpose is to turn meaning into decision-grade intent — intent that is clear enough to commit to, and robust enough to guide execution without constant re-interpretation.

Intent Refinement does not finalize delivery plans. It refines what must be achieved and under what rules, so a commitment can be formalized responsibly.

Purpose¶

Intent Refinement exists to:

Translate Meaning Handshake inputs into a coherent intent statement.
Define outcomes and success signals (what “better” means).
Set boundaries (what is in, out, and uncertain).
Make constraints and tradeoffs explicit and owned.
Identify assumptions and unknowns that affect viability.
Define decision rights and evidence expectations.
Produce an intent package that can be formalized into a commitment.

Boundaries¶

Intent Refinement is complete when the group can say:

“We can state the intended outcome without describing a solution.”
“We know how we will recognize success.”
“We agree on the boundaries and constraints.”
“We have named the tradeoffs we are accepting.”
“We know what we still don’t know — and how we will reduce that uncertainty.”
“We know who decides if reality changes.”

Intent Refinement is not complete when:

The intent is still a feature list or implementation proposal.
Success is described vaguely (“improve”, “optimize”, “modernize”) without signals.
Constraints are discovered late (“security will review later”).
Decision ownership is missing (“we’ll align later”).

Core outputs¶

Intent Refinement produces the Intent Package artifact. It is the canonical output schema for decision-grade intent in CDS.

The Intent Package is designed to be:

testable (via signals and evidence)
bounded (via constraints and scope edges)
inspectable (via explicit tradeoffs and assumptions)
commit-ready (via decision rights and revisit triggers)

Process¶

Intent Refinement can be run in one session or several. Regardless of format, it follows the same substages.

Step 1: State the outcome (as a change)¶

Convert meaning into an outcome statement:

For whom will the situation improve?
What will be different when this succeeds?
What will people be able to do that they cannot do today?

Avoid solution verbs (“build”, “implement”, “migrate”) in the first pass. Use change verbs (“reduce”, “enable”, “prevent”, “increase”, “make predictable”).

Step 2: Define success signals¶

Specify how success will be recognized:

What measurable signals should move?
What qualitative evidence will count?
What would indicate “no improvement” or “worse”?

Separate:

leading signals (early indicators)
lagging signals (outcome confirmation)

Step 3: Set scope boundaries¶

Make the boundaries explicit:

What is in scope?
What is out of scope?
What is unknown / to be discovered?
What dependencies could reshape scope?

Step 4: Declare constraints¶

Turn implicit constraints into explicit rules:

must / must-not constraints (compliance, security, privacy, brand, budget)
non-negotiables vs preferences
constraints that apply now vs later

Step 5: Surface and own tradeoffs¶

Every intent implies tradeoffs. Make them visible:

What are we optimizing for?
What are we sacrificing?
Who is accepting the sacrifice?
What risk are we consciously taking on?

Step 6: Make assumptions and unknowns explicit¶

List:

assumptions that must be true for success
disputed assumptions (where meaning differs)
unknowns that could invalidate the intent

This is where intent becomes inspectable later.

Step 7: Define a learning plan (when uncertainty is material)¶

Translate uncertainty into learning moves:

What is the smallest learning action that reduces risk?
What decision will that learning enable?
What is the timebox for learning before committing further?

Examples:

prototype, spike, experiment, user test, technical validation

Step 8: Define decision rights and revisit triggers¶

Clarify:

who decides acceptance of tradeoffs
who can approve changes to intent
what triggers a revisit (signals, events, constraint changes)
what happens when a revisit trigger is hit

Intent Package artifact¶

A minimal Intent Package includes:

Outcome statement
Success signals & evidence
Scope boundaries (in / out / unknown)
Constraints
Tradeoffs accepted
Assumptions & unknowns
Learning plan (if needed)
Decision rights
Revisit triggers

This artifact is intentionally not a delivery plan. It is the “commitment-ready” shape of intent.

Core quality checks¶

Use these checks before moving to Commitment Formalization.

Outcome quality checks¶

Outcome is expressed as a change in the world, not a solution.
Outcome is specific enough that people can disagree meaningfully.

Signal quality checks¶

Success signals exist beyond “we shipped it.”
At least one signal can be observed within the commitment horizon.

Boundary quality checks¶

In/out boundaries are explicit.
Unknowns are labeled as unknowns (not buried).

Constraint quality checks¶

Non-negotiables are explicit and not contradictory.
Constraints have owners (who enforces/validates them).

Tradeoff quality checks¶

At least one explicit sacrifice is named.
The tradeoff owner is identifiable.

Assumption quality checks¶

Key assumptions are written down.
There is a way to disconfirm them (even if not yet executed).

Decision quality checks¶

Decision rights are explicit.
Revisit triggers exist and are plausible.

Common failure patterns¶

Solution-shaped intent: outcome is replaced by a preferred implementation.
Vague outcomes: “improve” with no signals or boundaries.
Constraint denial: constraints treated as “later problems”.
Tradeoff amnesia: sacrifices are implicit until conflict erupts.
Unknowns disguised as certainty: assumptions presented as facts.
Decision fog: nobody can approve changes when reality shifts.

Transition to Commitment Formalization¶

Intent Refinement hands off via the Intent Package. The next step, Commitment Formalization, freezes refined intent into an accountable commitment: roles, governance, change protocol, evidence expectations, and revisit triggers — ready for execution.