The self-repairing graph
A memory is only useful if you can trust it. A graph that confidently serves a fact that's no longer true is worse than no memory at all — so Stele is built to maintain itself. Backfill seeds the record; this is how it stays honest as the project moves underneath it.
Two clocks on every fact
Stele tracks each piece of knowledge on two separate clocks, because "recent" and "true" aren't the same thing.
- Freshness — when the content last changed. This is cheap and automatic.
- Verification — when someone last confirmed the fact still holds against reality. This is the expensive signal, and it's never set by an ordinary edit — only by a deliberate check. A node can be freshly written and still wrong; only verification catches that.
Keeping the two apart is what lets the record tell "nobody has touched this in a while" from "nobody has confirmed this is still right" — and act differently on each.
What the graph does on its own
Most upkeep needs no one to run anything. As the record grows, Stele is continually:
- Flagging the stale. Knowledge that hasn't been verified in a long stretch is surfaced for a fresh look, rather than served as if it were certain.
- Favoring the recent. When two facts compete for a spot in the context, retrieval gives a gentle edge to the one updated more recently.
- Expiring what was only ever temporary. A fact written as true-for-now can carry an expiry date; when it passes, it retires itself.
- Retiring resolved risks. A risk or note bound to a task is archived when that task closes — the worry is handled, so the warning goes with it instead of lingering.
- Stepping aside when superseded. When a decision replaces an earlier one, the old decision is archived and stops being served as truth.
- Catching duplicates and broken links. Near-identical facts and edges that point at nothing are surfaced to reconcile.
The verification sweep
Freshness is automatic; truth isn't. The sweep is the deliberate part — the one that catches a node anchored to a file that has since moved, or a decision quietly reversed in the code while the record still claims the old answer.
It triages what's changed since the last sweep — diffing against the exact commit it last reviewed — and gathers the knowledge that touches those changes plus anything gone stale. Then it fans out a swarm of parallel reviewers across those facts; each one checks its batch against the real code, both the claim and the anchors (the files and symbols the fact points at). You make the final call on each — fix it, re-anchor it, retire it, or flag it. The run is recorded, so the next sweep only re-checks what changed since.
The health check
Where the sweep verifies truth, doctor is the broad audit: one command that walks the whole record and reports what needs attention — stale claims, knowledge overdue for verification, expired notes, decisions superseded but still active, duplicates, broken links. The entries that are safe to retire on their own are cleared in the same pass; the rest come back as a short worklist your agent helps you act on.
Your agents do the gardening
The point of all this is that you don't hand-maintain the record. The automatic parts — flagging, expiry, retirement — never sleep. The deliberate parts ride along with the agents you already use: they run the sweeps, act on what the health check finds, and write new knowledge with anchors and expiry dates so it can retire itself later. Maintenance is continuous because it's part of the work, not a chore bolted on after.
Today the sweeps run when your agent runs them, while the automatic flagging and retirement happen on their own. A fully autonomous, recurring drift-scan — one that gardens the graph in the background with no one prompting it — is something we're building next, not something that ships today.