Every engineer has been here.

You open a config file and see something like DB_POOL_SIZE=10. You want to change it. You check git blame and it says "fix config" by someone who left 8 months ago. You search Slack. Nothing. You check Notion. Empty. You ask your senior and they say "I think someone set it because of some memory issue, be careful."

You make a call. You change it. You deploy.

Production crashes.

That context — why that value existed, what incident caused it, who set it and why — was always there. Just scattered across a buried Slack thread, an incident report, a post-mortem nobody linked together. Nowhere you could actually find it when you needed it.

This is the problem I built Capi for.

What is Capi?

Capi stands for Config Archaeology. The name says it all — you're digging through layers of history to understand why something exists.

The idea is simple. Every config value was set by someone, at some point, for some reason. That reason is the most valuable context you can have before touching it. Right now that context lives nowhere queryable.

Capi ingests your git history, incident reports, and PR descriptions and builds a knowledge graph that connects config keys to the reasoning, incidents, and decisions behind them. You query a config value, you get the full story.

It is not a chatbot. It is not a linter. It is a memory layer for decisions your team already made but never stored anywhere useful.

Live: capi-bay.vercel.app
GitHub: github.com/Akarshkushwaha/Capi

What It Looks Like

The dashboard opens with one question — what happened last night?

The investigation form. Type any config key name, select your service, hit investigate.

Type DB_POOL_SIZE, hit investigate, and Capi pulls everything it knows — commits, PRs, incidents — into a Case File:

The Case File. Danger score, safe operating range, archaeology provenance, prior offenses — all connected.

And if you want to see how everything links together, the Evidence Board shows the full knowledge graph Cognee built from your git history:

The Evidence Board. Config keys (amber), incidents (red), engineers (blue) — all connected by strings of provenance.

Why Cognee and Not Just a Vector Database

This is the part worth explaining properly.

My first thought was simple — embed all the git history and incident reports into a vector database, do semantic search, done. But that has a real problem.

Vector search finds text that is similar to your query. It can find documents that mention a config key. But it cannot answer "what incident caused this value to be set" — because that is a relationship question, not a similarity question.

To answer that you need to know that this config key was changed in this commit which happened right after this incident which was caused by this specific infrastructure problem. That chain of relationships is a graph traversal problem, not a search problem.

Cognee builds a hybrid graph-vector knowledge store. It extracts entities from whatever you give it, maps relationships between them, and when you query it, automatically decides whether to use semantic similarity or graph traversal depending on what the question needs.

That is why I used Cognee specifically. Not because it was the hackathon sponsor. Because it is genuinely the right tool for this problem.

The entire API is four functions:

await cognee.remember()  # ingest into the knowledge graph
await cognee.recall()    # query with auto-routed retrieval
await cognee.improve()   # re-weight graph from outcomes
await cognee.forget()    # remove stale nodes

Everything Capi does sits on top of these four. Full quickstart at docs.cognee.ai and source code at github.com/topoteretes/cognee.

How Each Operation Maps to Capi

remember() takes your git log, PR descriptions, and incident reports and ingests them into the knowledge graph. Cognee does not just store the text — it extracts entities like config key names, dates, engineer names, incident IDs and builds a graph connecting them.

recall() is what powers the query command. When you ask "why was this value set?", Cognee traverses the graph and returns the connected story — not just documents that mentioned the key, but the actual chain of who changed it, when, and why.

improve() is the self-improving part. Every time a config change leads to an incident, Capi calls improve() with a negative signal. Every time a config change deploys cleanly, it calls improve() with a positive signal. The graph gets re-weighted over time. High-risk keys surface stronger warnings. The system gets smarter without anyone manually tuning it.

forget() handles deprecation. When a service shuts down or a config key is removed, forget() surgically removes those nodes from the graph so you stop getting warnings about values that no longer exist.

How to Integrate Capi Into Your Workflow

Install

git clone https://github.com/Akarshkushwaha/Capi
cd Capi
pip install -r requirements.txt
cp .env.example .env
# Add your GROQ_API_KEY and GITHUB_TOKEN to .env

Cognee itself needs no external infrastructure:

pip install cognee

All three stores — graph (Kuzu), vector (LanceDB), relational (SQLite) — are file-based and embedded. They initialize automatically on first run. No Docker, no Postgres, no Redis.

Step 1 — Ingest your repo

The line that got me was Cognifying commit diffs. Capi is not reading a .env file — it is walking backward through your entire git history, extracting commit patches and diff provenance, and building a memory graph on what actually happened over time.

Step 2 — Query any config key

That is the answer to "why is DB_POOL_SIZE=10 and not 20" — traced from git diff through PR through incident, in one query.

Step 3 — Audit an entire config file before deploying

Two danger keys caught before the deploy even happens.

Step 4 — Record incidents to make Capi smarter

When a config change causes a production issue:

Next time anyone queries DB_POOL_SIZE, the warning will be stronger. The memory re-weighted itself. Nobody configured anything manually. That is what self-improving actually means.

What Surprised Me While Building This

I underestimated how much Cognee does under the hood.

When you call remember(), it runs entity extraction, relationship mapping, and embedding generation in a single pipeline pass. The line Cognifying commit diffs in the ingest output was the moment it clicked — Capi was not storing text, it was building a memory graph on what actually happened in the git history. Config key nodes connected to incident nodes connected to engineer nodes, all from plain text commit messages and diff patches.

The recall() routing also surprised me. Ask "what is DB_POOL_SIZE set to" and it behaves like a search. Ask "what incident caused DB_POOL_SIZE to be set" and it switches to graph traversal. Same function, same API, completely different retrieval path underneath. You never specify which — Cognee picks based on the shape of the question.

The Stack

Memory       → Cognee open source (Kuzu + LanceDB + SQLite, all embedded)
LLM          → Groq llama-3.3-70b-versatile
Backend      → Python + FastAPI
CLI          → Typer + Rich
Git parsing  → GitPython
GitHub API   → PyGitHub
Dashboard    → Next.js + Tailwind + react-force-graph-2d
Deploy       → Render (backend) + Vercel (dashboard)

Links

Try Capi: capi-bay.vercel.app

GitHub: github.com/Akarshkushwaha/Capi

Cognee: cognee.ai · GitHub · Docs

Why This Matters

Config values are boring. Nobody writes about them. But a lot of production incidents have "someone changed a config value they didn't fully understand" somewhere in the timeline.

The context that would have prevented it existed. It was just never connected into something queryable.

Capi is an attempt to fix that — a memory layer that persists, learns from outcomes, and gets smarter over time instead of just being a fancier grep over your git history.

If you've ever stared at a mystery config value at 2am wondering if touching it will break everything — that's who I built this for.

Built for the Hangover Hackathon — @WeMakeDevs x @cognee