How CCIDE works: from the first idea to a finished story

The six articles of the series above explain why Requirements Dialogue exists as a methodology at all. This article explains something else: how CCIDE, the tool that implements that methodology, actually works. No more weighing of pros and cons, but a sequence — step by step, as it runs today, with the gaps that are still open today named explicitly rather than glossed over.

Three stations are at the centre: how a project begins in the first place, how a single requirement becomes something dependable, and how a story that can actually be built comes out of it in the end. Everything after that — architecture, code generation, tests, documentation — is only sketched at the close, because that is what it honestly deserves: to be no more than a sketch.

How a project begins

A project in CCIDE does not begin with code, and it does not begin with a finished specification either. It begins with text — in one of two ways.

Either a person types in one requirement after another, in direct dialogue. Or they feed in an existing concept document that nobody has structured yet. Both routes then run through the same pipeline, not through two separate ones. In the second case, two instances take on the initial decomposition work: they read the document and break it down into individual, atomic requirement candidates — every sentence, every intention, every implicit expectation becomes a candidate of its own that can be checked on its own terms.

This is the point that is easy to underestimate: from the very first second, a project is not a single thought but a bundle of individually verifiable claims about what is needed. That is also the answer to a question that looks trivial at first glance but is not — what actually is the "target app"? The honest answer: at the start it is nothing fixed. It is the sum of all requirements that pass through the forthcoming requirements dialogue and mature there. What gets built in the end is not what was in someone's head on day one, but what survives that dialogue.

At this point a gap has to be named openly rather than papered over: exactly what the very first rough description of a project's goal should look like — a free-form paragraph, a structured form, an interview beforehand — is not yet finally settled today. What is settled is the moment after: as soon as text exists, in whatever form, it runs through the same checked pipeline as every individual later requirement. That pipeline is the subject of the next section.

The requirements dialogue: how a sentence becomes a checked requirement

Every individual requirement candidate goes through the same core mechanism, whether it came from the free-text dialogue or from an imported document. Two roles carry this mechanism, and they deliberately do not do the same thing.

The Refiner conducts the actual conversation. It asks mandatory questions — who exactly suffers today from what is missing; what happens if this requirement is not implemented; what the smallest slice is that already delivers real value; how success will be recognised. What matters is not that a field gets filled in but that the answer carries substance. An answer that merely restates the question in different words counts as unanswered — formal completeness buys no substance. If an answer seems plausible but unsupported, the Refiner asks specifically for the source of the claim instead of simply accepting it.

Every answer produced along the way is assigned one of four possible epistemic states:

• STATED — explicitly confirmed by the human, in exactly the wording that was put forward for confirmation.
• DERIVED — logically inferred from statements already confirmed, not asked about separately again.
• ASSUMED — a working assumption that is carried forward but stays openly marked as unconfirmed.
• PROPOSED — a suggestion from the Refiner itself, still awaiting a response.

The transition from ASSUMED or PROPOSED to STATED is bound to a fixed rule, internally called UX-24: a confirmation — a "fine", a "yes" — only counts if exactly the wording being confirmed was visibly displayed immediately beforehand. So you cannot say "yes, all good" somewhere in the course of a long conversation and thereby turn five different assumptions scattered across the dialogue into facts at once. This rule applies not only to the product with respect to its future users — it applies to the Refiner itself, in its handling of CCIDE's own body of requirements.

The Challenger then takes on a different task. It receives the finished result of the Refiner conversation but not the context in which it arose — it is a structurally fresh instance, with no memory of the dialogue that just took place. This freshness is not a side effect but the actual point: whoever wrote a formulation tends to consider it more plausible than it is — an anchoring effect that human review processes are notoriously subject to, because the same head that wrote something is then supposed to check it. A structurally separate, context-free instance does not have this problem, because it brings no anchor of its own. The Challenger classifies the new requirement against the existing corpus: new, refines something existing, contradicts something existing, or is a duplicate. On a genuine contradiction the process stops immediately, even in the middle of a larger batch — contradictions are not collected and resolved all at once at the end.

