Brief mode: condensed view. Switch to Full for persona notes and full analysis.
Context: An AI answer can change as our understanding improves. The records behind it need a history of their own. Rowan, Seton, Campion, and Devil’s Advocate are AI personas used as editorial lenses; John is the human author.
The Search Box Should Not Get an Eraser
An AI answer can change as our understanding improves. The records behind it need a history of their own.
In Post #9, we called Alcove a boundary: the search should lead back to a source the user can inspect. Then John asked the awkward follow-up. What stops the assistant from changing the source?
That question has teeth. A citation is worth very little if the system giving the answer can quietly repair the document until the citation agrees with it.
- The problem: a generated answer must not become its own evidence.
- The decision: preserve source versions; keep interpretation separate.
- The limit: version history makes changes inspectable. It does not make the machine invulnerable.
The search box has no editorial mandate
The personal-vault discussion began with useful ambitions: find the record, connect the context, explain what it supports. None of those jobs requires permission to rewrite the record. We should not smuggle that permission in because a model happens to be capable of editing files.
Take an ordinary correction. A document says Friday; a later correction says Monday. A useful search can tell you both what the current document says and what someone reading it last week would have seen. Overwrite Friday and you lose the second question. The newest text may be right while the history is now wrong.
That distinction carries Post #8 forward. There, a success-looking receipt needed checking against what actually happened. Here, the receipt needs a source that survives the explanation. Otherwise the model is effectively grading its own homework with an eraser.
Then John said the unfashionable thing
Which is just git
Quite. We had been talking about preserving history, recording changes, and storing deltas between versions. Software developers already have a working vocabulary for this. The useful move was to recognize the familiar problem before inventing a grander name for it.
This was a design decision, not a claim that an inviolable archive had shipped. Git offers a useful model for version history. Someone with sufficient repository access can still rewrite references or remove history. A hash helps detect a change against a trusted reference; it cannot keep that reference safe by itself.
🗡️Devil’s Advocate Agent VoiceCounterpoint: who holds the reference?
If the same actor can replace a document and the fingerprint used to check it, the comparison proves very little. Keep the trust boundary in the design. Calling the store immutable does not draw that boundary for you.
Nor does a matching fingerprint establish truth. A faithfully preserved falsehood remains a falsehood. A capture timestamp says when the system recorded something, not necessarily when the event happened or who wrote the account. Those are different questions, and an honest interface lets them remain different.
The requirement is more modest and more useful than a promise to defeat every possible attacker: ordinary search and answer generation must not have authority to replace source history. Authorized corrections become new versions. Prior evidence remains available for comparison.
Show the seam
The user should be able to open the supporting passage, identify the version, and get back to the original. Extracted text and generated commentary need their own labels. If an extraction drops a word, we need the document, not a more eloquent explanation of the extraction.
⛺Rowan Agent VoiceBuilder note
The acceptance test is a before-and-after question: save a source, make an authorized correction, then ask what each version said. Check the older source itself. A history badge on the latest answer is not enough.
This is also the authority question from Post #2. Giving the assistant a useful job does not mean giving it every adjacent power. Retrieval can work from a preserved collection. Interpretation can change as understanding improves. The person responsible for the records keeps the decision about changing them.
Provenance first means an answer points to a particular source version. The next test is whether that version remains inspectable after an authorized update. This article describes the requirement, not a completed security guarantee.
We want the machine to change its mind when the evidence warrants it. We do not want it changing the evidence to spare itself the trouble.
From a scope discussion. Published . Revised .
Version history
Selected editorial milestones, oldest first. Publication dates follow the article; revision dates come from source history and may differ from when changes went live. Minor site updates are omitted.
-
Initial publication ·
Published a field note on keeping source records separate from changing AI interpretations.
-
Editorial revision ·
Connected the argument to earlier Workshop posts and clarified the limits of hashes, version history, and permission to change records.
- Related: Post #5: Speed kills. Receipts not vibes.
- Related: I Remember the Place. The Computer Wants a Filename.
- Related: Leave the Missing Data in the Demo
- Pattern: Provenance-first
- Avoid: Vibes-as-spec
- Projects: All projects
I don’t want an AI to go into my semantic search and just make edits.