Changing requirements conflate genuine change with disambiguation failure
Type: types/note.md · Tags: learning-theory, deploy-time-learning, constraining
Agile's "changing requirements" conflate two phenomena: genuine world-change and late discovery that downstream specs committed to a wrong reading of an underspecified upstream spec. Short iterations bound how far a wrong interpretation propagates—not only how fast teams respond to genuine change. Markets move, users give feedback, stakeholders revise goals—but some churn is late discovery of interpretation errors: the requirements did not change; they were never precise enough to prevent divergent readings.
The cascading interpretation problem
A natural-language spec can leave a consequential choice unsettled. When Spec A does, Spec B (written downstream) silently commits to one interpretation of A. Further specs build on B's interpretation. If that interpretation later turns out wrong, the entire downstream chain breaks — and it looks like "requirements changed."
But nothing changed. The ambiguity was present in Spec A from the start. B's author committed to a reading of A, so B is an unchecked candidate program refinement. Whether that reading was permitted may itself be disputed; it is not necessarily an unwanted selection from an agreed set. The later the discovery, the more downstream work is invalidated.
Constructed example: Spec A says “retain records for a year,” and Spec B fixes deletion at 365 days. If the applicable policy already defines a year as 365 days, this is not an interpretation error. If the parties disagree about calendar anniversaries and leap days, B has committed before the permission boundary was settled. A later correction need not reflect a new retention goal.
The English account of prompting exposes the same distinction for LLM systems: selecting among agreed alternatives differs from committing to a disputed reading.
Two kinds of "changing requirements"
What agile calls "changing requirements" conflates:
- Genuine change — the world moved. The market shifted, users want something different, a stakeholder revised their goals. The original spec was correct at the time; the target moved.
- Disambiguation failure surfacing late — as in the cascade above: someone downstream committed to one reading, the bet lost, and the spec itself did not change.
These demand different responses. Genuine change requires adapting to new information. Disambiguation failure requires going back to the original spec and choosing a different interpretation — or narrowing the spec to prevent the same ambiguity from recurring.
What short iterations actually do
The agile insight that short iterations "reduce risk" is usually framed as: deliver faster so you can respond to change faster. But for disambiguation failures, the mechanism is different: short iterations limit how far a wrong interpretation can propagate before it's caught.
In waterfall, a wrong interpretation in an early spec can cascade through months of downstream work before anyone deploys and discovers the error. In agile, you deploy after weeks — so the wrong interpretation has less downstream work built on top of it when it surfaces. The cost of correction grows with how much was built on the wrong reading.
This reframes iteration length as an interpretation-error propagation bound, not just a change-response latency. Even in a world where requirements never genuinely changed, short iterations would still be valuable — because a spec that leaves a consequential choice unsettled invites interpretation errors that only downstream work reveals.
Deploy-time learning
Deploy-time learning extends the same loop to human–AI systems: each deploy surfaces interpretation choices that natural-language specs left open, and constraining narrows the spec for the next cycle. Every prompt invocation shows its reading in the output, so misreadings surface faster—but the agile propagation bound still applies: shorter cycles limit how much downstream work rests on a wrong reading before correction.
Open Questions
- What fraction of "requirement changes" in real agile projects are genuine change vs disambiguation failures? Is there empirical data?
- Does this reframing change how teams should do retrospectives — distinguishing "we learned the world changed" from "we discovered our reading of the spec was wrong"?
- Are there spec-writing practices that specifically reduce cascading interpretation errors rather than just reducing ambiguity in a single spec? See specification strategy should follow where understanding lives for lifecycle-dependent answers.
Relevant Notes:
- program refinement — grounds: a downstream spec that commits to one reading of its upstream is a candidate refinement until the reading is checked
- silent disambiguation is the semantic analogue of tool fallback — sharpens: the downstream cascade starts with a runtime event whose degraded status should have been surfaced when the first ambiguity was locally repaired
- Ingest: ATAM: Method for Architecture Evaluation — evidenced-by: bounds the two-way split, since the case study's late findings were requirements absent from a specification frozen for two years, a kind of late discovery that is neither genuine change nor a competing interpretation