What separates a second brain that stays useful from one that rots? A git-history audit of our own wiki
VERIFIEDSourceThis repository's own git history (`git log --oneline` run against every page in llm-wiki/concepts, /people, /frameworks) read directly; AGENTS.md and content-buckets.md read directly; external framing (the collector's fallacy, the Zettelkasten "write-only" note problem) via WebSearch extracts, graded SECONDARY
Method: Primary source is this repo's own git history —
git log --oneline -- <file>run against every page inllm-wiki/concepts/,llm-wiki/people/,llm-wiki/frameworks/, read directly this session.AGENTS.mdandcontent-buckets.mdread directly. External framing (the "collector's fallacy," the Zettelkasten "write-only" problem) came fromWebSearchextracts only — graded SECONDARY, pages not opened directly. Honesty caveat, load-bearing: this repository's recorded git history begins 2026-08-01 — the earliest commit anywhere in the repo, not a per-file artifact. The wiki's own log says the wiki pattern itself was adopted 2026-04-12, months earlier. So every number below covers this repo's ~7-week recorded history, not the wiki's full life. This digest checks something narrower and still real: of the pages that exist right now, how many has anyone gone back to, in the only window there is a record for.
The one-paragraph answer
In the one window this repo's git history can actually prove — the seven weeks since 2026-08-01 — 91% of this wiki's own reference pages have been touched exactly once: written, and never opened again for an edit. Across concepts/ (87 pages), people/ (55 pages) and frameworks/ (44 pages) — 186 pages total — 169 (91%, VERIFIED via git log) carry exactly one commit, ever. Nine pages were touched twice. Exactly one page, out of 186, has been revised a third time. This is not a hypothetical failure mode borrowed from a blog post — it is what happened inside the second brain the studio is teaching people to build, checked against its own version-control record. And the finding has a second layer that makes the point better than any external citation could: AGENTS.md, this wiki's own schema file, states as fact that a past folder rename left "~130 files" with stale [[digests/...]] links. A direct grep run this session (grep -rl '\[\[digests/' llm-wiki --include='*.md' | wc -l) returns 234 (VERIFIED). The file that documents the wiki's rot has itself gone stale by 80%. A second brain does not rot because nobody wrote the maintenance rule down — this one has had the rule, in writing, since its founding schema. It rots because writing a page and revisiting a page are different acts, and the second one has no natural trigger.
§1 — The audit: what "touched" means, and the raw numbers (VERIFIED, own git history)
For every file in llm-wiki/concepts/*.md, llm-wiki/people/*.md, llm-wiki/frameworks/*.md, this session ran git log --oneline -- <file> | wc -l. A count of 1 means the file has exactly one commit ever — the one that created it. A count of 2+ means someone came back and changed it — the exact behavior AGENTS.md prescribes: "Page exists → update it (new insights, new cross-links, Sources section)."
| Folder | Pages | Touched once | Touched twice | Touched 3+ |
|---|---|---|---|---|
concepts/ |
87 | 78 (90%) | 9 (10%) | 0 |
people/ |
55 | 53 (96%) | 2 (4%) | 0 |
frameworks/ |
44 | 38 (86%) | 5 (11%) | 1 (2%) |
| Total | 186 | 169 (91%) | 16 (9%) | 1 (0.5%) |
Checking creation dates (git log --diff-filter=A --format='%ad' --date=short): 75 of the 87 concept pages were created in a single bulk import on 2026-08-01 — the day this repo's history begins — with the rest trickling in through August and September (Aug 9 ×2, Aug 11, Sep 2, Sep 5, Sep 6, Sep 9 ×4, Sep 17, Sep 19). Pages created three days before this digest are already in the "touched-once" column, alongside pages from six weeks ago. Recency does not predict revisit. None of this proves the 169 pages are wrong — a correct page needs no correction. The finding is narrower and still real: the schema's own revisit mechanism, the thing meant to catch drift, essentially never fires.
§2 — The self-referential embarrassment (VERIFIED, grep run this session)
AGENTS.md carries this line, written when the Research Digests/ folder replaced a digests/ symlink: "the old digests/ symlink is gone... every [[digests/...]] wikilink inside older digests is stale... Those links are not being mass-rewritten: ~130 files." A direct count this session — grep -rl '\[\[digests/' llm-wiki --include='*.md' | wc -l — returns 234, not ~130: roughly 80% more stale links than the note about staleness says exist. Two honest readings, both worth holding: either the note was accurate when written and 104 more such links have been added since by digests copying the old citation habit, or the original count already undercounted. Either way, the maintenance note itself was never re-checked against the thing it describes — the exact failure this digest is about, one level up.
§3 — The unresolved conflict sitting in plain sight (VERIFIED, content-buckets.md)
A smaller instance of the same pattern: content-buckets.md carries an "Open conflict for a human to settle" section — the Focus Filter disqualifies "DevOps... without a direct PM application," while ⚙️ DevOps Basics (explained for PMs) is a live, published pillar. The file records two possible readings and says neither is chosen. That is the system working as designed — flagging rather than silently overriding — but the flag carries no visible age marker, so a reader cannot tell whether it has been open for a day or a month. Recording that something is stale is not the same as bounding how long it stays that way.
§4 — What the outside literature calls this (SECONDARY — extracts, not opened directly)
Two named concepts from the personal-knowledge-management literature, found via WebSearch this session: the "collector's fallacy" — the failure mode named around Tiago Forte's Building a Second Brain (2022) — saving in place of learning; and Zettelkasten's "write-only" note problem — systems where "information goes in and never comes out," collecting without using. Neither source was opened directly this session; this reports what the search extracts say. Both locate the failure at the same seam this audit found mechanically: capture has a natural trigger (a new digest gets written every time something is researched); revisit does not.
How a PM applies this — what to try this week
- Run the same audit on your own second brain, without git. Notion's page history, Obsidian's file-modified timestamps, Confluence's version count, even a Google Doc's version history — all work. Open your ten oldest notes and check how many have a second edit, ever, after the day they were created.
- Don't trust a note's age from its "created" date — check its "last touched" date. Recency of creation told this audit nothing; recency of revisit is the real signal.
- Add one deliberate revisit trigger — the audit's finding is that none exists by default. Cheapest version: whenever a new note touches the same topic as an old one, spend 30 seconds re-reading the old one and asking whether it still says what you'd say today.
- When you flag something as stale or unresolved, date the flag. An undated "flagged, unresolved" note looks the same on day one and day ninety.
Open questions for a future session
- Whether the 12 concept pages created after the Aug 1 bulk import show a different revisit rate than the 75 bulk-imported ones, once enough time has passed to judge.
- A direct read of Forte's Building a Second Brain or a Zettelkasten primary source, to move the "collector's fallacy" / "write-only note" claims from SECONDARY to VERIFIED.
- Whether
content-buckets.md's open conflict predates this digest by days or weeks — no in-file date pins it.
Sources
Primary (VERIFIED — read directly, this repository)
llm-wiki/concepts/*.md,llm-wiki/people/*.md,llm-wiki/frameworks/*.md— 186 files,git log --onelinerun against eachllm-wiki/AGENTS.md— schema file, the "~130 files" stale-link claimllm-wiki/content-buckets.md— the open, unresolved conflict sectionllm-wiki/log.md— the 2026-04-12 wiki-creation entry, used only for the honesty caveat about git-history start date
Search extracts (SECONDARY — pages not opened directly)
- "Collector's fallacy" — curtismchale.ca, "Building a Second Brain Gives You Permission to Fall Into Collector's Fallacy" (2022-07-30), via WebSearch extract
- Zettelkasten "write-only" note problem — multiple forum.zettelkasten.de and PKM-blog extracts, via WebSearch, no single page opened directly
Not reachable / not attempted this session: Forte's Building a Second Brain book text itself (no primary edition fetched); no domain was tested and blocked for this digest — every primary claim came from files already in this repo.
The askOpen whatever tool holds your own notes and check five of your oldest ones: has any of them been edited a second time, ever? Tell me the honest number — I'm collecting real counts, not guesses.
Post angle →
This wiki's own schema file claims ~130 stale links from a folder rename; a direct grep this session found 234 — the note about the wiki's rot is itself 80% stale.
Receipt to lean on: Lean on the self-audit: 169 of 186 concept/people/framework pages (91%, VERIFIED via `git log`) carry exactly one commit since this repo's git history began 2026-08-01, and AGENTS.md's own "~130 stale links" claim is itself outdated — the real count, grepped directly, is 234 (VERIFIED).
Seed for /draft-linkedin-post, not a finished post.