How do you keep a codebase knowledge graph from going stale?

Make the merged change the unit of updates. Capture the files that changed, a short decision summary, and links to review discussions that explain the reasoning. Review comments can be especially useful when the explanation never made it into documentation.

The tricky part is handling renames, reverts, and decisions that replace older ones. A nightly re-index can catch drift, but I wouldn't rely on it as the only update path if the graph is used throughout the day.

Don't assume you need to refresh every corner equally. Track what people and coding tools actually retrieve, then prioritize those areas when related changes merge. That won't eliminate drift elsewhere, but it gives maintenance work a more useful target.

Separate ingestion from what people are actively querying. Let updates run in the background, then publish a consistent snapshot rather than changing relationships halfway through someone's investigation.

Show when that snapshot was last updated too. A graph can be useful without being instantaneous, as long as readers know what they're looking at.

Getting the data into a graph isn't the same as getting people to use it. A question interface in the team's existing chat or development workflow may be more useful than another database nobody remembers to open.

And the storage doesn't necessarily have to be a graph database. Depending on the questions you need to answer, a searchable index might be enough.

Watch the query side as the graph grows, not just the update pipeline. Dense relationships can make traversals expensive at larger scales, so test the questions you actually want to ask before assuming a few more hops will stay cheap.