Saving your work is not the same as making it recoverable

On Thursday evening, I asked ChatGPT to tidy the GitHub repositories I use as shared memory for Editorial Intelligence. It had been struggling to find things I knew we had recorded, and I was getting tired of supplying the same context again. I thought the notes might have become cluttered enough to make retrieval unreliable.

There was clutter. A current-state file had grown to about 82 KB, mixing live priorities with old schedules and completed tasks. But the audit found something more serious: a September commit labelled as an article publication had replaced a repository containing 366 files with one article.

The missing material included methodology, evidence, research notes and the instructions intended to help different AI tools work from the same knowledge. We recovered the 365 paths still absent from the current version and preserved all 18 newer files. Git history made that possible; the exact tool or process responsible for the original change has not been established.

That last qualification matters. I can describe the change and its consequences, but I cannot responsibly turn it into a story about one model deleting my work. The more useful question is why such a large loss could remain unnoticed while the work continued.

The system I trusted needed checking

I have argued that AI work needs a save point: an inspectable record of decisions, evidence and unfinished work that survives the conversation. I use GitHub partly so that ChatGPT and Claude can consult the same material, rather than each relying on fragments of their own chat history.

This incident exposed a gap in that argument. Having version history gave me a way to recover the material, but it did not ensure that the material remained available in the working version. A useful safeguard existed, yet nobody was checking the condition it was supposed to help protect.

I was also relying on the assistant to recognise when it lacked context. When something could not be found, the conversation could still continue from partial information. A fluent answer did not tell me whether the relevant record had been retrieved, whether it existed somewhere else, or whether it had disappeared.

The failure was therefore larger than a bad file operation. I had a system designed to preserve knowledge, but insufficient verification of what had been saved and what could still be used. I was becoming the manual consistency check, noticing that the assistant seemed to have forgotten things and trying to reconstruct them.

It would be convenient to blame the technology and leave my own assumptions untouched. I had treated a durable store as more dependable than the maintenance around it justified. I had also allowed the current-state notes to become a rolling archive, making it harder to distinguish missing information from information buried beneath weeks of updates.

What we changed, and what remains unfinished

The first job was recovery with verification. Each restored file was checked against its original Git version, and the newer files were checked to ensure they had been preserved. Recovering an old snapshot over the whole current repository would have created a second problem by wiping out work completed since the loss.

The next job was to improve how changes are saved. A small edit should begin from the complete current repository and preserve everything outside its intended scope. Before accepting it, the system should inspect the proposed change for unexpected removals. Afterwards, it should check that the intended files remain available.

We added a script and automated workflow that flag disappearing file paths. The script accepted a normal edit and addition, and rejected a simulated destructive replacement. Those checks are useful, but I should be precise about their limits: a failing check is not an enforced block on every possible direct write. We could not establish that protection through the available connection, and the private repository’s ruleset access returned a paid-plan requirement.

We also separated current state from history. The long Sage current-state file became a much shorter account of live work, with the full former log preserved separately. Completed tasks, proposed dates, confirmed deadlines and waiting dependencies could then be distinguished without reconstructing the entire month.

Finally, we made the retrieval rule explicit. “I did not find it” cannot silently become “you never recorded it”. A failed search should trigger a check of the actual files, their history and the repository that owns the subject. If the record remains unavailable, that limitation should be visible in the answer.

These changes address the failures we observed. Independent backups, tested recovery procedures and enforced write controls remain part of the wider solution; I am not claiming they have all been implemented. Nor would a file-count check tell me that a surviving document was accurate or current. Integrity and usefulness need different checks.

Shared knowledge needs an owner

For one person’s experiment, this was frustrating and recoverable. In a team, the same weakness could affect several people before anyone noticed. An assistant might draft from an outdated policy, a colleague might repeat a rejected approach, or a new joiner might receive a confident explanation assembled without the evidence behind the decision.

Those are possible consequences, not outcomes established by my incident. They illustrate why shared knowledge needs more than a place to live. Someone must be accountable for what belongs there, which version guides work, who can change it and what happens when the record cannot be trusted.

The responsibilities should be divided clearly. The human owner decides what has been agreed and what remains provisional. The assistant retrieves the relevant material, preserves unrelated work, checks its changes and reports failures. Technical controls catch errors that instructions alone may not prevent.

There is editorial work inside this maintenance. Deciding that a meeting changed a project is different from saving every sentence said in it. Identifying the evidence behind a claim is different from archiving the finished article. Preserving a useful production lesson is different from turning one person’s preference into a permanent rule.

A technical backup can protect the files while all of those distinctions remain unclear. Equally, an editor can organise the knowledge carefully while a poorly controlled write operation removes it. Reliable shared work needs both kinds of care, with enough ownership to stop each side assuming the other has handled the problem.

A service should prove that people can resume the work

This gives me a more concrete way to think about the editorial-systems work I want Editorial Intelligence to do. An organisation can already have substantial research, customer evidence and accumulated judgement, yet struggle to make that knowledge dependable for colleagues and AI tools. Helping it become usable is a potential service, provided the outcome is demonstrated.

I would start with one workflow, such as customer stories. Which record owns the approved evidence? Where are the decisions about the angle? What did the last interview fail to capture? How does a reviewer know which claims are checked? When someone changes the brief, how does that change reach the next person working on it?

The deliverable could include clear ownership, a maintained current-state record, connected evidence and a reviewed update process. Technical backup and access controls may need a specialist partner. My contribution would be to establish what needs to survive, how it should guide the next decision, and whether people can actually use it.

The test should be practical. Give a colleague or a fresh assistant the maintained record, without the original conversation. Can they identify the current objective, recover the relevant evidence, distinguish decisions from suggestions and resume the work accurately? Then make a legitimate change and test the handover again.

If that reduces repeated questions, reconstruction and avoidable rework, there is a useful capability to develop. One recovered repository does not validate a new consulting offer, but it supplies a failure case and a concrete way to test the response.

I still think shared memory is valuable. This experience makes me more demanding about what deserves that name. My next test is whether the repaired system can support accurate handovers over time, while making missing or conflicting context visible before it shapes another answer.