Beyond Long-Term AI Memory: Building Persistent, Governed Canonical State with ChatGPT + GitHub + Drive

[ChipCAD]

I originally thought I was trying to solve long-term memory. What I ended up building was something different: an external canonical-state system with rules governing what can become durable, which sources have authority, how conflicts are handled, and how changes are verified.

GitHub and Google Drive provide the storage, but the part that has taken most of the work is the governance around them.

Why I’m posting this

I started looking through the OpenAI Developer Community for other people working on problems similar to the ones I’ve been running into with long-term AI continuity, persistent state, and cross-mode context.

I found several discussions that were clearly circling parts of the same problem, and I ended up commenting in two of them:

• Universal Project Brain / shared state across Chat, Work, Codex, Dots & Sites:
  Feature Proposal: Universal Project Brain + Objective Mode + Shared State Across Chat, Work, Codex, Dots & Sites - #2 by jscotthynson

• Using a Git repository as durable state outside the conversation:
  Using a Git repository as durable state for ChatGPT Web, outside the conversation - #7 by ChipCAD

After writing those replies, I realized I was trying to explain pieces of my own system inside other people’s threads.

So I decided it would make more sense to create one post where I could describe what I’m actually doing in my own words, how it evolved, what has worked, what still requires human oversight, and what I’ve learned from operating it over time.

This is not meant as a claim that I’ve solved the problem or built the final architecture. It’s a snapshot of a system I’m actively using and continuing to refine.

My Setup

In my setup, ChatGPT is the reasoning/operator layer. A conversation is working space while I’m using it. It can contain ideas, hypotheses, dead ends, temporary context, and things that may never deserve to become durable state.

But that does not mean the conversation is disposable.

I can start a completely ordinary chat with no intention of preserving it, work through a problem, and later realize that the result matters. At that point I can explicitly tell the system to preserve or capture the relevant result. That invokes a governed update process rather than simply dumping the conversation into storage.

Conversely, if I’m returning to something I’ve worked on before, I can start a fresh chat, enter through the system’s governing “front door,” and have it retrieve the relevant canonical state before we continue.

The distinction that eventually became important to me was:

conversation ≠ evidence ≠ canonical state

I currently use GitHub as the canonical structured-state layer for things like current state, SOPs and rules, decisions, open loops, source authority, provenance, source maps, and verification requirements.

I keep supporting evidence separately in Google Drive. Canonical records contain pointers back to the relevant evidence, so the system can distinguish between a source document and the interpretation or decision derived from that document.

A typical flow is closer to:

conversation → reasoning → decision → promotion gate → canonical state → verification

I also don’t treat ChatGPT’s own memory as authoritative state. It can help with continuity, but if something matters enough to govern future work, it needs to be deliberately promoted into the external system.

What turned out to be harder than persistence

Getting information to persist was actually the easy part.

The harder problem was deciding what the system should trust later.

Once I began using the system over longer periods, I started running into questions like:

• Which source is authoritative for this fact?
• Is this an original source, supporting evidence, or my current interpretation of that evidence?
• Is the canonical record still current, or has newer evidence superseded it?
• If two sources disagree, which one controls?
• Should this conversation change durable state at all?
• If a change is made, how do I know the intended information was actually written correctly?
• How do I prevent an old assumption from quietly becoming “true” again in a future conversation?

That led me to add explicit governance around the storage itself.

For example, GitHub is authoritative for my system’s structured interpretation and current state, but it is not automatically authoritative for every underlying fact. A document in Google Drive may be the original evidence. A live connected source may be authoritative for current live information. For example, a financial account source may control current balances or posted transactions, while a health-record source may control the current record it exposes. ChatGPT can reason across those sources, but it is not allowed to silently treat its own recollection or an older conversation as the final authority.

I also try not to turn the durable system into a transcript archive.

Most conversation content does not need to become permanent. What gets promoted is the useful result: a confirmed fact, a decision, a rule, an open question, a current-state change, a source pointer, or another piece of information that future work genuinely needs.

And when durable state changes, I want the change to be traceable.

That means knowing what changed, what source supported it, what it replaced or superseded, and whether the resulting record was checked after the write.

This is where the system stopped feeling like “long-term memory” to me.

It started feeling more like a governed state layer whose job is not simply to remember information, but to preserve the current authoritative interpretation of information over time.

What the governance actually looks like

When I say “governance,” I don’t mean a large prompt sitting in one chat.

