Persistence of memory and long running Projects

ChatGPT Feature requests
, , , ,
1

The core principle is:

Persistent history should remain available without allowing obsolete instructions inside that history to override current authoritative project sources.

This would make Projects substantially more reliable for serious long-running work.

It would improve long-running software projects, research projects, legal/document workflows, organizational procedures, writing projects, operating manuals, simulations, and any project where rules evolve while historical context must remain available.

I am using ChatGPT Projects for a long-running persistent Dungeons & Dragons campaign. I am using this to stress test your model for 12 to 16 hours a day for the past month or so. I am impressed but there is a huge problem I see. Projects are extremely useful for this because they can hold campaign records, governing instructions, source files, and long-running conversation history.

However, there is a major limitation that makes persistent structured projects unreliable:

A user cannot designate a Project Source file as a mandatory authoritative operating source that must be retrieved before the model acts.

For example, I may have a file named:

Generalized-DnD-AI-DM-Runtime-Kernel-V1.2.md

and Project Instructions that explicitly say this file is the current governing runtime authority and that older versions are superseded.

I can delete V1.0/V1.1/V2 files, replace them with V1.2, update the Project Instructions, start a fresh chat, and use Project-only memory. Yet the model may still use obsolete architectural information from previous conversations instead of retrieving and following the current Project Source.

This creates a serious problem for persistent projects. Historical conversations are valuable because they preserve campaign events, dialogue, relationships, decisions, and continuity. They should not need to be deleted merely because the operating rules have changed.

Projects need a way to distinguish:

  1. Authoritative operating sources — files/instructions that govern current behavior.
  2. Historical contextual sources — previous chats and records that may supply facts but cannot override current operating instructions.

Suggested functionality:

  • Allow a Project Source to be marked Authoritative / Always Load.
  • Allow Project Instructions to specify required files that must be retrieved before responding.
  • Provide source precedence controls such as:
    Project Instructions > Authoritative Sources > Current campaign records > historical project chats.
  • Allow a source to be marked as superseding older versions.
  • Prevent historical chats from restoring obsolete instructions, workflows, or architecture when they conflict with current authoritative sources.
  • Provide a visible indication that required authoritative sources were successfully loaded.
  • If a required source cannot be retrieved, the assistant should fail explicitly rather than silently fall back to remembered or inferred behavior.

This would benefit far more than D&D campaigns. It would improve long-running software projects, research projects, legal/document workflows, organizational procedures, writing projects, operating manuals, simulations, and any project where rules evolve while historical context must remain available.

The solution to stop the recovery and usage of outdated or no longer relevant control data or information was to delete everything and start over. this means there is no way at the present moment to move forward with a new thought or reestablishing a fresh chain of thought that doest require the erasure or dependance on the integration of an ignorance protocol, rather than a fresh start it is a recursive redundancy patching over a negative rather than beginning on a positive.

The actionable rules of a project need to stay current an the only way to do this is to ad the source files in the project folder and the instructions in the projects settings be followed as the standard operation or prime source of the project. right now it is seeing the files in the source file folder as being present some as the information and instruction section in the project settings. It is programed only to see that they are there not that they are to be followed as authority in the function of the model. This means that users are truly not able to have any manful change in their projects because the old information is always in the chat history and that is the authority rather than the current file as required by the user.

You can see that this could be a huge problem with the use of your model in long term multi layered workflows controlling a multi million dolor project. I am not certain that I have expressed what needs to be done or what if anything is possible to be done, but if you have any thoughts or questions please respond.

2

I’ve been using a similar multi-chat structure for long-running projects, and I think your distinction — “Memory remembers the user; Project State remembers the project” — is an important one.

One complication I ran into after moving project state outside individual chats was that shared state alone wasn’t quite enough.

If several specialist chats can all read and update the same state, you eventually have to answer questions like:

  • Which chat is allowed to change which part of the project state?

  • What happens if one chat is working from an older state?

  • How do you distinguish a proposed change from an accepted project decision?

  • How does a fresh chat verify that it has recovered the current state before it starts making changes?

For some of my longer-running projects I’ve been experimenting with ChatGPT Projects as the working environment and Git/Markdown as the durable project state, with individual chats acting more like separate workstreams.

That has worked reasonably well, but the useful part turned out not to be Git itself. The important part was making the current state and update boundaries explicit, so one chat cannot silently overwrite decisions made elsewhere.

Your backend / licensing / client / testing example is very close to the kind of case where I’ve found this distinction matters.

