Answers
Should team knowledge for AI live in versioned files, or in curated memory?
Files in the repository — a CLAUDE.md, a skills folder, notes committed next to the code — are where most teams put what their AI should know, and they work for what a repository owns: conventions, commands, the shape of the code. What they do not carry is the part that changes and needs a person behind it — which rule is in force, who decided it, whether it is a proposal or settled, and whether the model actually received it. Arroway holds that part as product material: curated by people, ranked against the task, and delivered with a receipt saying how much fit.
A file is corrected by hand, and only after someone notices
A versioned file is only as current as the last person who remembered to edit it. Nothing tells you a line has been overtaken — a superseded rule reads exactly like a live one, and it keeps being followed until a human writes the correction. Arroway treats that as a feature rather than a chore: a memory has an explicit kill condition, a superseded memory points at what replaced it, and a proposal waits for a person instead of governing quietly.
A repository is a boundary, and half the team lives outside it
Knowledge in a repo reaches whoever works in that repo. The decision about pricing, the rule about what may be sent to a client, the reason a supplier was dropped — those belong to the same team and have no repository to live in, and the people who hold them often do not open one. Arroway scopes by project rather than by codebase, so a decision written by someone who never touches git reaches the assistant of someone who does.
Loading a file is not the same as knowing it arrived
A file is text placed in front of the model, and the amount of it that fits is not something the file can report. Arroway's read is ranked against the declared task and comes back stating the budget it used and what did not fit — so "the AI has the rule" stops being an assumption and becomes something you can check. That receipt is the difference between context that was sent and context that landed.
What it looks like in practice
A team writes its release rule into the repository's context file. Two months later the rule changes in a meeting, and the file is not touched — every assistant keeps quoting the old rule, correctly, from a file nobody thought was stale. The failure is not that someone forgot: it is that a file has no way to say it was overtaken.
Questions people ask about this
- Should we delete our context files, then?
- No, and Arroway does not ask you to. Files stay good at what belongs to a repository — how to build it, how to run it, the conventions of the code. What moves is the part that has a human behind it and changes without the code changing. Arroway's own repository keeps a context file for exactly that reason, and keeps rules and decisions out of it on purpose.
- Why not just commit the decisions too, with dates?
- You can, and teams do. What a committed file still cannot do is distinguish a proposal from a sanctioned decision, tell an assistant which of two conflicting lines is in force, or say how much of the file the model actually received. Those are the three failures this page is about, and none of them is solved by writing more carefully.
- What does a person actually have to do to keep this current?
- Review, not authorship. Assistants propose what they learned as proposals; a person sanctions, edits or discards them, and only what a human sanctioned governs. The work is judging a short list, not remembering to write things down.
Where this is verifiable
Product documentation on this site (How it works, Install) and the sanctioned product spec in the repository. The description of files-in-a-repository is about the practice, not about any vendor's product, and every property named here is one a plain versioned file has: no expiry, no sanction step, no delivery receipt. This page makes no claim about the built-in memory of any specific AI tool.
https://www.arroway.app/en/answers/context-files-vs-curated-memory