Here's a fun fact nobody asked for. Kubernetes has proposals that are officially "implementable" while their tracking issue was closed back in 2019. They're not alive and they're not dead. They're zombies, and nobody noticed, because nobody looks at both records at the same time.
I noticed because I spent a hackathon building something that does nothing but look at both records at the same time.
Wait, what's a KEP
Every big change to Kubernetes starts as a KEP, a Kubernetes Enhancement Proposal. Think of it as the paperwork before the feature. And like all good paperwork, its status is written in about four places:
- a
kep.yamlfile - the tracking issue (open, closed, labels, milestone)
- sometimes another KEP saying "I replace this one"
- the memory of whoever was in the meeting
Different people update different records at different times, and nothing keeps them in sync. So naturally they drift apart. Quietly. For years.
Kubernetes is basically a company
This was for Graph Hacks by WeMakeDevs and FalkorDB, and I picked Track 3, Company Brain. Most "company brain" projects need a company, and I don't have one lying around. But Kubernetes kind of is one: a public org chart (SIGs), a public decision log (KEPs), and an enormous number of meetings. So I built KEP Brain.
I loaded three SIGs (sig-node, sig-scheduling and sig-apps), 238 KEPs in total. The result: 59 pairs of records disagreeing across 50 KEPs, and 40 of them were zombies. I was honestly expecting maybe five.
Why not just "chat with the docs"
My first instinct was the classic move: dump everything into a vector database and let a model vibe its way to an answer.
Then I wrote down the questions people actually ask:
- Who decided this KEP's status, and based on what?
- Who owns this area, and who actually knows it? (Not the same person. Ever.)
- What changed since release 1.33?
None of these are "find me a similar paragraph". They're chains: a person opened a PR, that PR changed a kep.yaml, that change was a decision, the decision belongs to a KEP, the KEP belongs to a SIG. That's a graph wearing a trench coat. So I used FalkorDB and made the graph the entire product, with no other database anywhere.
This is a real query the agent runs:
MATCH (p:Person {key: $login})-[r:SUBMITTED|COMMENTED]->(x)<-[e:EVIDENCED_BY]-(d:Decision {kep_path: $key})
RETURN d AS decision, type(r) AS rel, x AS via, e.evidence_kind AS evidence_kind
ORDER BY d.decided_at DESC
One line of pattern matching. In SQL that's a join party. In a vector store it's a prayer.
How it works (the short version)
A worker pulls everything live from GitHub: KEPs, SIG rosters, OWNERS files, issues and PR history. It all becomes one graph of about 39,000 nodes and 127,000 edges, and it re-syncs every day.
My favourite trick is that every status edge remembers when it was true. So "what's the status now" and "what was it back in 1.30" are the same graph with a different filter. Nothing gets deleted. It just gets an end date, like a gym membership.
On top of that there's an agent you can ask questions in plain English. It's only allowed read-only graph queries (FalkorDB's GRAPH.RO_QUERY with timeouts), so it physically can't mess up the data, no matter how creative it gets. Every answer cites its sources, and each citation is a graph node with a GitHub link you can click.
And if it can't back an answer up, it says "I don't know" instead of confidently making something up. A validator checks every citation against what the tools actually returned. Wrong or missing citations get the whole answer thrown out. It's the most honest thing I've ever built, and it's more honest than me during exams.
Then there's the audit page, which lists every place two records disagree. It shows both sides, the links and a drafted fix. It never posts anything to GitHub on its own, because the last thing the Kubernetes maintainers need is a bot from a hackathon opening 59 issues at 3 am.
Things that bit me
Full-text search said "nope". FalkorDB's full-text index treats every word as required, so "what is a KEP" returned... nothing. I ended up rewriting questions into an OR of the useful words with wildcards. Works great now. Took me longer than I'd like to admit.
Some people are just too connected. A few maintainers have thousands of decision edges. Running a shortest-path search from them blew straight through my 2-second budget, so the search goes in steps: direct link first, then through the KEP, then the full search. Shortest first.
I caught my own README lying. It said "every claim is cited". The validator actually checks every citation, not every sentence. So I fixed the wording. A tool about trust with a dishonest README would've been very on brand for the zombie KEPs, though.
What I learned
The AI part was the easy part. The real work was the data model: what counts as a decision, how to store time, and how to tie every single fact back to a public URL. Once the graph was right, the answers mostly fell out of it.
Also: sometimes the most useful answer really is "I don't know, and here's why."
Try it
- Live: https://kep-brain.duckdns.org
- Code: https://github.com/akshat-lakhera/kep-brain
- Demo: https://youtu.be/5ht6jMg8Ou8
Big thanks to WeMakeDevs and FalkorDB for Graph Hacks. And if you're a Kubernetes maintainer and one of those zombies is yours... the audit page has a drafted fix ready.
Top comments (0)