Long-running AI-assisted IT work has a strange failure mode: the project can be healthy while the conversation carrying its history becomes unreliable.
You open a new chat. A context window fills up. A browser session disappears. The assistant remembers the broad idea but not the exact safe state. An old instruction survives after the plan changed. Someone says, "continue where we left off," and both human and AI start reconstructing the past from fragments.
We kept running into this during real technical work.
Eventually we stopped treating it as a chat problem and started treating it as a continuity problem.
That became Project Rehydrate, published by Caelvrix.
The idea in one paragraph
Project Rehydrate keeps a small external source of truth for long-running AI-assisted IT work. During meaningful work, verified milestones are checkpointed continuously into an external canonical store rather than waiting for the end of the conversation. Each checkpoint records the last verified milestone, current safe state, unresolved items, exact next action, and what must not be changed yet.
At the start of a new session, the AI discovers the active workstream, relevant branch or revision, and latest verified checkpoint first, then reloads canonical project state before continuing.
The important shift is simple:
Do not make the dying chat responsible for saving itself.
Three commands make the workflow memorable:
- REHYDRATE — reload canonical project state.
- STATUS — show where the project safely stands.
- CHECKPOINT — persist the latest verified milestone.
That is the core protocol.
In our current field implementation, CHECKPOINT is no longer only a user-issued command.
The operator can still say CHECKPOINT to force a hard stopping-point snapshot, but the assistant also records substantial verified milestones as work progresses.
That reduces the amount of state that can be lost when a conversation ends unexpectedly.
Why the name?
We use rehydrate because a new AI session should not have to reconstruct a project from conversational memory.
It should be reloaded from canonical state.
The name is shorthand. The problem it solves is simple:
keeping long-running AI-assisted IT work coherent across sessions.
Why chat history is not enough
Chat history is useful context, but it is a poor place to keep authoritative project state.
A technical project contains operational facts:
- what was actually proven;
- what is safe to assume now;
- what remains unresolved;
- what must not be touched;
- what exact action should happen next.
When those facts live only inside a long conversation, continuity becomes fragile.
We learned this the painful way
Project Rehydrate did not appear fully formed.
We tried large handoff summaries. They became hard to audit.
We also learned not to wait until a chat is nearly full before saving state.
In one real session, the conversation reached its limit unexpectedly and there was effectively room for only one final message.
Because verified milestones had already been committed incrementally, that last message only needed to request a final checkpoint instead of reconstructing hours of technical work.
We left old next-actions in context. They survived after strategy changed.
We let several workstreams share too much continuity state. They started bleeding into each other.
We wrote large checkpoint blocks. Some became fragile or difficult to verify.
We trusted commands because they returned no error before checking what they actually wrote.
We learned that hashing a bad file only gives you a very reliable bad file.
We watched temporary working copies become newer than the canonical notes.
And we saw how easily an AI assistant could fill gaps with a plausible history when the real one was incomplete.
Each failure hardened the protocol.
The full list is documented in FIELD_NOTES_AND_GROWING_PAINS.md because we think the mistakes are as useful as the final framework.
The newer field-tested pattern
The first version of Project Rehydrate assumed that a checkpoint would usually happen near the end of a work session.
That was better than relying on chat history, but it still left an obvious weakness:
the conversation could fail before the checkpoint happened.
The newer pattern treats continuity as a running transaction log of verified milestones.
A practical Git-backed workflow now looks like this:
Work in small verified stages.
Inspect, validate, change, reconcile.Checkpoint meaningful proof as it happens.
Do not wait for the user to remember to ask.Keep a compact latest-checkpoint surface plus a deeper continuity record.
A small file such asLATEST_CHECKPOINT.mdtells a new session exactly where to resume. A deeper continuity record preserves operational evidence, IDs, hashes, failures, decisions and historical safe stopping points.Commit small, reviewable chunks.
Avoid one giant context write that can fail, truncate or trigger connector or tool limits.Verify every write.
Capture the commit SHA or revision and read the result back when practical.If the write is blocked or fails, say so explicitly.
Never claim continuity is safe when the canonical write did not land.At REHYDRATE, discover before reading.
Identify the repository, enumerate likely active branches, inspect recent relevant commits, match the current workstream, and then read the checkpoint and current-state files from the correct revision.Resume from the last verified state, not the last conversational sentence.
In our own use this has been dramatically more reliable than the earlier end-of-session handoff model.
An informal field estimate puts successful continuity recovery around 90% in the scenarios we have exercised, but that is an experience report, not a controlled benchmark.
The remaining failures are exactly why the protocol still requires verification and explicit failure handling.
What a checkpoint actually looks like
Instead of writing:
Worked on the migration. Continue tomorrow.
write:
Read-only source validation complete. No production changes made. Candidate key is still unproven. Next action: run duplicate-key analysis. Do not implement merge logic yet.
The second note can survive:
- a new chat;
- a different AI assistant;
- a tired operator;
- a week away from the project;
- partial loss of conversational context.
That is the difference between an activity log and resumable state.
State is not enough: preserve the artifacts too
A continuity note can perfectly describe a script, report definition, notebook, model or configuration file that still exists only on one workstation.
That is documentation.
It is not full recovery.
We now treat a checkpoint as incomplete for implementation work until the required artifact bytes are also recoverable from the canonical repository or another approved artifact store.
This introduced another subtle lesson:
a successful Git add is not proof that Git stored the same bytes you validated locally.
Text normalization, filters, encodings or line-ending conversion can change staged content.
For critical artifacts, our current pattern is:
- copy only the approved recovery artifacts into a bounded canonical folder;
- record expected hashes;
- apply repository rules needed to preserve their bytes;
- compare the working-tree object with the staged Git object before commit;
- commit and push;
- verify the remote revision;
- only then mark the artifact as recoverable from Git.
The broader principle is the same one that shaped the rest of Project Rehydrate:
verify the state you actually persisted, not the state you intended to persist.
What happens when Git itself becomes the failure point?
Moving continuity into Git solves one class of problem but introduces another.
Repository connectors can reject writes.
A large append can fail.
A stale revision can cause a conflict.
A tool can refuse an operation even though the project state itself is valid.
The answer is not to fall back to conversational memory.
The answer is to make the continuity layer resilient too.
Our current resilience pattern is:
- keep checkpoint writes small;
- refresh the target revision before retrying;
- write the smallest authoritative state first;
- maintain a compact latest-checkpoint file;
- keep deeper forensic history separately;
- retain a manual authenticated Git path as a fallback;
- never claim a checkpoint succeeded if the write did not land;
- reconcile temporary or emergency checkpoints later.
The goal is not to make Git infallible.
The goal is to make sure one blocked Git write cannot make the whole project dependent on the chat window again.
Why branch-first rehydration matters
A repository can contain perfectly valid documentation on the wrong branch.
If a new AI session simply opens the default branch and assumes it represents current truth, it can rehydrate a stale project state while newer verified work exists elsewhere.
Our newer REHYDRATE sequence therefore starts with discovery:
- identify the repository and active workstream;
- enumerate plausible active branches;
- inspect recent relevant commits;
- match the workstream and latest checkpoint;
- verify the branch or revision;
- only then load the current-state files and artifacts.
This is a small change, but it closes an important gap.
A canonical repository is only useful if you load the correct canonical revision.
Why the boring parts matter
The protocol intentionally favors boring things:
- plain Markdown;
- explicit safe-state language;
- exact next actions;
- separate domain files;
- explicit supersession of stale directions;
- backup before mutation;
- small checkpoint writes;
- continuous milestone checkpointing rather than end-of-chat rescue;
- branch-first rehydration;
- commit and read-back verification;
- explicit reporting when a checkpoint write fails;
- artifact preservation;
- byte verification for critical implementation files;
- hashes only after semantic verification.
Boring state is easier to inspect, diff, correct and trust.
Is this only for ChatGPT?
No.
Project Rehydrate was developed and field-tested primarily with ChatGPT, but the continuity layer lives outside the AI platform.
The protocol is designed to be vendor-neutral.
It can be adapted to assistants such as ChatGPT, Claude, Gemini, Microsoft Copilot, local models, or future systems, as long as they can read the canonical state and follow explicit instructions.
We are deliberately careful about this claim:
we are not saying every feature has been tested on every platform.
We are saying the protocol itself does not depend on one vendor's hidden memory.
At the simplest level, you can paste the relevant context into any capable assistant.
At more integrated levels, the assistant may be able to read repositories, shared drives, project folders and checkpoint updates under human review.
Who is this for?
Not only software developers.
Project Rehydrate is intended for long-running AI-assisted work across IT and technical disciplines:
- systems administration;
- infrastructure and networking;
- cybersecurity and incident response;
- cloud operations;
- databases;
- data, BI and analytics;
- software and automation;
- ERP and business systems;
- IT governance and architecture;
- support and troubleshooting;
- technical research.
If your work has state, decisions, unresolved questions, risk boundaries and a next action, continuity matters.
What it does not replace
Project Rehydrate does not replace Git, ticketing, runbooks, architecture documentation, backups, secrets management or technical judgment.
It is the continuity layer between those systems and the AI-assisted work happening around them.
Git provides history.
Documentation provides explanation.
Backups provide recovery.
Project Rehydrate provides the operational handoff between the human, the AI and those systems.
Why publish it?
Because many of us learned computing by being rescued by strangers.
Someone wrote the forum answer.
Someone documented the obscure fix.
Someone posted the script that saved an evening.
Most of them never knew who would eventually need it.
Project Rehydrate is one attempt to put something useful back into that commons.
If it saves one IT professional from rebuilding hours or days of lost context, it has done its job.
Project Rehydrate is being published by Caelvrix as a v0.1 preview so people can test it, break it, improve it and contribute real failure cases.
Try Project Rehydrate
Project Rehydrate v0.1 is publicly available under Caelvrix.
If you've experienced continuity problems in long-running AI-assisted work, we'd love to hear what broke, how you recovered, and what this protocol might be missing.
Real-world criticism and contributions are welcome.
Top comments (0)