There is a small core of files in the canonical repository that define how the system operates. The exact names are specific to my system, but conceptually they look like this:

Master Update SOP
    ↓
Source-of-Truth Governance
    ↓
Promotion Rules
    ↓
Mode / Handoff Rules
    ↓
Commands and Workflow Triggers
    ↓
Domain Current State + Open Loops
    ↓
Verification / Completion Rules

In my current implementation, some of those responsibilities are represented by files such as:

• chips_system_update_sop.md — the master procedure for changing durable state
• source_of_truth_governance.md — defines which systems own which kinds of information
• promotion_rules.md — defines what is allowed to become durable truth
• chatgpt_mode_routing.md — defines the roles and handoffs between Chat, Work, and Codex
• commands.md — reusable commands and governed workflow triggers
• domain current_state records — the current authoritative state of a subject
• open-loop records — unresolved actions, questions, dependencies, and closure conditions

Each operating mode has a governed “front door” into the system. Chat, Work, and Codex are all expected to begin from the current governing SOP and the relevant canonical records rather than relying on remembered context. Codex additionally has a small repository-native AGENTS.md file that points it to those same governing sources before implementation work begins.

The important part is not the filenames. Someone could organize this completely differently.

The important part is that the rules governing the state live with the state and are themselves versioned and inspectable.

So if I say “Preserve this”, the system does not interpret that as:

save the conversation

It is closer to:

recognize the requested operation
       ↓
read current governance
       ↓
identify the relevant domain and existing canonical records
       ↓
determine whether external evidence or a live source is required
       ↓
reconcile the new information with current state
       ↓
promote only the durable result
       ↓
update related state / open loops if needed
       ↓
commit the change
       ↓
read it back
       ↓
verify SIMI / ELIG where applicable
       ↓
return a completion receipt

That is what I mean by a governed state change rather than simply giving an AI somewhere to store information.

How Chat, Work, and Codex use the same state

I separate Chat, Work, and Codex into different roles rather than treating them as interchangeable.

• Chat is where I usually think through unresolved questions, compare options, and make decisions.
• Work handles sufficiently defined research, analysis, and production work.
• Codex handles repository changes, software, automation, testing, and engineering work.

The routing rules are part of the system itself.

If I’m working in Chat and the remaining task is really production work, the system can tell me that it belongs in Work and prepare the handoff. If Work reaches a defined engineering task, it can route that to Codex. If Codex runs into an unresolved architecture, policy, or requirements question, it routes that decision back to Chat instead of inventing an answer just to finish the implementation.

The important part is that I do not depend on one mode inheriting another mode’s conversation.

A handoff points the receiving mode back to the relevant canonical records, settled decisions, constraints, and source material. That lets the next mode reconstruct the state it actually needs instead of assuming the previous conversation is somehow still in context.

Because of that, I also do not depend on ChatGPT Projects or custom GPTs as the continuity layer.

I mostly work directly in Chat, Work, and Codex. Anything I have deliberately promoted into the governed system can be recovered from the external canonical state and supporting evidence, regardless of which conversation I happen to be in.

That means I can start fresh when I need to.

I can open a new Chat and reload the current state of something I have not touched in months. I can move a defined task into Work or Codex without requiring the entire prior conversation to follow me. And I can return later and continue from the governed state instead of depending on memory of the old thread.

In principle, that also means the state is not inherently tied to one model or one AI vendor.

If another AI can access the same governed sources and follow the same authority rules, it can reconstruct the same decisions, current state, and supporting evidence rather than forcing me to rebuild everything from scratch.

Natural-language control is harder than it looks

Another problem I did not anticipate at first was controlling a governed system through ordinary conversation.

Humans can hear phrases such as:

• “preserve this”
• “capture this”
• “update the system”
• “this is just an idea”
• “this is now a decision”
• “Project T0 session start”
• “Fo4 session start”

and usually understand the difference from context.

For an AI operating against persistent state, those differences matter a lot.

“Preserve this” might mean promote the durable conclusions from the current conversation. “This is just an idea” should specifically not make that idea authoritative. “Update the system” may require finding an existing canonical record, reconciling new information with it, updating any related open loops, and then verifying the result.

I therefore use named commands, governing rules, and strong natural-language cues to route those requests into defined workflows.

There is an important distinction here:

recognizing natural-language intent is still probabilistic; the governed workflow that follows a recognized command can be much more deterministic.