3

Yes, that is a prime example of the situation I am trying to find a solution to.

My issue is that the threads run out of room and I have to continue my project into another chat thread within the project. The issue is that keeping the rules set and frame work as set and standard for each out put is the prime difficulty. The limitation of its access to the information is not enough if the model doesn’t use the current constraints as actionable only. it is like continually trying to build a stable house on a faulty foundation, it can’t work.

It only slows the models reasoning down my doing something, only to remember a moment later as it isn’t following the new instructions, that its out put was irrelevant and needs further editing before completion.

Having to do a hard wipe each time isn’t sustainable when a minor correction of the workflow or guidance instructions for the model to be edited. I have spent a lot of time talking to the model about its function and abilities, and I have come to the conclusion that the model only see the files we place in the project folders and the instructions we put in the projects settings as being present and that is it. The model explicitly said this to me, that it is not programed to read them or use them as operational guidance or parameters for its desired function as required but the user. It must be given direct commands from the user within the chat feature in order to use them as intended and then that only last for that one moment and it returns to default function. It repeatedly says it doesn’t store information or remember anything but try to get it to forget something.

so your work around was to have multiple chats running different idea to trains of thought?

4

This is exactly the problem I’m encountering with a long-running writing project.

I’m writing a multi-book fantasy series, and my Project contains manuscripts, chapter-by-chapter summaries, character information, world-building, history, and continuity notes. The problem isn’t simply storing these files; it’s making them reliably available as authoritative project knowledge across conversations.

For example, I’m currently writing Book 3. A character’s motivation or a plot mechanism may have been established in a Book 2 chapter summary months earlier. When I ask a continuity question in a new conversation, I need ChatGPT to be able to retrieve that Book 2 source material rather than reconstructing the information from conversational memory.

Ideally, I would like to designate certain documents as authoritative canon, distinguish them from brainstorming and drafts, and have ChatGPT consult the appropriate project sources when answering questions. If the authoritative sources don’t establish something, it should say so rather than filling the gap with a plausible inference.

For a multi-book writing project, this would make Projects far more reliable as a long-term workspace.

5

Not exactly. Multiple chats help separate workstreams, but the key for me has been keeping project state outside individual conversations.

I use ChatGPT Projects as the working environment and Git/Markdown for durable state — governing rules, accepted decisions, current progress, and recovery information.

When starting a new chat, I have it recover and verify the current governing files and project state before continuing, rather than reconstructing them from conversation history.

I’ve been testing this across several long-running projects, with encouraging results, though it’s still evolving.

For your V1.2 kernel, have you tried starting a fresh chat with only the current kernel and essential project records, without the old conversation history? That might help determine whether the problem is recovering the correct rules or following them once loaded.

6

yes I have tries that. the problem is that the memory limitation for accessing outside of the projects doesn’t work for information whiten the project and that means in the various chat threads within the projects section. chat will continuously carry the files it has created as working actionable files even if they are not in the source folder so I can’t get it to use only the current source folder even if I change threads.

7

I am also using it to help me write a series of books and it can’t keep consistent details and will not stay on task as desired for more than a few prompts at a time before I have to reinstate the directives. It isn’t sustainable as it is for long term projects it unfortunately is only a chat bot that gives one off responses and forgets what it was doing as soon as it has finished the out put. There is a huge gap between what it is and what they say it is capable of. I am not seeing the payoff for my subscription at this point.

8

That helps clarify the issue. Our setup is a little different, so perhaps it offers a useful comparison.

We use ChatGPT Projects as the working environment, with Git/Markdown holding the durable project state. Project Instructions provide a small entry point, while the runtime rules, current project state, and historical records are kept separately. New chats recover the current authoritative state before continuing, rather than relying on previous conversations.

We’ve been using this across multiple long-running research workstreams. Older files and conversations remain available as history, but they aren’t supposed to override the current authoritative state. When rules change, we update the relevant modules and their authority references rather than rebuilding the entire project.

I wonder whether part of the difference might be how your kernel and Project Instructions are structured. Simply declaring V1.2 authoritative may behave differently from explicitly requiring a new chat to load and verify the current version before doing any work.

Of course, this doesn’t eliminate ChatGPT’s tendency to reference older Project context, but it gives us a way to detect and correct conflicts.

It might be interesting to compare this structure with your current setup and see where the behavior starts to differ.

9

I am open to try any thing at this point. this is frustrating to the point it isn’t worth the trouble