I treated Kubernetes like a company and gave it a brain

Description and use

The system synchronizes Kubernetes KEP statuses with their GitHub records, identifies 40 zombie proposals, and offers accurate, time‑filtered queries plus an audit page with drafted fixes.

Problem

Kubernetes KEPs and their tracking issues drift apart, leaving many proposals in a zombie state where status records are inconsistent and hard to reconcile.

Outcome

The system identifies 40 zombie KEPs, provides accurate, time‑filtered status queries, and offers an audit page with drafted fixes, all while ensuring answers are fully cited and verifiable.

Workflow

• 1. Pull KEPs, SIG rosters, OWNERS files, issues and PR history from GitHub.
• 2. Load data into FalkorDB as a graph, preserving status edges with timestamps.
• 3. Run daily sync to keep graph up‑to‑date.
• 4. Expose a read‑only agent that answers plain‑English questions via GRAPH.RO_QUERY with timeouts.
• 5. Validate each answer’s citations against graph nodes; discard answers with missing or incorrect citations.
• 6. Provide an audit page that lists all record disagreements and drafts fixes.
• 7. Allow maintainers to review and manually resolve discrepancies.

Evidence

Kubernetes has proposals that are officially "implementable" while their tracking issue was closed back in 2019.

Source

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 those zombies.

Source

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.

Source

Every answer cites its sources, and each citation is a graph node with a GitHub link you can click.

Source