Why I’m testing a graph for long-term AI memory

Chat history works fine when the next question follows straight on from the last one. It gets awkward when you need to know, weeks later, why a project decision was made, which source backed it up, and whether it's changed since. A transcript is just statements in order. Search might hand back a durable fact next to an idea that got thrown out, or the current decision next to the one it replaced, and feeding all of that back into a model crowds the actual task with stale material. So I want the memory layer to store selected records, each with a type, identity, date, status and source link, and keep the conversation around for when someone needs the original context. What I'm testing is whether explicit relationships make those records easier to find and check.

I'm starting with a small set of record types: people, organisations, projects, tasks, decisions, claims and sources. The relationships carry most of the context. A person works on a project, a claim is supported by a source, a later decision supersedes an earlier one. I'll only create a node when it answers a question I already know I'll ask, like "what decisions currently apply to this project?" or "who owns this unresolved item?". Turning every noun in a conversation into a node would just add noise.

Each claim or decision should link to where it came from, whether that's a document passage, a task, a code change or a specific part of a conversation, with both the source date and the date the memory was created (they're often different). I'd also say what kind of support the link is: stating the fact directly, backing an inference, contradicting an earlier claim, or just mentioning the subject. If every link is "related to", the graph turns back into a pile. And where a source is private, a link to it doesn't make it visible to everyone, so retrieval has to filter both records and traversed sources for whoever's asking.

The memory will have mistakes in it. A name gets corrected, a project changes direction, an extraction misreads its source. For the records that matter (status, ownership, requirements, decisions), I'll keep corrections as events: mark the old claim superseded or disputed, link the replacement, and record when and why. Retrieval can prefer the current record while a reviewer can still follow the path. A graph doesn't decide what goes into a prompt, though. For a planning task I'd start at the project node and pull current decisions, open tasks, owners and recent sources, then use text search inside the linked material where it helps. I'll also log which records were retrieved, so when an answer's wrong I can tell a bad stored fact from a retrieval miss or a reasoning error.

The first test is one project, its decisions, the sources behind them and one correction, all checked by hand. Then the harder cases: two people with similar names, a component shared between projects, a decision with conflicting sources. Can I back the graph up and restore it, or delete records when policy says so?

That's why I'm testing a graph for long-term AI memory. I want to get back, weeks later, to who decided what on which project and based on which source, without wading through transcripts full of stale and replaced ideas. Whether it works comes down to whether the typed records and explicit relationships return the current decision with its source, and let me trace a correction when something was wrong. So for each test question I'll write down the records and relationships I expect first, then compare them with what retrieval actually returns before adding more history.