That distinction has mattered in practice.

Most of the time the system recognizes what I intend correctly, but I still treat intent recognition as something that can fail or become ambiguous. Once the requested operation has been identified, however, the system has explicit rules for what sources to inspect, what authority they have, what may be changed, and what verification is required before the operation is considered complete.

There is still a human-in-the-loop component to this.

Occasionally I’ll notice that an answer sounds stale, incomplete, or as though ChatGPT is reasoning from conversational context or memory rather than from the governed state. When that happens, I’ll ask something like, “Did you go through the front door?”

“Front door” is simply my shorthand for: reread the current governing SOP first, then locate and retrieve the relevant canonical records for the subject we’re working on before continuing.

Sometimes the answer is effectively, “No, I didn’t.” At that point I send it back through the front door, it reloads the governing rules and current canonical state, and we continue from there.

That failure mode has become less common as the system has matured, but I don’t pretend it has disappeared. I still have to recognize when the AI appears to be operating from recalled context instead of verified state.

So the system does not eliminate human judgment. What it gives me is a defined recovery path when I suspect context drift:

something sounds stale → return through the front door → reread governance → retrieve current canonical state → continue

That has been much more reliable than trying to correct the AI from memory inside the conversation.

The guardrails don’t guarantee the AI never wanders. They give me a known road back when it does.

That has made me much less interested in simply giving an AI permission to “remember everything.”

The more durable the memory becomes, the more important it becomes to control what is allowed to cross the boundary into durable state in the first place.

“Done” is not the same as verified

Another guardrail I added came from a simple problem: an AI can confidently say that it updated something correctly when the resulting durable state is actually wrong.

The wrong fact can be written to the right file. The right fact can be written to the wrong place. A file can be truncated or malformed. An old open item can remain active after the underlying issue has been resolved. An identifier, dollar amount, date, URL, or other exact value can be copied incorrectly while the surrounding prose still looks perfectly reasonable.

So in my system, a write is not considered complete merely because the model says it made the change.

After an update, the system is expected to read the result back and verify two different things:

1. Semantic integrity — Did we record the correct fact, interpretation, source, authority, and current meaning?
2. Mechanical integrity — Did the write itself preserve the intended content and structure without truncation, unintended deletion, duplication, malformed formatting or syntax, misplaced content, or other write/serialization damage?

For precision-sensitive values, I use a narrower mechanical-integrity sub-gate called the Exact-Literal Integrity Gate (ELIG).

ELIG applies when a one-character difference could change the referent or meaning—for example a request ID, commit SHA, file ID, URL, timestamp, dollar amount, measurement, or serial number. In those cases, the source and written value are compared exactly rather than relying on visual similarity or the model deciding that they “look right.”

SIMI asks whether the update says the right thing and whether the write itself is intact. ELIG is the exact-match test inside Mechanical Integrity when precision-sensitive literals are involved.

So my verification model is essentially:

SIMI: Did we preserve the correct meaning and perform the write correctly?

ELIG: Where exact literals matter, did the source and destination actually match?

Git history helps here because changes are inspectable and reversible, but Git itself does not perform the governance. The system still has to decide what should have changed and verify that the committed result actually represents that decision.

That changed how I think about AI completion.

For durable work, “the model says it is done” and “the system has verified the state transition” are two different things.

The second one is what I care about.

Where the system still needs human awareness

I don’t consider the system perfect, but most of the problems that originally drove its development are no longer everyday problems.

The system now handles promotion, source separation, canonical records, provenance, verification, handoffs, and retrieval reliably enough that I generally use it rather than work on it.

The remaining weakness I notice most often is at the boundary between ordinary conversation and governed workflow.

The underlying rules can be explicit, but the AI still has to recognize when those rules should be invoked.

Most of the time that happens correctly. Occasionally, though, I will notice that an answer sounds stale or seems to be coming from conversational context or remembered information instead of the current canonical state.

That is where the “front door” recovery path matters.

I can simply ask whether it went through the front door or tell it to do so. It rereads the governing SOP, retrieves the relevant canonical records, and continues from the governed sources.

So I would describe the remaining problem less as maintaining the state and more as reliably recognizing when the state needs to be retrieved.

That recognition is still partly probabilistic because natural-language interpretation is involved.

Once the correct workflow has been recognized, however, the process behind it is much more deterministic.

