Main idea

The specification, the support documentation, the framing document are often defended on their clarity: they are understandable by everyone, usable in meetings, shareable with the teams, workable without technical skill. Those qualities are real, but they are qualities of access, not qualities of information.

The reason this layer exists is a readership constraint: most Product Managers, salespeople and support agents do not work in the repository. An intermediate object was therefore needed, less reliable than the code but readable by those who decide. As long as that constraint held, the natural-language layer was the least bad solution available — and nobody had to choose between reliability and readability, since only one of the two was attainable.

What follows from that: the day access to the source stops being reserved to those who can read it, the argument that justified the layer disappears, while the layer itself stays in place.

Why it matters

This is what keeps you from reading the gradual abandonment of documentation as slackening. The layer was not defended for itself, it compensated for an inability to access; when the compensation becomes optional, the artifact loses its grounds without anyone having decided it.

It also gives a test to apply to any intermediate document: which inability to access does it answer? If the answer is "none", it duplicates information that exists elsewhere, better maintained.

Nuances and limits

Access is not everything. A natural-language document also carries the intent and the business context, which the repository does not contain — that part does not disappear when the access barrier falls.

And being able to read the code through a tool is not the same as understanding it: the barrier moves toward technical literacy rather than vanishing.

Open questions

• What share of a specification rests on business context, and therefore survives the lifting of the access barrier?