Answers
Doesn't a knowledge graph solve this by linking the facts together?
It solves a real part of it, and the part it solves is not this one. A graph is good at identity: it can work out that "the billing service", "billing-svc" and "the payments backend" are one thing, which a flat list of notes cannot. What it does not carry is authority. Link the facts about that service and the contradictory versions now arrive together — last year's retry policy beside this quarter's, connected, consistent and equally present, with no edge saying which one is in force. Arroway answers that question first: one entry is current, it names who approved it, and the one it replaced is retired with the reason attached.
Last updated September 16, 2026
Linking is identity; deciding is authority
These are different problems that look alike because both surface as the assistant getting it wrong. Identity is recognising that two names refer to one thing, and a graph is the right tool for it. Authority is which of several true-sounding statements the team stands behind, and no amount of structure produces it, because it is not in the data. Someone decided, and unless that decision was recorded as a decision, there is nothing for the graph to represent — it can only show that both statements exist and are about the same subject.
Connecting contradictions makes them arrive together
There is an uncomfortable middle stage worth naming, because teams reach it and read it as the graph failing. Before linking, the stale fact and the current one were disconnected, so retrieval usually surfaced one of them and the collision stayed hidden. After linking, both come back, correctly, as facts about the same entity. The graph did its job exactly. It turned an invisible inconsistency into a visible one, and a visible contradiction with no resolution rule still leaves the assistant to pick — usually by recency, which is not the same as by decision.
Currency has to be written when the decision is made
The reason this cannot be inferred afterwards is that it is a fact about the world, not about the text. A statement is superseded because a person chose to supersede it, and that choice leaves no trace in the wording of either version. So it is recorded at the moment it happens: a new decision names the earlier one it contradicts, the earlier one is retired with the reason on its line, and every entry carries the condition that ends it. What an assistant reads is the current answer, while the history stays available to a person who wants to audit how it got there.
What it looks like in practice
A team builds a graph over their engineering notes, and it works well. It resolves that the service called "ingest" in one document and "the event pipeline" in another is the same component, and queries that used to miss now find everything about it. Everything about it is the problem. The subgraph for that component holds a note from the original design saying events are retried three times, a runbook from the incident review saying retries were dropped to one, and a proposal to move to a dead-letter queue that was written up thoroughly and never adopted. All three are genuinely about that component, and all three are linked correctly. An assistant asked about retry behaviour now has three connected, mutually contradictory answers and no basis for choosing except how recently each file was touched — which, because the design document was reformatted last month, points at the oldest one.
Questions people ask about this
- Couldn't we put timestamps on the edges and take the newest?
- Recency approximates it and fails in the cases that matter most. A decision reaffirmed in passing looks newer than the deliberate one that set it; a document reformatted or migrated gets a fresh date without its content changing; and a proposal written after a decision is newer than the decision it was rejected in favour of. Recency answers when something was written, and the question is what the team stands behind — the same thing only when nobody has changed their mind.
- What if the graph records who said what?
- That is closer, and it is provenance rather than authority: knowing the author is not knowing whether the team agreed. The missing piece is an explicit act — someone with standing on that project marking this as the version that governs, and what it replaced. Once that act exists, the ordering stops coming from the structure and starts coming from the decision, which is the whole of the argument here. A graph can hold such a record perfectly well; it just does not produce one on its own.
- So is the structure useless?
- Not at all, and the distinction is worth keeping clean. Resolving that several names mean one thing is genuinely useful, and the record here is scoped by project for a related reason — so material about one client's work is not served into another's. What structure cannot do is the ranking that comes after: of the things it correctly gathered, which one holds. That answer comes from a person, once, and is then read by everyone.
Where this is verifiable
Product documentation on this site (How it works, Install), the answer on why retrieval does not replace sanctioned memory for the recovery side of the same objection, and the supersession, 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/the-graph-links-facts-it-doesnt-decide-which-is-current