At this point, that distinction may be the most important remaining limitation I have learned from actually operating the system:

governance can make the workflow reliable, but the AI still needs to recognize when to enter the governed workflow.

Human awareness remains the final backstop.

How this actually evolved

I did not sit down one day and design all of these rules, SOPs, source hierarchies, verification gates, and handoff procedures in advance.

The system grew out of use.

One of the earliest problems that pushed me in this direction was long-running Fallout 4 sessions. I kept running into continuity and state problems: what had happened, what was current, which save or record should control, and how to keep a future session from confidently reconstructing the wrong version of events.

That was one of the first places where external state started proving its value.

From there, the broader system evolved iteratively over several months.

I would use it, something would fail or feel wrong, and I would correct the rule:

No, don’t do it that way.
This source should have authority.
That information should stay evidence, not canonical state.
This needs a verification step.
That mode should hand the decision back to Chat.
This command needs a clearer trigger.

Then the governing files would be updated so the correction became part of the system going forward.

Fallout 4 may have been one of the early proving grounds, but the system did not stay there.

Today I use the same governed architecture across much of my real life. It helps me maintain current state and open loops around finances, health, career and work, vehicles and RV matters, projects, learning, decisions, research, and other ongoing areas that I may return to weeks or months later.

When needed, it can also consult live sources such as email, calendar, health data, financial data, or other connected systems, then reconcile the relevant information back against the canonical state instead of treating those live sources as one giant undifferentiated memory.

I also keep a governed inbox in Google Drive. I can drop in a file from almost any subject, and the system can classify it, move and rename it into the appropriate Drive location, and promote the relevant durable information into the appropriate canonical record.

So the thing that started as a continuity problem gradually became more like a personal operating layer for long-running work and life state.

I can leave a subject alone for months, come back in a fresh conversation, go through the front door, and recover the current governed state without needing the old chat to still be in context.

So if someone wanted to experiment with this approach, I would not recommend sitting down and trying to design the complete governance architecture first.

Start small.

At minimum, I would begin with:

1. A repository for durable structured state

2. A "front door" document
   - what the AI must read first
   - where authority lives
   - how to find the rest of the system

3. A source-of-truth rule
   - what belongs in the repository
   - what remains supporting evidence
   - what should never become authoritative automatically

4. A current-state record for the thing you are actually working on

Then use it.

Let the failures tell you which rule you need next.

If the AI retrieves stale information, add a freshness rule.

If temporary ideas start becoming permanent facts, add a promotion gate.

If two sources disagree, define source authority and conflict handling.

If the AI says something was updated but the file is wrong, add read-back verification.

If different modes lose context, define a handoff contract.

The architecture should grow because a real failure demonstrated the need for another guardrail, not because you tried to anticipate every possible failure before using it.

That is essentially how mine developed.

I started by trying to keep continuity.

The guardrails came later.

And after enough iterations, I reached the point where I spend far more time using the system than building the system.

Start small.
Let the failures tell you which rule you need next.

One last thing before I stop.

I’ve spent this post describing how the system works, but I don’t want to leave the reader with only descriptions of rules, governance, promotion, verification, and receipts.

I used this same system while developing this post.

When I finish, I’m going to give it the same ordinary command I use in day-to-day work:

“Preserve this.”

I’ll then capture the governed process that follows that command: how the system identifies what should become durable, where it belongs, what existing state it checks, what it updates, how it verifies the result, and the completion receipt it returns at the end.

My goal is to provide a concrete receipt for what I’ve been describing throughout this post rather than asking anyone to simply take my word for it.

So the next section is not another explanation of the system.

It is the system using itself to preserve the work that produced this post.

That was it thinking and I told it before hand that I wanted to show the reader how it processes a “preserve this” command so it added a section after it preserved it to screen shot as well.

[oliver-zehentleitner]

Thanks for writing this up in full. Seeing the complete system, I think “governed canonical state” is actually a much better description of what you built than “long-term memory”.

The distinction that stood out to me most is:

conversation ≠ evidence ≠ canonical state

That additional separation from evidence is also where your system clearly goes beyond what I built with Keep the Why.

KTW intentionally stays inside the much narrower scope of a software project: the session is working memory, project files are durable project memory, and the durable layer focuses primarily on rationale such as decisions, constraints, rejected alternatives and lessons learned.

That narrow scope is deliberate. We do not need to solve source authority across financial data, health records, Drive documents or other live systems. Keep the Why has one job, and we try to keep it there.

