Failure Patterns and Recovery Moves¶

This page lists common software delivery failure patterns and the recommended CDS recovery moves. Each pattern includes:

early signals (what you notice first)
typical root cause (which CDS stage was skipped or under-specified)
recovery move (which stage to re-enter and what to produce)

These patterns are intentionally practical. The goal is not blame—it is fast re-alignment.

Pattern: Constraint ambush (security/compliance/data arrives late)¶

Early signals¶

“Security will review later” becomes “Security blocked release”
new requirements appear late (data residency, PII handling, audit evidence)
architecture must change after implementation starts

Typical root cause¶

Meaning Discovery did not capture delivery conditions and gate ownership
Intent Refinement treated constraints as future validation, not intent

Recovery move¶

Re-enter Meaning Discovery (Software Delivery):

capture gate owners and evidence requirements
document data/security constraints as conditions and non-negotiables

Then re-enter Intent Refinement (Software Delivery):

elevate constraints to first-class intent
add feasibility probe (policy fit check, threat posture review)
update tradeoffs and decision rights

Pattern: Dependency paralysis (blocked in indirect teams / ticket queues)¶

Early signals¶

delivery team is idle waiting for access, environments, approvals
“it’s in ServiceNow” becomes the dominant status update
lead times are unknown; no one can escalate effectively

Typical root cause¶

Meaning Discovery missed dependency landscape (owners, lead times, definitions of ready)
commitment did not bind dependency obligations

Recovery move¶

Re-enter Meaning Discovery (Software Delivery):

map dependencies with owner + lead time + definition of ready
identify incentive misalignment and escalation paths

Then re-enter Commitment Formalization (Software Delivery):

formalize dependency obligations and “definition of ready”
add governance cadence item for dependency review
define escalation path when obligations are not met

Pattern: Semantic drift (building the “right thing” with the wrong meaning)¶

Early signals¶

repeated rework due to “misunderstood requirements”
stakeholders approve wording but disagree during demos
business terms are overloaded (“account”, “active”, “done”, “customer”)

Typical root cause¶

Meaning Discovery did not capture domain language and ambiguities
intent was refined as features without semantic alignment

Recovery move¶

Re-enter Meaning Discovery (Software Delivery):

capture key terms, conflicting definitions, and boundary cases
collect examples (real data/events) that illustrate meaning

Then re-enter Intent Refinement:

restate outcomes and boundaries using agreed terms
add acceptance evidence that relies on shared semantics (examples/tests)

Pattern: Feature-only intent (NFRs and operability appear late)¶

Early signals¶

“works on my machine” → production readiness conflict
performance/reliability debates start late in the cycle
operations/support push back near release

Typical root cause¶

Intent Refinement did not include quality attributes as first-class intent
operational stakeholders were absent from meaning

Recovery move¶

Re-enter Meaning Discovery (Software Delivery):

include operational stakes and failure modes (“what must be protected”)

Then re-enter Intent Refinement (Software Delivery):

define NFRs/quality attributes (minimal “must be true” set)
define observability and support posture expectations

Then re-enter Commitment Formalization if acceptance criteria must change.

Pattern: Decision vacuum (no one can say “yes/no”)¶

Early signals¶

work stalls waiting for approval
conflicting stakeholder requests with no resolution mechanism
changes are negotiated via escalation, not decisions

Typical root cause¶

Intent Refinement did not define decision rights
Commitment Formalization did not define governance and change protocol

Recovery move¶

Re-enter Intent Refinement:

name decision rights per category (scope, tradeoffs, constraints, acceptance)

Then re-enter Commitment Formalization:

define decision forum, cadence, and decision recording
define change protocol with a routable path

Pattern: Value drift (deliverables ship, outcomes remain unclear)¶

Early signals¶

demos feel “busy” but impact is unknown
“done” means shipped, not improved outcomes
stakeholders argue about whether it’s working

Typical root cause¶

Intent Refinement did not define success signals and evidence expectations
commitment treats deliverables as value

Recovery move¶

Re-enter Intent Refinement:

define success signals (leading/lagging)
define evidence review cadence and acceptance owner

Then re-enter Commitment Formalization:

formalize acceptance evidence and what happens if evidence is inconclusive

Pattern: Scope thrash (constant change without control)¶

Early signals¶

backlog churn dominates planning
“just one more thing” becomes the default mode
delivery feels chaotic; estimates collapse

Typical root cause¶

boundaries and tradeoffs were not explicit in intent
change protocol was missing or unused

Recovery move¶

Re-enter Intent Refinement:

restate boundaries (in/out/unknown)
name explicit tradeoffs and what is being sacrificed

Then re-enter Commitment Formalization:

formalize change protocol (what counts as change, who decides, how recorded)
add revisit triggers rather than silent scope creep

Pattern: Probe avoidance (unknowns treated as confidence)¶

Early signals¶

major technical questions are postponed
risks are discussed but not tested
rework appears late and expensive

Typical root cause¶

learning plan (feasibility probes) was missing from intent

Recovery move¶

Re-enter Intent Refinement (Software Delivery):

convert top unknowns into timeboxed probes
define pass/fail signals and the decision each probe unlocks
update reversibility classification and tradeoffs accordingly

Pattern: Governance theater (meetings exist, decisions don’t)¶

Early signals¶

recurring status meetings with no clear decisions
same issues repeat; nothing is resolved
change and risk are discussed but not managed

Typical root cause¶

governance cadence exists without decision mechanism and recording
commitment formalization did not specify how governance produces decisions

Recovery move¶

Re-enter Commitment Formalization:

define the decision forum (agenda, decision types, attendance)
introduce lightweight decision recording
connect governance cadence to change protocol and revisit triggers

Pattern: Operational surprise (handoff to ops/support fails)¶

Early signals¶

“we delivered it” but support refuses ownership
incidents increase; no runbooks/alerts exist
unclear on-call responsibilities and escalation paths

Typical root cause¶

operational posture and ownership were not formalized
meaning did not include operational stakes

Recovery move¶

Re-enter Meaning Discovery (Software Delivery):

capture operational stakes, unacceptable failure modes

Then re-enter Commitment Formalization (Software Delivery):

formalize operational ownership, support model, minimal observability/runbooks
define release/cutover posture if needed

Fast diagnosis: which stage to re-enter?¶

Use this quick mapping:

Conflicting realities, missing stakeholders, hidden constraints → Meaning Discovery
Vague outcomes, missing signals, unclear boundaries, denied tradeoffs → Intent Refinement
Unclear accountability, change chaos, acceptance disputes → Commitment Formalization

Recovery principle¶

When a failure pattern appears, do not “push execution harder.”

Instead:

identify the pattern
re-enter the right CDS stage
update the artifact (Handshake / Intent Package / Envelope)
re-formalize what changed

That is how CDS prevents repeated drift.