Only once a requirement passes this check does it count as mature. And only a mature requirement may become the starting point for the next step at all: decomposition into epics, features and stories.

One more piece of honesty here, which belongs to the principle itself: the exact wording in which provenance rules between individual claims are formalised in detail — for instance which chain of STATED and DERIVED statements actually supports a given conclusion — is itself currently being reworked. The underlying principle has been settled for months and is tested in practice; the final refinement of its formulation is not.

From a mature requirement to a story

A mature requirement is not yet a story. It is the origin from which a hierarchy of exactly three levels emerges: epic, feature, story — no more, not even when a fourth level looks tempting. If a story becomes too large, it is cut more generously, not subdivided further.

This decomposition does not come about by a single instance making a proposal and nodding it through. It comes about in what is called top-down ping-pong: two simulated architect roles that put the same subject to each other from different angles — with one hard rule that has proved in practice to be the centrepiece of the whole mechanism. Each side must raise at least one genuine objection. No confirmation loop, no mutual nodding. Discarded alternatives are documented, deviations from higher-level specifications are marked explicitly instead of silently adopted, and cross-relationships between epics or features are named as soon as they surface.

Every decomposition is recorded as its own numbered version (decomposition.v1.md, v2.md, and so on) — nothing is overwritten, only added to, the same additive principle that applies to the body of requirements itself. Each epic or feature pass additionally has a short REVIEW-SUMMARY.md: the outcome at a glance, contested points, deviations, open decisions — kept separate from the points that are routinely deferred anyway.

Between the levels there is a coupling rule that looks illogical at first but is not: the epic level may be worked through in a batch, because it is loosely coupled. The transition from feature to story may not — it runs one after another, with an approval between each individual step, because here the individual parts genuinely build on one another. And however far a pass carries: after each allotted scope there is a hard stop. No automatic jump to the next level, no continuation without explicit approval.

Which epic or feature comes first when several are equally eligible also follows a rule rather than chance — though one that had to be corrected once itself. Originally what counted was simply how often a candidate was referenced in other decompositions. That turned out to be too crude: a candidate that repeatedly cited itself in its own follow-up decisions could push itself artificially to the front. Today only directed, confirmed references from currently open neighbouring candidates at the same level count, complemented by a second, equally weighted quantity: how expensive an error at this point would be compared with an error elsewhere. A detail that shows the rules governing the decomposition are subject to the same principle as the requirements they decompose — they are checked, corrected, and the correction is documented visibly rather than concealed.

This part too has a current, very concrete piece of evidence that the methodology is meant seriously rather than merely asserted: CCIDE's own epic/feature/story tree so far — six epics, 86 stories — was recently marked as obsolete. Not deleted, but no longer the target structure. The reason is precisely the point of this article: those 86 stories came about before the requirements dialogue described here was applied to CCIDE itself. They therefore rest on no checked requirements foundation, but on one that never went through this process. Rather than healing that retroactively, the missing body of requirements is currently being rebuilt from scratch and in full, before the decomposition begins a second time — the same consequence that would be demanded of any other project CCIDE manages one day.

What comes after — deliberately only sketched

A finished story eventually becomes code. In between lie several stations that are actively taking shape at the moment but are not yet stable enough for a detailed public description to be honest: an architecture dialogue that derives a technical foundation from the story tree; a translation of that foundation into a concrete, executable set of build instructions; the actual code generation; automated writing and running of tests; and documentation that keeps itself current where needed.

Some of this has already been decided — that it is a browser application rather than a separate desktop installation, for instance, or which database binding comes first. But those are boundary conditions, not a finished architecture. The actual relationship between story, data model, test coverage and generated code — that is, exactly the part that turns a specification into a running program — is only now being worked out conceptually, with the same care that went into the requirements dialogue and the EFS decomposition. Something is taking shape here — nothing more can honestly be said today, and anything else would be feigning a specification that does not yet exist.