02 The specification before the product

02 · The specification before the product

The method's first principle is that the primary artefact of the work is not the finished product, but a specification document. The product — a program, a document, a plan, a strategic decision — is a derived artefact: generated or verified from the specification, not the other way around. In this document's examples the derived product in mind is predominantly software code, because that is the domain the experience comes from; but the principle is general in those areas where an artefact is built from an intent.

In software this principle has an established name — spec-driven development: the specification is the source of truth, the code is what follows from it. But the reason the idea, in itself not new, has become topical again holds beyond code. When a model generates an artefact from instructions scattered across a conversation, every ambiguity left unresolved upstream re-emerges downstream — in the form of a product that works but does not do the right thing, of rewrites, of divergence between what was intended and what was produced. It holds for a program as for a report, a policy, a plan. Fixing the intent explicitly, before producing, reduces this cost: the software literature calls it the "ambiguity tax", but the effect is observable across various fields.

In the method described here the specification is a plain-text document, versioned, that grows through successive iterations. While it is being drafted, one property is non-negotiable: additivity. A new version does not delete the content of the previous one; it integrates it. This constraint guards against a typical and insidious failure mode — the silent loss of content between two revisions, where a detail decided weeks earlier disappears without anyone choosing to remove it.

A note on method

The method distinguishes two phases with different needs: the drafting of the specification, in which the reasoning is built and deposited, and its application, in which the product is realised from the specification. In the second, the consolidated specification is read-only dogma: whoever realises the product does not renegotiate the choices while doing so, but executes them. If a discrepancy emerges during execution, it is escalated upward — to the drafter — rather than resolved locally in the product. In this way the source of truth remains a single one.

---

← 01 · The problem of working with a model · The Method · 03 · Declaring the boundaries, accepting good enough →