What a receipt-driven build system actually costs you

Most build tooling reports on itself. It tells you a phase closed, a suite passed, a deploy went out. The reporting is generated by the same process that did the work, which means it can only ever be as honest as that process was having a good day.

An alternative is to make the record the primary artifact and the report a derived view of it. Every action that matters appends one event to a log that is never edited. A correction does not overwrite the thing it corrects; it is a new entry pointing at the old one. If you want to know what happened, you read the log. If a claim has no entry behind it, the claim is an opinion.

That is a small idea and it is genuinely uncomfortable to live with, in three specific ways.

The log will tell you that you did less than you thought

The first honest week is unpleasant. Work that felt substantial leaves three entries. Work you had half-forgotten leaves forty. The distribution is never the one you would have described from memory, and there is no arguing with it, because the entries carry timestamps you did not choose.

Writing a receipt is easy; making it impossible to lose is not

The interesting engineering is not in appending an event. It is in the key that decides whether two events are the same event. Get that key too narrow and two genuinely different facts collide, and the second one is discarded as a duplicate — silently, because a deduplicating writer that drops something is doing its job as far as it knows. Get it too wide and one fact splits into several entries every time a step is retried, and anything counting those entries now overcounts.

The rule that survives contact is that the key covers every field that distinguishes two things you would want to see separately, and no field that merely stamps the machinery that produced them. That sentence is easy to write down and hard to apply, and the cost of getting it wrong is not an error — it is a number that is quietly wrong later.

Exit zero is not evidence

The failure mode that costs the most is a writer that succeeds at returning and fails at writing. The command exits cleanly, the session moves on, and the entry went somewhere else — a rejected pile, a different directory, nowhere. Nothing surfaces, because the only thing that would have surfaced it is looking.

The habit that fixes it is unglamorous: after wiring anything that emits, go and look at the log. Not the return code. The log.

Is it worth it

If your question is “what is the state of things right now”, ordinary tooling answers that fine. The discipline pays when the question is “what actually happened, and who decided it” — asked weeks later, by someone who was not there, about something that matters. Reconstructing that from memory and chat history is a bad afternoon. Reconstructing it from an append-only log is a query.

It is a real cost for a narrow benefit. Whether the benefit is one you need depends entirely on how often you have had that bad afternoon.