07 Keeping the specification as it grows

07 · Keeping the specification as it grows

An additive specification has a flip side: it grows. Version after version, decisions, open points, glossary, references and change history accumulate, and a document that loses nothing becomes, over time, voluminous. If the whole document must be held in the model's context at every step, its very completeness risks working against the reasoning — saturating attention with material that, at that moment, is not needed. The method addresses this tension with two devices.

The first device is distillation: the production, on demand, of a condensed version that presents the current state of the work as a legible specification, cleared of the chronicle of the process — the previous versions and the alternatives weighed and discarded. What remains is the current state with its reasoned decisions, the glossary, the constraints and the sources, as functional memory in the form the executor can apply. It does not replace the complete document — it stands alongside it, for the uses in which one needs the snapshot of the present and not the path that led there. It is the instrument of the application phase: whoever realises the product works on the current state, not on the history of how it matured. To distil is to choose deliberately not to saturate the context when the complete history is not necessary, while keeping the source document intact — with all its tracked history — for when it is.

When distillation omits something that would have been useful, and how much that weighs against working on the complete document, is a difficult judgement: it falls to the expert operator, and is still to be investigated in depth. In the practical use of the method for software development it has proven reasonably reliable: the cases in which the synthesis would have induced errors have for the most part proven recognisable in advance, and a well-formed specification in this field mitigates the problem at the root — the snapshot of the present is self-supporting because it rests on known foundations that need not be reformulated every time. It is the same principle by which, in technical domains, best practices, patterns and consolidated solutions to recurring problems emerge.

The second device acts on the same tension from another direction: partitioning into sub-specifications. A main specification that grows beyond a certain threshold is split into thematic sub-specifications — the interface design, the server-side design, the operational details of what is already in production — each coherent within itself and linked to the main one. Partitioning keeps each document within a size in which it stays legible, and each working context focused on its own theme, without whoever works on one aspect having to carry the weight of all the others. It is the same logic as distillation applied to space rather than time: showing, each time, only what is needed.

These devices have a consequence that goes beyond legibility, and touches cost. A wide specification held entirely in context is what most readily puts a model with a narrow window into difficulty — typically a local model, run on one's own hardware. Distillation and partitioning reduce what one needs to have before one's eyes at a given moment, and with it the load on the context; and since, as we have seen, a well-made specification turns the downstream work into a structured task, that task becomes within the reach of a model of modest size. Here the limit turns once again into a boon: minimising the portion of work that requires large, costly models in production, and entrusting to local models — cheap, runnable in-house, respectful of the data — the clear, well-specified tasks the method produces. The same discipline that risks saturating the context is the one that, once managed, makes it sustainable to work with small models where before the large ones were needed.

---

← 06 · The specification's anchors · The Method · 08 · Two ways to break the single perspective →