A tool takes shape that checks its own methodology against itself
Requirements Dialogue is not a theory waiting for an application. It is taking shape directly on a tool built by its own rules — while those rules are still being sharpened.
The previous four articles in this series have assembled a picture: Scrum solves a coordination problem that is currently disappearing. SAFe answers the same problem with even more process instead of reducing it structurally. Three axes — coordination, prior knowledge, consistency — explain why no method so far holds at all three points at once. And eight months of building alone showed that a methodology only proves itself when it is measured against real errors, not against a tidy thought experiment.
This article describes what actually comes out of all that.
Neither a return nor an evolution
Requirements Dialogue is not a return to waterfall and not an evolution of Scrum. It is an attempt to deliver what the spiral model already wanted in 1986 but could not achieve for lack of tooling: an indefinitely repeatable, risk-driven refinement of requirements, with a hard, non-negotiable completion criterion for each individual requirement, and a structurally unbiased checking instance, held in a machine-maintained, consistent body of work that is never overwritten.
Four building blocks carry this:
A four-state model that records, for every statement in the body of requirements, how binding it is — directly confirmed by the decision-maker, logically derived, provisionally assumed, or merely proposed. This state is not a formality. It determines the confidence with which a statement may be used further.
A dialogue between two roles with structurally separated context: one role conducts the actual dialogue with the decision-maker. A second, independent instance checks the resulting statements for contradictions and gaps without knowing the preceding negotiation. If it finds something, the first role goes into a second round, pressing persistently where necessary, until the real core of a requirement has genuinely been exposed.
A hard completion criterion per individual statement, combined with unlimited openness at the level of the whole corpus. A single requirement only counts as binding once the decision-maker either explicitly confirms a formulated version or supplies a formulation of their own — and a confirmation is only valid if the exact wording it refers to immediately preceded it. At the same time the entire corpus remains extensible at all times, because a real product is never wholly finished.
Additive rather than overwriting correction. When a requirement changes, the previous version is visibly struck through and the new one placed beside it. The history stays fully traceable without obscuring the current state.
A tool that has to prove its own method
The tool this is taking shape on is called CCIDE. It orchestrates several AI instances in order to make software development visible and steerable — and it is being built by exactly the rules it is meant to implement, while those rules are still being sharpened. This is not a detour but the actual point: every error the methodology would not have caught counts against it. Every gap that becomes visible flows back into the methodology itself, before it turns into a problem elsewhere.
CCIDE is currently in active development. There is no public version yet — but there is an approach that is documented openly, tested on a real project, and whose limits are named as openly as its strengths.
The final article in this series is about who can be the first to work with it themselves.