10The walking skeleton and the roadmap
A thin system from end to end at Crawl, one question per stage, and criticality earned by measured quality.
The first article set the stages: Crawl, Walk, Run and Fly. This chapter describes how the system is built through them, in short cycles, so that each stage adds to what the previous one built instead of replacing it.
A skeleton from the start
The first version of the system is a walking skeleton: thin on both sides, but complete from end to end, with a narrow scope of trusted data, a simple answering path, the contract, traceability and a test run. It exists from Crawl, for one purpose: to measure whether the data can actually be retrieved and used. Data can look clean in an audit and still fail at retrieval, because tables fall apart, revisions cannot be told apart, or users ask in words the documents never use. Only a running system reveals this. At Crawl, the skeleton is used by the team, evaluated against the test set and shown in reviews. It is never put in users' hands.
Each stage answers one question
The stages answer one question each (Figure 10). Crawl: can we have trusted data, and at what cost? Walk: can the system find the right trusted data, measurably, and improve? Real users see it for the first time, but only as pointers to sources. Run: can it answer directly in real work, where errors are tolerable, and can we operate it for years? Fly: can it scale, and be trusted with critical questions where the evidence allows? Some questions will remain pointers for good.
The first gate
At the end of Crawl, the audit, the expert interviews and the skeleton's measurements answer the first question. The answer is rarely yes or no for everything: yes for one engine family, not yet for another, never for some documents under contract. The gate mostly sets the scope of the next stage, sometimes limits it to pointers, and occasionally stops the project. It comes back whenever a new source or scope is considered.
Choosing each stage's scope
Four criteria apply, in order: the cost of a wrong answer, the value of a right one, how easily answers can be checked, and how easily the data can be prepared. The first two are business decisions, the last two engineering ones. Data that is easy to prepare but hard to check is a trap: it produces results nobody can verify, and looks like progress until it fails. Starting with easy data is not cherry-picking if it is done openly, with the whole collection profiled from the start and results never presented as valid beyond their scope.
Proven relevance earns criticality
Criticality never rises on enthusiasm. It rises for a type of question only when measured quality for that type has reached its threshold.
Something to show every cycle
Short cycles keep sponsors and experts engaged, and the credibility they build is what the gate decisions will draw on. Each review shows something real: contradictions the audit found in the company's own documents, the quality curve rising, honest examples including a correct "I don't know," and experts' corrections now in the test set. A rising curve convinces more than a polished demonstration.