content-hashed build

Two properties follow from the hash, and both matter more than they sound.

The build cannot change without becoming a different build. The identifier is derived from the contents, so there is no version of events in which "version 4" means one thing today and another thing tomorrow. Nothing is edited in place. Asking for a change produces a new version beside the old one.

Rollback stops being an operation and becomes a lookup. If every version still exists and each is addressed by its hash, going back is a pointer change — repointing at an artifact that is already built and already verified. There is nothing to recompute, nothing to reapply, and no half-way state to end up in. That is why an instant, unfailable rollback is a claim worth making and a slow, occasionally-broken one is a claim worth doubting.

The idea is not new — it is how content-addressed storage, container image digests and lockfiles all work. What is new is applying it to the output of a chat, so that a conversation gets an undo that behaves like version control instead of like a hope.

One caveat worth stating: rolling back code is not the same as rolling back data. A code artifact can be restored exactly; a database that has taken writes since cannot be, and any tool claiming otherwise deserves a follow-up question.