Every code repository has a file that says who owns each part of the code. Nobody fully trusts that file, and there’s a good reason. People change teams. People leave projects. The file never updates itself when that happens.
I wanted to know how wrong that file actually is, and whether a graph database could measure the gap instead of just storing data.
The setup
I took every pull request merged into Home Assistant’s core repository over 180 days. About 10,000 pull requests, 1,600 modules, 1,500 contributors. I loaded all of it into FalkorDB: people, modules, pull requests, and decisions as nodes. The connections between them (who wrote what, who reviewed what, which modules depend on which, and who’s listed as the owner) became edges.
The first thing I checked was simple: when a pull request touches a module, does the listed owner actually review it?
Across the whole dataset, the listed owner was the real reviewer only about 14% of the time. That’s not a small error. That means the ownership file is wrong most of the time.
Making the graph do the thinking
A normal database can answer “who reviewed pull request #4512.” It struggles with “what breaks if this person stops reviewing,” because that question needs several steps: find the modules this person maintains, find who else has touched those modules recently, find the ones with nobody left, then find everything that depends on those.
That’s a few lines of Cypher in FalkorDB. I used variable-length path matching to trace dependencies several steps deep, and FalkorDB’s built-in PageRank to rank which modules matter most based on how much depends on them.
I also ran into a real bug along the way. Binding a loop variable inside a MATCH pattern silently returned zero rows instead of giving an error. No warning, nothing. It just looked like there was no data, when the data was actually there. I only caught it by building a tiny test graph and checking the query by hand. The fix was switching to a WHERE key IN $list filter instead.
The result I didn’t expect
I ran the “what if this person leaves” query against the most active reviewers in the dataset. For one contributor, removing them left 21 modules with no remaining reviewer who had touched them in the past 90 days. Those 21 modules have 751 other modules depending on them, directly or through a chain.
None of this shows up in the ownership file. That file still lists this person as relevant to modules they haven’t touched in months.
Making sure the answers can be trusted
I didn’t want to just print numbers and hope they’re right. So every answer the system gives is built from small facts, and each fact is tied to the exact query that produced it. Before showing anything to a user, a separate piece of code reruns that query and checks the number still matches. If it doesn’t match, the claim gets dropped, not shown with a warning next to it.
I also built a plain text-search version on the same data, on purpose, to check whether the graph was really adding value or whether I was just convincing myself it was better. The graph wins at picking the top three likely reviewers. The text-search version wins when there’s almost no history to work from. I kept both results instead of only showing the one that made the graph look better.
What’s next
Right now, ownership and dependency connections are snapshots, not dated, so I can’t yet ask “who owned this module back in March.” Adding dates to those connections is the next real improvement. I’d also like to combine the graph ranking with the text-search ranking, since each one wins under different conditions.
The code, setup steps, and full graph structure are linked below if you want to try it yourself or check the numbers.
srishtipandey1
/
provenance
A graph-powered tool for understanding code ownership, reviewer expertise, and project risk.
Provenance
See who owns the code and who actually knows it.
Why
I built Provenance to show where a repository's listed owners differ from the people doing the work.
When ownership records fall behind, reviews go to the wrong people and expertise gaps stay hidden. In Home Assistant, if epenet stops reviewing, 21 modules lose expert coverage, affecting 751 dependent modules.
How it works
flowchart LR
A[Public GitHub data] --> B[FalkorDB graph]
B --> C[8 typed deterministic tools]
C --> D[Evidence facts]
D --> E[Claim]
E --> F[Plain-code verifier]
F -->|replay matches| G[Verified answer and UI]
F -->|mismatch| H[Reject claim]
Architecture
flowchart LR
GH[GitHub data and local architecture records] --> ING[Resumable ingestion]
ING --> DB[(FalkorDB)]
DB --> TOOLS[provenance/tools]
TOOLS --> AGENTS[Router, verifier, and workflow agents]
LLM[Optional Groq or Gemini planner] -. typed tool selection .-> AGENTS
AGENTS --> API[Read-only FastAPI]
API --> UI[React and TypeScript dashboard]
Graph schema
Top comments (0)