Visualise your Codebase Memory built with Greplica
Greplica stores engineering context in a typed graph — components, flows, claims, and sources. Agents query it through the CLI, but humans need a way to browse that memory too. It is important to prune out stale memories, to promote working memories to durable main memories, to audit what got captured, and to spot gaps before they mislead the next session.
We just shipped greplica graph view — a self-contained in-browser visualisation of your repo's memory. One command, no server, no config. It opens a local HTML file built directly from your graph database.
If you have Greplica installed and a bootstrapped graph, you can see your whole codebase memory laid out like a wiki.
Linked Wiki, no fancy graph
In our earlier post on designing Greplica's memory model, we argued that engineering memory must stay human-readable and human-verifiable.
Greplica's memory is a graph — but we did not render it as one. Force-directed node diagrams look impressive in demos and become unreadable the moment a real repo has dozens of components and hundreds of claims.
Instead, the viewer uses tables and hyperlinks that mimic the linkages. The graph structure is still there — about, contains, evidenced_by, supersedes — you just navigate it the way humans navigate wikis and dashboards, not the way graph theory textbooks draw edges.
The views
Greplica splits the graph into views that help audit how the memory is shaping up.
1. Components — "What subsystems does this repo have?"
A table of top-level components with code anchors, flow counts, claim counts, and subcomponent counts. Roughly corresponds to your folder structure.
Click a claim count to jump to Claims filtered to that component.
2. Flows — "What processes matter in this repo?"
Same table pattern as Components, but for top-level flows: name, description, which components each flow touches, and a clickable claim count. Useful when you care about how work moves through the system rather than where code lives.
3. Claims — "What do we actually know?"
Every claim in one searchable table: claim text, session source, kind badge (fact, decision, requirement, task, risk, question), and created timestamp. A keyword search bar filters by substring match on claim text or id.
Or better, click-through from Components, Flows, Overview, or Timeline lands here with the relevant subset already selected.
4. Claims — Timeline — "Which session created this memory?"
Memory commits on a vertical timeline, newest first. Each item shows how many claims were added and the split between session-sourced and code-sourced facts.
People tend to remember their stretch of work — what they were building and which decisions they took in that session — more easily than just through keywords. The timeline is organised around those batches so you can review what a particular session actually stored.
Click a timeline entry to open only the claims from that commit in the Claims view.
5. Claims — Overview — "What's the shape of our memory?"
A summary dashboard with three pie charts — by type, by source, and by freshness — for high-level auditing or to narrow in on one kind of memory, e.g. only decisions vs requirements.
Click any slice or legend row to filter the Claims table.
Use the visualisation to audit the memories Greplica has captured for your repo — what landed from sessions, what is still active, and what has been superseded.
How to use
From any repo with Greplica bootstrapped:
greplica graph view [--out <file>] [--no-open]
By default this writes a self-contained HTML file to a temp path and opens it in your browser.
For a deeper dive on why the graph looks like this — scopes, supersession, claim kinds — read Designing a memory optimised for storing codebase context.
If you find this useful or want to shape what visual review UX looks like next, find us on Discord.