Your second brain is dying of maintenance — so we built one that maintains itself
Second brains don't die at capture — they die at maintenance. A zero-dependency maintainer finds dead links, orphans, stale notes and near-duplicates + a connectivity gauge, suggests which note to link each orphan to, and applies the fix only with your go-ahead (advisory, dry-run by default). Validated on a real ~7,700-note vault. Open-core.
The claim. Second brains don't die at capture — they die at maintenance. Setting up Obsidian/Notion is easy; the ongoing chore of re-linking, de-duplicating, archiving, and noticing what's gone stale is what people quietly stop doing, until the vault is a pile that search can't save. The fix isn't another note-taker. It's a maintainer that does the chore for you.
What we built. A single zero-dependency pass over a folder of Markdown notes that finds what's rotting and — crucially — says what to do about it:
- dead
[[links]](pointing at notes that don't exist), orphans (nothing links to them and they link to nothing), stale notes (old and weakly connected), and near-duplicate clusters; - a vault connectivity score —
self_legibility= the fraction of notes in the link graph's giant component (the standard network-science order parameter; here 0.81 — an unvalidated proxy for retrieval, see below, not a verified "health" number). There is a real percolation cliff, and we measured it — but read it carefully: sweeping random link-removal on a homogeneous graph at the vault's density (~13 links/note), the giant component holds high (≈0.89 at 80% removed, 0.77 at 85%) then drops abruptly past ~90%, as the remaining mean degree → 1 (the Erdős–Rényi threshold; the general Molloy–Reed criterion ⟨k²⟩/⟨k⟩=2 reduces to this for our Poisson/random-removal model — Callaway 2000, Cohen 2000, Newman-Strogatz-Watts 2001). Two caveats kill the easy reassurance: (1) random removal on a homogeneous graph is the most-robust regime — the real failure mode is losing hub/index notes (targeted removal on a heavy-tailed graph), which fragments far faster and with less warning, and we have not modeled it; (2) the 0.81 is not a point on that curve — the same model predicts ≈1.0 at the vault's density, so the missing 19% is orphan accrual, a slower and different mechanism than the cliff. Treatself_legibilityas a drift monitor we hypothesise is useful (one snapshot, not yet a measured trend), not proof you're safe; - for each orphan it suggests which existing note to link it to, and it can apply that fix — appending a marked
## Relatedblock — additively, idempotently, dry-run by default. It never edits, moves, or deletes your existing content. (One caveat worth naming: because every reconnected orphan joins the giant component, running this pass mechanically raisesself_legibility— the tool can improve its own score without proving it improved retrieval, so don't read the score as a grade of the tool's work.)
Validated on a real ~7,700-note vault. Not a toy: self-legibility 0.81 (well-connected but fraying), ~13 links/note, ~10% orphans — and 287 of 300 scanned orphans got a candidate note to reconnect to. (Honest read: that's coverage — a lexical-overlap suggestion exists for almost any prose note — not a precision score; we haven't yet evaluated how many suggestions are good.) Running it on real data also caught two bugs in our own tool — it was missing Obsidian aliases (falsely flagging ~300 orphans) and dating notes by file mtime (which a git sync resets) — both now fixed. That's the point of dogfooding: the measure has to survive contact with a real vault.
Falsifier — and we ran it. The percolation framing predicts the giant-component fraction collapses abruptly as links are lost, not linearly. We tested it: on a graph at the vault's density, the giant component holds high then drops sharply only as the remaining mean degree approaches ~1 (a true cliff) — so the abrupt-transition framing is confirmed. But the test was random edge removal on a homogeneous graph; the vault's real risk — losing hub/index notes (targeted removal on a heavy-tailed graph) — collapses faster and with less warning, and we have not run that yet. What would still change our mind: a vault whose connectivity fades linearly with no knee, or evidence that giant-component fraction doesn't predict actual retrieval success (see the honest limits). Connectivity is our proxy for health; we have not yet shown it tracks whether you can find things.
The tool. It's the maintenance layer of the memory core that runs our own autonomous research OS over ~5,800 notes — open-core, the core stays free. Point it at your vault; it reads, it advises, and it only writes the one block you let it. Bring an embedder and the link suggestions get sharper; with none it runs today on lexical overlap.
FAQ
Why do note-taking “second brains” fail? Not at capture — at maintenance. Setting up Obsidian or Notion is easy; the ongoing chore of re-linking, de-duplicating, and pruning stale notes is what kills them, so the vault rots into an unsearchable pile.
What did you build instead? A maintenance layer for the memory core — the same one that runs our autonomous research OS over ~5,800 notes — that automates the upkeep: surfacing orphans, duplicates, and stale-but-valuable notes instead of leaving it to manual effort.
Is it validated on a real vault? Yes — on a real ~7,700-note vault. That shook out real bugs we fixed: Obsidian aliases were falsely flagging ~300 orphans, and dating notes by file mtime broke when a git sync reset timestamps. Both are fixed.
Is it open-source? It is open-core — the maintenance/memory core stays free. It is the same layer Agora dogfoods on its own vault, so the design rules are measured on real data, not assumed.