Show IH: I lost three weeks of AI context in one mistake. So I spent over a year building a local memory forest. (Mac only)
Every AI conversation I've had since GPT-3.5 felt disposable.
I once recorded three full weeks of AI work — architecture decisions, debugging sessions, trade-offs — into PostgreSQL through MCP. Then the Docker container was accidentally wiped. No Time Machine recovery. Three weeks of context, gone forever.
That was the moment I stopped treating AI conversations as disposable.
I'm Iz_JP — I've been building things for clients (music, video, web) for over 30 years in Japan. About a year and a half ago, I started building something strictly for myself. I've rebuilt it more than ten times since.
If you're deep into Claude Code, Codex, Cursor, or local LLMs, you probably know this feeling. You spend hours in a deep conversation. Then: "Context limit reached." Or worse — auto-compacted into a summary. They save the conclusion. They destroy the journey.
What Organiee does
You just talk to your AI. Say "Record it," and the conversation becomes a tree — searchable, connected, yours to keep.
- Records your AI conversations locally — plain Markdown files on disk, plus a SQLite search index
- Connects to MCP-compatible clients — tested with Claude Code, Claude Desktop, OpenAI Codex, Cursor, and local LLM apps
- Searches your entire conversation history, including months-old discussions
- Everything stays on your Mac. Optional sync uses your own iCloud — never our servers. No lock-in.
- Now a native Mac app — signed, notarized, no terminal maze, no fragile setup.
With thousands of records in the forest, the next AI can answer from more than the current session — with the weight of the history you've built. The difference between a handful of trees and a forest is the difference between knowing and understanding.
This app was finished inside itself
This post was developed across multiple AI models and sessions. Auto-compacting happened repeatedly — but every decision was recorded in Organiee, so each new session could search the full history and continue where the last one left off.
In the final week before launch, the Mac app itself was finished inside Organiee Rooms. The implementing AI lost its working memory twice to context compaction, and recovered both times by searching the forest it was helping to build. Its first-person account now lives in my forest, alongside over 4,700 records and 60+ Rooms — including the one where this launch post was written.
That's not a pitch. That's what happened.
Rooms
A Room brings several AIs into one shared workstream. One implements, another reviews, a third tests. They keep handing work back and forth across multiple cycles, while the decisions and history stay in the Room. No agent framework. No loop configuration to maintain.
You could build the loop yourself. You shouldn't have to maintain it.
The other side of the context war
Right now, everyone is solving context from the AI side — bigger windows, better RAG, agents, skill files. Vendors ship memory features too. All of it lives inside one vendor's world.
Still within a session. Still not yours.
Organiee solves it from the human side: a memory you own, on your own disk, that any AI can walk into.
Most note tools let you collect. Organiee lets you continue.
What do you do today when an AI session ends before the work does?
Plant 100 trees for free. I dare you to stop there.
→ organiee.com (Mac only)
The "lost three weeks of AI context" part is honestly the strongest part of the story.
It's not just a technical problem — it's a painful moment almost every AI user can understand: putting in effort, building context, and then suddenly losing the thing that made the workflow valuable.
A lot of products explain what they built, but the best ones start with the frustrating moment that made the product necessary.
I'd make sure that story stays front and center because it creates instant understanding before anyone even sees the features. People connect with the problem they have felt, not just the technology behind the solution.
Losing three weeks of AI context must have been incredibly frustrating, especially if that context included decisions, research, and work that would be difficult to recreate. I can understand why that experience pushed you to build a local solution instead of relying completely on one platform. The privacy angle is also interesting for people working with sensitive projects. Does the memory forest work across different AI tools, or is it currently designed around one specific workflow?
Cross-tool is the design, not a side effect. Organiee runs as a local MCP server, so MCP-capable clients can plant and search the same forest — Claude Desktop, Claude Code, Cursor, LM Studio, and others. The forest itself is plain Markdown plus a local SQLite search layer on your Mac; it doesn't belong to any one AI client.
That's my daily use: AIs from different vendors reading the same records, picking up work from one another. Organiee does not operate a cloud that stores your forest — the files stay on your Mac.
One privacy boundary matters: when you talk to a cloud AI, what it reads passes through that provider. For a fully local workflow, pair Organiee with a local model like LM Studio.
Lost a chunk of context on a client project the same way, mid session with no clean way to reconstruct what the agent had already decided versus what it just happened to write. What actually saved me wasn't a memory system, it was treating every commit as the real source of truth and re deriving intent from the diff instead of trusting whatever the agent's last summary claimed. Curious how your forest handles the case where the agent's own notes about a past decision turn out to be wrong. That's the part memory alone doesn't fix.
That's exactly the boundary: Organiee preserves what was recorded; it doesn't make it true.
Trees are immutable. If a Tree later proves wrong, I add a correction as a new Tree that cites the earlier one instead of editing it away. A later AI can inspect the original claim and the correction trail together. The wrong Tree remains as evidence of what was believed at the time.
I agree with treating the commit as the source of truth for implementation. That's also how I use Organiee alongside Git: when I commit, I routinely ask the AI to preserve the surrounding context as a Tree or in a Room. In autonomous Rooms, the agents often log commits themselves as the work progresses. Git is the source of truth for what was implemented; the forest is the source of truth for the design history — why it was chosen, what was rejected, and what was later corrected. They are sources of truth for different layers, not competing ones.
Judgment still belongs to the reader, human or AI.
The origin story is the strongest part of the pitch — the whole thing exists because a Docker wipe ate three weeks with no recovery. Which is exactly why I'd lead with durability even harder than the feature list. Plain Markdown + SQLite on disk is the right call (I build offline-first, and "your data is just files you can read without my app" is a real trust unlock), but the failure mode you're solving for is data loss, and local files can still be lost the same way — no Time Machine, a bad sync, a corrupted index. What's the recovery story when the SQLite index and the Markdown disagree, and can someone rebuild the whole forest from just the Markdown if your app disappears? Nail that answer and it becomes the reason to trust it, not just a feature bullet.
Fair questions. There are three recovery layers.
First, the forest’s records, notes, and local database live as ordinary files under your home folder. If Time Machine is enabled and that folder is included, it can back up and restore them like other files. That is why I switched from PostgreSQL to SQLite: the three weeks that started this project were lost inside a Docker container that Time Machine could not recover.
If only the full-text index is damaged, a connected AI client can run Organiee’s index maintenance tool to inspect, backfill, or rebuild it from the local database. Organiee also includes optional Cloud Sync, which is not part of Organiee Free. Once sync has completed, another Mac using the same serial and the same iCloud account can reconstruct a searchable forest from that mirror. The same serial supports up to five Macs. Sync is not a substitute for an independent backup.
If the app itself disappeared, the records would remain dated, human-readable Markdown, and the notes would remain readable Markdown too. If Cloud Sync had completed, each Room timeline would also remain as a readable Markdown file in iCloud. What would not recreate itself is the searchable, interactive experience.
The code is closed. Your memory is not.
Lived a much smaller version of this today — kept re-explaining the same project context to an AI every session, so I finally wrote it all down once and started using a persistent memory tool instead of relying on my own. Nowhere near the scale of what you built (three weeks lost is brutal), but same root problem: conversations that don't survive the session are expensive in a way that's easy to underestimate until you actually lose something.
The strongest part of this is not local storage, it's vendor portability, and the post buries it under the tree metaphor. Every model vendor will ship memory, and none of them will let you carry it to a competitor, so lead with that. One thing I'd test: your buying trigger is the moment someone loses context, so a lightweight import of existing Claude or Cursor history would let people feel the value before they have a loss story of their own.
Right now I just dump a "state of things" markdown file at the end of every session and paste it back in at the start of the next one — it works, but it saves conclusions and loses exactly the trade-offs I end up re-litigating a week later.
The part I'd want to test first is search across months-old records, since my handoff files are only ever useful for about two days before I stop trusting them.
You’ve named the exact failure I built this around: a handoff summary preserves the conclusion, but often drops the reasoning that made it trustworthy.
Organiee keeps whatever goes into a Record word for word. In a normal chat, you choose the scope each time — a decision, a specified stretch of dialogue, or several Records from one long conversation. The title, summary, and recall keywords are added on top, never instead. If you want everything to stay without deciding the scope each time, use a Room, where every post remains by design.
And yes—months-old retrieval is the real test, and I can’t honestly compress that into a day-one demo. My current forest has 4,700+ records spanning roughly nine to ten months. Across earlier versions I’ve created more than 10,000 over about a year and a half, but I deliberately kept those older versions out of the current forest. That’s the scale at which I use Organiee every day; your own test will still take time. The first 100 Trees are free at organiee.com.
"Everyone solves context from the AI side; Organiee solves it from the human side, a memory you own that any AI can walk into" is the whole product in one line, and a genuinely sharp wedge. Worth pulling out for anyone reading, because it's a structural bet, not a feature: every vendor memory feature is trapped inside that vendor's walls, and no vendor will ever build memory that spans competitors, because that helps you leave. The neutrality is the moat. OpenAI won't build memory that works in Claude, so the cross-vendor space is yours by default.
The honest tension, as a peer: your wedge is defensible against vendors, but the thing that makes it valuable (owning your context) also makes adoption hard. "Say record it and it becomes a tree" is friction, however small, competing against a vendor's zero-effort native memory that's just on. Vendor memory is worse and trapped, but automatic. Your bet is that people value ownership enough to do one deliberate thing. For power users who've been burned (your origin story), yes. For everyone else, native "good enough and free" is the real competitor, not other note tools. You're selling to the burned, not the general user, at least first.
Which points at positioning: lead harder with the loss. Your three-weeks-gone story is more persuasive than any feature list, because it makes the reader feel the pain of trusting disposable context. The ones who've felt that convert instantly; the ones who haven't won't care until they do. Sell the scar, not the forest.
To your question, what I do when a session ends before the work does: I lose it, and paper over it by re-explaining context to the next session, exactly the tax you're describing. That re-explanation cost is invisible until someone names it, and naming it is your best marketing, it's the moment a reader realizes they've been paying it for months.
Genuinely thoughtful build, and "they save the conclusion, they destroy the journey" is a line that'll stick.
Thank you — the idea of a re-explanation tax is what I'm taking away from this.
You're right that people who have already been burned feel the urgency first. That's where I'm starting, because I was one of them. But I don't want the product's meaning to end at the loss.
I care deeply about cross-vendor neutrality, but I think of it as a design principle, not a prediction about what vendors will never build. The part I can stand behind is simpler: the records are plain Markdown files on your disk, usable beyond any single model vendor.
"Sell the scar, not the forest" is half right for me. The scar makes the problem visible; the forest is the lasting value. The scar explains the first tree. The forest explains why you keep planting after the emergency is over.
And yes, "Record it" is deliberate. It keeps the human present at the moment a conversation becomes memory. Thanks for reading the product closely enough to see that tension.
The disposable conversation problem is real — I use Claude Code daily and every session is one
exitaway from losing the entire context. Today alone I built a Japanese job interview AI tool, redesigned a landing page, migrated 5 products to a new payment processor, and added analytics to 4 sites — all across multiple Claude Code sessions that don't share state. My workaround is crude: I save key decisions as Markdown files in the project folder.The memory forest concept is interesting — but my hesitation is whether the retrieval quality justifies the local storage overhead. How does it handle partial recall? Like "what was the reasoning behind that pricing decision last week?" vs "show me everything about the Creem migration." If it nails that fuzzy retrieval, I'd install it tomorrow. Mac-only is fine for indie devs — most of us are on Macs anyway.
Your two examples are actually two different kinds of search.
"Show me everything about the Creem migration" is a direct topical search. With Search Compass, Organiee can also group the related records into a dynamic cluster.
"What was the reasoning behind that pricing decision last week?" is the harder case — and the one I built it for. I have 4,700+ records now, and I rarely remember exact titles or wording. When a record is created, the AI also writes recall keywords: phrases a future you might naturally try. If the first query still misses, Organiee can return nearby records explicitly labeled as neighbors, not answers, so the AI can use them as clues and search again.
That is not only a design claim. Recently, an AI investigating one of Organiee's own subsystems used a poor query and got zero direct hits. The labeled neighbors still led it to the exact records it needed.
The honest limit is that the reasoning has to have been recorded. You already save key decisions as Markdown, so you have the important habit. Organiee automates the index card and lets different AI sessions search it later.
There's no embedding model or vector database: the records are plain Markdown and the local search index is SQLite. The free 100 trees are for exactly this test — organiee.com. Try both searches on your own work. If Organiee cannot recover reasoning you know you recorded, don't plant tree 101. Just tell me what failed — I'd genuinely want to know.
Wow !! A local memory forest
saving the conclusion but losing the journey is the part that stings. handing specs through mcp in bunzee, the why behind each decision always drops. does search pull that back too?
It can — if the "why" was preserved. And there's an important distinction.
A normal "Record it" does not automatically save every turn of the chat. The AI turns what you chose to preserve into a structured Record — and what goes in stays word for word; structure is added on top, never instead. Search can bring back the reasoning that made it into that Record. If I want the dialogue itself preserved too, I ask for that explicitly.
For the complete path — rejected approaches, exact wording, and the argument before the decision — I use a Room, where every post remains. A Record preserves the crystallized "why"; a Room preserves the trail. Both can be searched later.
So the honest limit is: Organiee cannot recover reasoning that was never recorded. But it gives me two ways to keep the journey from collapsing into only the final spec.
that's a useful split. record for the crystallized why, room for the whole trail. and yeah, nothing recovers what you never wrote down.
The three-week loss is the inflection point nobody talks about. Most people experience lost context as a minor inconvenience. But for knowledge work (architecture decisions, debugging sessions, API design patterns), three weeks of lost context can reset your entire approach.
What's interesting is that you didn't just rebuild the same thing—losing the context forced you to solve a different problem. That's a genuine insight: the value isn't just "preserve old conversations," it's "avoid architectural regression when context gaps force you to re-solve problems."
For anyone using Claude/ChatGPT for extended projects, this is the real risk. The platform's context window is huge, but durability across sessions is zero. Local-first seems inevitable for serious work.
"architectural regression" — that's the phrase I didn't have, and it precisely names one of the engineering costs.
For me, though, the deeper loss wasn't the decisions — it was the context itself. Those three weeks were lived: the exchanges, the connections, the whole experience of that time. No rebuild can give that back. What the ten-plus rebuilds since have changed isn't what I record — it's how the context is protected. The fire changed where I keep the records; it changed nothing about what I record.
You're right about the real risk: the window is huge, but durability across sessions is zero — and no amount of window growth touches that.
Records being immutable is right, but what happens when the decision itself changes? If I recorded "use approach A" three months ago and now the answer is "actually B, A had a bug," does search surface both with a clear signal of which one is current, or does it just return the closest match and let the AI figure out which is stale from context? That's the failure mode that scares me more than losing records: not missing history, but confidently retrieving the wrong slice of it.
You found the failure mode I worry about most. Honest answer first: Organiee has no hidden "current truth" flag, and a topical search cannot guarantee that A and B will appear in the same view.
Corrections never overwrite. When A turns out to be wrong, "actually B — A had a bug" is written as a new record that explicitly cites A and explains what it supersedes. The old record remains as evidence of what was believed at the time. Searching A's record ID can then find later records that cite it, so the correction trail is walkable in both directions.
The safeguard against confident wrongness is that search does not pretend its view is complete: each result set reports when matching records remain outside the current view, and fallback results are labeled as neighbors rather than answers. The AI still has to follow the correction trail and decide what is current — and that is deliberate. Newest does not mean truest: B may later need a C. That judgment belongs to a reader following the whole trail, not to a timestamp.
Stale retrieval is still possible; what the design tries to prevent is stale retrieval presented with silent certainty. That also depends on corrections being recorded as corrections — as the AI is instructed to do. I planted one this week.
That last line is the load-bearing wall though: the whole trail depends on the AI reliably writing the correction as a correction. Nothing stops it from dropping a fresh unlinked note instead when it's in a hurry, and now you have an orphaned belief with no citation back to what it replaces, indistinguishable from ordinary content until someone notices the gap. Anything that flags "this record talks about the same subject as an existing one but doesn't cite it," so a missed link surfaces itself instead of waiting to be found?
Ah, yes — you mean a write-time guard. No, Organiee doesn't have one, and I don't plan to put a semantic gate in front of recording. Multiple records about the same subject are normal in the forest; similarity doesn't necessarily mean that one replaces another. I let the storage layer keep them and leave that judgment to the model reading the records later.
At this point, I think trying the actual workflow would tell us more than designing that guard in the abstract. The Mac version is free for your first 100 trees if you'd like to test it.
Fair, that's real design feedback vs speculation from me. Deferring the judgment to read-time instead of gating writes makes sense once I think about it, a false-positive gate would cost you legit records. Appreciate you walking through the reasoning, and the offer.
I can relate to this. Losing important AI context is frustrating, especially when a project spans multiple sessions. Keeping a local, searchable history sounds like an interesting approach, particularly for long-term development work where the reasoning behind decisions matters just as much as the final result. Curious to see how it evolves over time.
This resonates. I went the opposite direction with my own stuff: tools that can't talk to a server even if they wanted to. Everything runs in the browser, no upload, no API call. The "lost your context" problem only exists when the context lives somewhere you don't control. Treating local-first as a hard design constraint (not a feature) eliminates a whole category of bugs along with the privacy question.
Curious if you considered a browser extension or web app substrate instead of Mac-native — would've been a smaller build, but cross-platform from day one.
Respect — "can't talk to a server even if they wanted to" is a harder line than mine, and I like it.
I did consider the browser. But a purely browser-based substrate would break two constraints I cared about: native AI clients and terminals need a local MCP endpoint, and I wanted the memory to remain ordinary files on disk rather than storage owned by a browser sandbox. A browser extension could bridge that through a native companion — but then I would still be shipping and maintaining a local component.
Once a local component was unavoidable, a native Mac app became the most honest scope for one developer: the platform I use every day and can test end to end. It also let installation feel like installing an ordinary app: download, drag, enter your serial, and Organiee connects itself to your AI clients. No npm, no config files to edit, no terminal. People who never open a terminal deserve a memory system too.
There's also a purely personal reason: I wanted my memory to have its own door — a dedicated app I could open, rather than another place among everything else my browser already does.
The records remain plain Markdown, with SQLite as the search index. Mac-only today is a scope decision, not an architectural dead end: I'm proving the experience on one platform first, and the core is kept portable so Windows and Linux remain possible if enough people want them. Either way, the records are designed to outlive the engine that reads them. The longer version of that bet: https://organiee.com/field-notes/what-survives/
What resonated with me is the distinction between preserving answers and preserving how those answers were reached.
When the reasoning survives, a new session can inherit more than context—it inherits judgment. That feels like a very different direction than simply making context windows bigger.
"It inherits judgment" — you described what I built better in three words than I did in 550. Thank you.
I appreciate you saying that.
I'd be interested in continuing the conversation by email if you're open to it. What's the best email to reach you on?
The idea of preserving the journey, not just the conclusion, is the part that stands out to me. Auto-summaries are useful for continuing quickly, but they often remove rejected ideas, trade-offs, and the reasons behind important decisions.
Right now, I usually rely on a mix of project notes, Git history, and manually written handoff files between sessions, but it still feels fragmented.
Keeping the memory locally and making it accessible across different AI tools seems especially valuable. How do you handle relevance once the forest becomes very large? Is retrieval based mainly on semantic search, or do Rooms and tree relationships also affect which records are surfaced?
Great question — and your current stack (notes + Git history + handoff files) is exactly the instinct this grew out of.
The honest one-line answer: nothing that isn't recorded can be found — and everything that is recorded, the search can now dig out one way or another. That second half took a year.
On relevance at scale (4,700+ records in my own forest today): the heavy lifting happens at write time, not query time. When an AI records a conversation, it also writes the retrieval metadata — title, TL;DR, tags, and the part that matters most: recall keywords, the phrasings a future searcher might actually use. The librarian writes the index card at shelving time, while it still holds the full context.
Retrieval itself is lexical — a local SQLite full-text index over the records; no embeddings, no vector database. The pipeline falls back when a query misses, and labels those results "neighbors, not answers" instead of pretending. The semantic step happens in the model reading the results: it sees titles and TL;DRs, decides what matters to the current question, and pulls full text only for those. A model judging "is this relevant to what we're doing right now" beats any fixed vector distance — and it gets better every time your model does.
Rooms are a parallel layer, not a ranking signal. Records are immutable; Rooms hold the process that produced them — rejected ideas, trade-offs, the argument before the decision — and you can walk from a record back into the Room behind it. The forest is where records sleep; a Room is where the right ones are already awake.
And when the search finds nothing, it says so — with a note on how many records are still sleeping outside the current view — rather than returning confident noise. At 4,700 records, that honesty has mattered more than any ranking tweak.
The longer philosophy: https://organiee.com/field-notes/wasnt-it-something-like/ — and your handoff files aren't wrong, by the way. They're a forest maintained by hand. The difference is only who does the planting.
That write-time indexing approach makes a lot of sense. I was assuming relevance would mainly be solved at query time, but generating recall keywords while the full context is still available is a much stronger design.
I also like the distinction between records and Rooms—the result stays immutable, while the reasoning process remains traceable. And labeling weak matches as “neighbors, not answers” is a great trust decision.
Thanks for the detailed explanation. This gave me a much clearer picture of how the system scales without embeddings.
Losing three weeks of context is brutal — I've had a smaller version of the same thing: a session-compacted summary kept the conclusion but dropped the reasoning behind it, and an agent that picked the work back up later re-derived the decision wrong. The "save the conclusion, destroy the journey" line is exactly the pain. What finally worked for me was treating the repo itself as the memory — every decision gets a commit that says why, and the agent rules file pins the non-negotiables so a fresh session doesn't have to re-infer them. Local-first searchable history would have saved me a few of those re-derivations. Curious how you handle stale records — when a decision recorded months ago gets reversed later, does the search surface the new one first?
I don't keep the session. At each phase boundary I flush what's durable into a roadmap doc in the repo, in a fixed shape (done, in progress, next, decisions with their reasoning, known unknowns), and then treat the conversation as disposable on purpose. The next session starts from the doc, not from a transcript.
Where that beats a memory store, and it's the axis I'd push on: the doc lives in the same repo as the code, so the commit that changes behaviour edits the reasoning in the same diff. A decision can't quietly outlive the thing it was about. A verbatim record has the opposite property. It preserves the journey, which is your whole pitch and a real gain, and it also preserves the reversed decision at full confidence forever, sitting next to the current one, both retrievable, both reading as true. eddzsh asked the near version of this, and I'd sharpen it: at 4,700 records the failure mode isn't a wrong note, it's a superseded note that doesn't know it was superseded.
Where the doc is worse, and why I'd still try yours: it's lossy by construction. I write the conclusions and the reasoning I judged load-bearing at the time, and I lose the trade-offs I didn't think mattered, which are exactly the ones I re-litigate a week later (NovelCaptcha's point). Git history recovers some of it, but a diff of a summary is not the argument that produced it.
If a Record could carry a supersedes pointer, so recall surfaced "this was true, here's what replaced it", I think that closes most of the gap.
The phrase "Record it" is the part I would pressure-test. Clear capture is nice, but people forget right before compaction or when a debugging session gets messy. I built DictaFlow around fast voice capture, and even then I would want automatic checkpoints tied to a commit, branch change, or context warning. Let the user prune bad memories later, but don't make remembering to save the work another task.
Eighteen months and ten rebuilds before showing it to anyone is the expensive way to learn, and I would spend the next 30 days watching five strangers try to record their first session. The stronger sale is not nostalgia for lost sessions, it is that local-only means the transcripts never leave the machine, which is the answer regulated teams need when legal asks where their AI conversations live. Mac-only plus own-your-disk is a beachhead inside firms that already ban cloud AI tools, and those buyers pay per seat instead of planting free trees.
This resonates with me. Losing context halfway through a long AI session is frustrating, especially when the reasoning process is as valuable as the final answer. I like the idea of preserving the entire conversation in a searchable format. I'm curious—how do you handle branching conversations without them becoming difficult to navigate?
The wiped container is the loss everyone can see. With a permanent local archive I'd worry more about a quieter one: a record that was fine to write and can't be read correctly later.
The failure that unsettled me most this year wasn't a crash or a wrong answer. It was a mid-session blank — the session hiccups, drops what it was holding, and comes back confidently talking about a different conversation. No error, no hedge. It sits next to what people call drift, minus the gradual part; the confidence is the only symptom.
Why that matters here: marc_kumiko123 asked about the record that turns out wrong — "use A," when B is the real answer — and your system has a slot for it, a new record citing A and what it supersedes. A session that had already lost the plot produces something with no such slot. The reasoning is coherent, the trade-offs articulate, and nothing gets flagged later, because on its own terms it isn't wrong — it just belongs to a conversation you weren't having.
I do notice at the time; the confident non-sequitur is obvious live, which is why I kill the session on the spot. What doesn't survive is the noticing. An hour later it exists nowhere, and those records shelve like the good ones.
So the live decision looks like a write-time one, not a search one — you described the librarian writing the index card at shelving time. Can a record carry what the human knew about the session when it was written? Not the model rating itself; whatever just drifted is the worst judge of that. Just somewhere to put "this stretch was suspect" while it's still known.
It wouldn't cover a session nobody caught live, and I don't think anything does yet, mine included. But it seems worth deciding before the count grows, because it isn't retro-fittable — at several thousand records you can't reconstruct which hour was the bad one.
You're asking whether a Record can preserve the human's judgment about the session — not just the session's words. That's a real distinction.
Organiee doesn't ask the model to grade its own reliability. If I notice that a session has drifted, I can leave that stretch out of a Record, or preserve a separate warning that names the affected Record or period. In a Room, the suspect posts remain, and a later warning can sit beside them rather than silently rewriting them.
If that warning names the affected Record's ID, it can be found later by searching that ID. But that is a workaround, not the write-time trust signal you're describing: a topical search does not guarantee that the warning and the affected Record will surface together. Organiee has no dedicated "suspect" marker today, and it cannot detect drift nobody noticed.
The important evidence in your example is the human noticing — and that can be recorded while it still exists. You've given me a useful distinction to think about: sometimes what needs recording is not what the session said, but the moment I stopped trusting it.
Organiee can preserve that human observation, but it does not currently guarantee that the warning will accompany every later reading of the affected Record.
The distinction you've landed on records as immutable evidence, plus corrections that explicitly cite what they supersede is a lightweight provenance model, and it's the piece most 'AI memory' tools skip entirely. Most competitors treat memory as a single mutable blob (a rolling summary, a vector store you overwrite in place), so when a decision changes, the old reasoning just quietly vanishes. You're keeping the 'why' next to the 'what,' which is the harder and more valuable problem, and the 'neighbors, not answers' labeling is the right kind of honesty; false confidence is worse than an empty result.
One thing I'd push on: this is still pull-based; someone (or some agent) has to think to search the forest before the relevant history shows up. The failure mode marc_kumiko123 flagged gets worse as the forest grows, precisely because nothing surfaces itself before you ask. Have you experimented with a proactive layer, something that looks at what you're about to work on at the start of a session and surfaces the 3-4 most relevant prior decisions, correction trail included, before a single query is typed? That's a materially harder problem than search, but it's the difference between a forest you have to walk into and one that meets you at the door.
"I accidentally lost three weeks of AI conversation context, so I spent over a year building a Mac app that stores and organizes AI memories locally in a 'memory forest,' making them searchable, persistent, and private."
This comment was deleted 4 days ago.