Documentation rots
Written once, half-wrong within a year, and nobody knows which half. So people stop trusting it — and then stop reading it.
AI assistants forget your codebase every morning. This one doesn't — and it can prove what it knows.
A private, verified memory of a large codebase: every fact tied to real evidence in the code, re-checked as the code changes, and withdrawn the moment it stops being true.
Every session starts from zero. It's a brilliant new hire with amnesia — arriving each morning knowing the language but nothing about your system: which fix was already tried and failed, why that odd-looking code is odd on purpose, which path handles money.
Written once, half-wrong within a year, and nobody knows which half. So people stop trusting it — and then stop reading it.
What the system really does lives in a few people's heads. When they're busy, on holiday, or gone, it isn't anywhere.
Not in what the team works on daily — in the paths nobody has opened in a year, where surprises are most costly.
Put another way: AI knowledge is normally demand-driven — it accumulates where people happen to be working. This is coverage-driven. The quiet code gets read because it is there, not because somebody asked about it.
Mnemyra reads a codebase systematically — including the parts nobody has touched in months — and writes down what it learned. Each fact carries the evidence it came from, so it can be checked rather than believed. Then it keeps itself honest: as the code moves, those facts are re-checked, and one that no longer holds is withdrawn and flagged rather than quietly left to mislead someone.
The first look is next week's board.
It does not come back with a summary. It comes back with the traps, the patterns and the contradictions it found in each area — each one anchored in the code, each one either a thing to fix, a thing to decide, or a question only a person can answer.
Most of what a team knows is learned in the middle of doing something else. A memory that only grows when somebody runs a tool is a memory that stops growing the week everyone gets busy — so this one grows two ways, and the second needs nobody to remember it.
When a session works out something the memory does not hold, it writes it down — with the line of code it came from. Nothing is taken on the assistant's word: it lands as proposed, and a person accepts it.
The rule that keeps the first one honest: never propose what you did not verify. A guess with a citation attached is worse than silence, because the citation is what makes people stop checking.
Say something it knows differently and it says so, with the evidence, and asks which is right — rather than agreeing with whoever spoke last. Nothing anyone says flips settled knowledge on its own.
What people searched for and did not find is kept. The questions your team asks are the most honest map of what the memory is missing, and it is read that way.
When something can only be settled by a person, it asks — and then waits. It will not close its own question by reading harder, because that is the class of question reading cannot answer.
Point it at one area and it goes deeper there, without re-reading everything. The effort follows what you care about now, not the size of the repository.
The two halves answer different questions, which is why it needs both. The initial read covers the code nobody opens — the part no amount of daily work will ever surface. The day-to-day proposals cover the code somebody is opening right now, at the moment it is best understood. Neither half can reach the other's territory.
Every team has rules. Some are written in a decision record, some are enforced by a linter, some live only in the head of whoever has been there longest — and the gap between what a team decided and what its code actually does is where a newcomer does the most damage, politely and with good intentions.
So it reads both sides: what you declared — documents, lint and formatter settings, the type checker, git hooks, CI — and what the code does, counted rather than sensed. Neither alone is the answer. The pair is.
This is the convention, reported with how much of the code actually conforms — not a vague "we do it this way".
The rule you wrote is obeyed in two areas out of eight. Reported as the breach it is — never as though the rule holds, and never flipped into "the majority is the convention".
A concern solved several ways with none dominant. That is a finding, not a blank: somebody owes a decision, and until they make it every new module picks a side by accident.
The failure it refuses to commit is the tempting one: if a rule is broken often enough, a counting tool reports the breakage as the convention and tells the next person to copy it. A declaration outranks a majority. Drift is drift, however widespread — and that is precisely when saying so is worth the most.
Some things are true and are nowhere in the code. Whether a shortcut was deliberate, whether a pattern is still the intention — no amount of reading recovers an intent that was never written down. So it asks, and what a person answers is kept as what it is: a statement of intent, weighed above whatever the code happens to do most often, and never disguised as a fact about a file.
Instruction files tell an assistant how you want things done. Docs and decision records explain why you chose something. Search finds text that looks relevant. All of it is useful and none of it goes away.
None of it tells anyone what is actually true in the system right now — and that is the part that keeps being wrong.
| Answers | Comes from | When the code moves | |
|---|---|---|---|
| Rules / instruction files | "How we do things here" | Someone writing it down | Quietly becomes wrong |
| Docs & decision records | "Why we chose this" | Someone, at the time | Quietly goes stale |
| Search / RAG over the repo | "Which files probably relate to this?" | Similarity to your question | Still retrieves — and returns stale text just as confidently |
| Assistant auto-memory | "What we noticed while working" | Accumulates where people happen to work | Forgets on a timer; never covers untouched code |
| Mnemyra | "What is actually true, and how we know" | Systematic reading — including code nobody opens | Re-checks itself and withdraws what no longer holds |
The one worth stating plainly, because it is the first question every engineer asks: search and RAG retrieve text that looks relevant to your question. They take no position on whether it is true, hold no record of when it was last checked, and hand back a stale file with exactly the confidence of a current one. This produces the other half of the sentence — a claim, the evidence underneath it, the commit it was verified at, and a withdrawal when that stops holding.
It runs on a machine you control, on your network. No source is uploaded anywhere.
Each person's AI login stays theirs. Nothing is pooled, copied or stored by us, and no work runs on someone else's account.
People see what their projects entitle them to, and nothing else.
It feeds the AI tools your developers have open today, over a standard connection.
Re-checking evidence is ordinary computation, not an AI call. It keeps working regardless.
Run it on the AI capacity your team already has, or in your CI on your own key. Most teams end up with one of each.
Mnemyra runs in daily use on live production systems, where it has already found defects that reached customers.
What's being worked on now is the path for a second organisation to run it on their own infrastructure. I'm looking for one or two design partners — teams with a large, long-lived codebase who feel the cost of everything living in a few heads.