Answers
Why not just run RAG over our repository instead of another AI memory tool?
Because retrieval and sanction answer different questions. RAG finds the passages most similar to what was asked, out of everything it indexed — including the decision the team reversed last quarter, the design that was never built, and the two documents that contradict each other. It has no way to say which of them is in force, because nothing in an index carries that. Arroway holds a much smaller set: the rules and decisions a person on the team approved, each with the name of who approved it and the condition that ends it. An assistant reads that set before it acts. Retrieval still finds text for you; it is not what tells the assistant which text still counts.
Last updated September 4, 2026
Similar is not the same as in force
Retrieval ranks by resemblance. Ask about retry policy and you get every passage that discusses retries — the current runbook, the version before it, the thread where someone argued against it, the incident review that proposed a fourth option. All four look equally relevant to the query, and the wrong one is often the longest and best written, which is exactly what ranks well. Finding the text is rarely the team's problem. Knowing which of four texts the assistant should obey is, and that is a question about authority, which resemblance cannot answer.
Somebody has to say yes
Here an assistant can propose a rule, and a proposal governs nothing. It stays a proposal until a person on the project approves it — and if they refuse, the refusal is recorded, so the same suggestion does not return next week as though nobody had seen it. That approval step is the whole difference: what an assistant reads has been through a human decision and carries the name of who took it. An index has no such step and nowhere to put one, because nothing inside a document says whether the team agreed with it.
Norms expire; documents read the same forever
A decision taken for one quarter, a limit that was raised, a rule that only applied while a migration was running — each stops being true at some point, and the document describing it goes on reading exactly as it did. Every memory here carries the condition that ends it, and a rule that has been superseded is replaced by the one that replaced it instead of sitting in the index beside it. What an assistant receives is the current answer, not a history of answers with the current one somewhere inside.
What it looks like in practice
A platform team keeps its engineering docs in the repository and puts a retrieval index over them. It works well for questions like which region a service runs in. Then a new engineer asks their assistant how to handle a failed payment retry. The index returns three passages: a design doc from an approach the team abandoned, the runbook that replaced it, and an incident review that argued for something else. All three live in the repository, all three are about payment retries, and the abandoned design doc is the longest and most detailed — so it comes back first. The assistant follows it. Nothing malfunctioned; the index did what an index does. What was missing was a place where somebody had written that the abandoned approach is abandoned, in a form an assistant reads before it answers. That is one sentence, and it is not the kind of sentence anyone thinks to put in a document — because everyone who abandoned the approach already knows.
Questions people ask about this
- So should we switch retrieval off?
- No, and that would be the wrong read of this. Retrieval is good at what it is for: locating a passage in a large body of text nobody has read recently, pulling up a reference, searching an archive. Sanctioned memory is for the short set of things an assistant has to know before it acts, whether or not anyone thought to ask. A team running both is not duplicating anything — it is keeping search apart from standing rules.
- Couldn't we get the same result with better filtering over the index?
- You can filter an index, and teams do — by folder, by date, by tag. What filtering cannot recover is who agreed. Sanction is a fact about a person's decision, not a property of a document, so it has to be recorded when the decision is taken, by the person taking it. Once that record exists, the assistant no longer has to be told which passage to trust: it reads the set that was approved.
- Our decisions are already in the repository. Isn't that enough?
- It is a good place for the ones that belong to the code, and the comparison between a context file and curated memory is its own answer on this site. What a repository does not hold is the decision nobody wrote as a document — the call taken on a Tuesday that changed how the team scopes work, the exception a customer negotiated, the approach someone tried and rejected. Those never become files, so no index can find them, and they are the ones an assistant gets wrong most often.
Where this is verifiable
Product documentation on this site (How it works, Install), the answer on context files versus curated memory for the file-based comparison, and the sanction, provenance and expiry rules in the sanctioned product spec. Everything described here is behaviour the tools apply today, not roadmap.
https://www.arroway.app/en/answers/why-rag-doesnt-replace-sanctioned-memory