Main idea

A book written about a working method can be written inside that method: the sources, the chapters, the writing decisions, the cut passages and the reason for cutting them all stay in the workspace the book describes. Coming back to a chapter after three weeks away then doesn't call for rereading it — you ask where you stood and what you had decided to leave out. The translations and the different editions come out of the same place, with no manual rework of the text.

The resulting deliverable doesn't illustrate the method: it attests to it. A description says what the system is supposed to make possible; a book of several hundred pages, translated and picked up again over months, says what it actually made possible, including at the points where the description stays vague.

Why it matters

It shifts what you ask of the author of a method. The question is no longer "is it coherent?" but "what have you produced with it?" — and the answer is verifiable by a reader who has to take nothing on trust.

It also changes how a method gets announced. An article describing the system convinces less than a deliverable that could not have existed without it: the second carries its own proof of use, and it makes visible the burdens the description passes over in silence — the duration, the interruptions, the volume, the revisions.

Nuances and limits

A deliverable produced by its own author only proves viability for that author. It says nothing about what the method costs someone who didn't build it, nor about what holds up once it passes through several hands.

And a successful deliverable may be successful despite the method, through stubbornness rather than through system: the proof bears on what was produced, not on who deserves the credit.

Open questions

• What, in a deliverable, would let an outside reader tell apart what the method made possible from what the author would have produced without it?