What I find fascinating is how much the underlying architecture still converged independently: user-owned external state, explicit promotion instead of transcript dumping, rules living with the state, fresh sessions reconstructing context from durable artifacts rather than previous conversations, and no inherent dependency on a particular model or AI vendor.

Your “front door” concept is especially interesting. Even perfectly maintained persistent state is effectively useless if the agent fails to enter the workflow and retrieve it when needed. From the coding-agent side, I have come to see that retrieval behavior as at least as important as the storage format itself.

So despite the very different scopes, I think we arrived at a very similar fundamental idea:

The conversation is transient. The state that matters should live outside it, under the user’s control.

Great write-up.

[Daareek]

This is very close to where we arrived independently after operating a persistent AI collaboration for a while.

One additional distinction became important for us:

OBSERVED ≠ INFERRED ≠ PROVEN ROOT CAUSE

We found that provenance is not only about where information came from, but also about the epistemic status of the conclusion derived from it.

For example:

• “the tool returned X”
• “therefore we suspect Y”
• “we reproduced Y independently and can now treat it as the root cause”

should not collapse into one canonical fact.

We also ended up treating recovery/checkpointing as part of the state model rather than just an operational convenience. A long-running agent can fail halfway through a tool sequence, so future work needs to know not only the intended state but also the last verified durable state transition.

The pattern we use is roughly:

event/history → evidence → interpretation → promotion gate → canonical current state

with corrections and supersession preserved instead of silently rewriting history.

Another lesson was that communication and authorization should remain separate. An agent may know what the next action should be, but that does not automatically mean it is authorized to perform it.

So I strongly agree with your conclusion that this stops being a “memory” problem fairly quickly. It starts to look more like a small governed operating system for long-term human–AI collaboration.

[ChipCAD]

Oliver, thanks for the thoughtful response. One thing I especially appreciate is the independent convergence you pointed out. When two systems built separately for somewhat different purposes keep arriving at many of the same underlying boundaries — external user-owned state, selective promotion, reconstruction from durable artifacts, verification, and the importance of retrieval — that gives me a little more confidence that the architecture isn’t just something ChatGPT and I talked ourselves into. I appreciate you taking the time to compare the two.

Daareek, the more I thought about your comment, the more interesting the comparison became because I think we have actually run into several of the same problems but solved them in somewhat different ways.

Your OBSERVED ≠ INFERRED ≠ PROVEN ROOT CAUSE distinction lines up closely with something I ran into this week.

I was troubleshooting a GitHub write failure in ChatGPT Chat and handed the diagnostic work off to Codex. What I did not realize at first was that some of the test conditions were being changed during that handoff. It was not random drift so much as the AI making what it thought were reasonable assumptions about a cleaner or better way to run the test.

Eventually Chat explained what had happened and I realized that the reproduction was no longer actually reproducing the original conditions.

That caused me to tighten the governance around diagnostics. If I am trying to reproduce an observed failure, the reproduction has to remain apples-to-apples with the known failure conditions. If we change, simplify, sanitize or otherwise vary something, that is a different test and has to be identified as such. Otherwise an inference about what happened can quietly start looking like something we actually proved.

Your recovery/checkpointing point is interesting too because I think my system solves that from a somewhat different direction.

I don’t maintain a separate transaction journal or checkpoint layer. GitHub is the canonical structured state, and a system change is not considered complete until it is committed, read back and verified. I use SIMI for semantic/mechanical integrity, ELIG when exact literals matter, open loops for unresolved work, explicit completion states, and a governed handoff lifecycle for substantial cross-mode work.

So if a conversation or tool sequence gets interrupted, the system is designed to be reconstructable from the last verified canonical state rather than depending on the interrupted session to recover itself. Anything that did not make it through verification is simply not treated as completed state.

The authorization distinction is also one I had to make explicit. In my system, an agent knowing the correct next action does not give it authority to perform that action. A handoff itself does not grant execution authority, and even an old status such as “ready” or “approved” cannot be reused as current authorization. I also don’t allow the receiving agent or mode to self-declare final completion of a governed handoff.

So I think we may have arrived at several of the same boundaries from different operating environments.

Your terminology makes me curious about that difference. When you talk about long-running agents, tool-sequence recovery and checkpointing, are you primarily operating in a software/agent-development environment, or are you using this as a broader personal system as well?