GTM Knowledge Base Maintenance: The Compounding Loop

By Ryan Vanshur

Most GTM knowledge bases get built once and then left alone. The notes keep getting quoted on calls long after the pricing changed or the ideal customer profile moved, and nobody notices, because a stale note looks just like a current one. The fix, as this guide shows, is a schedule with numbers attached, not a bigger wiki.

Memory compounds only when four things run in a loop, namely capture, structure, prune and measure. Each working session also closes in writing, so the loop restarts cold the next morning instead of starting from scratch. The essay Memory That Compounds makes the case for the loop, and this guide is its operating side. We set the thresholds in advance and run them on a cadence, and you should follow one rule above all the others, because it keeps a cleanup pass from erasing the record it was meant to protect.

Thresholds for GTM Knowledge Base Maintenance

A maintenance pass with no thresholds turns into a debate about taste, and taste never settles anything. So we pick the numbers now, while nothing is on fire, and let the pass read them off the table.

Check Healthy Warning Critical
Tag sprawl (share of tags used exactly once) Under 20% 20% to 40% Over 40%
Link density (links per note) 3 to 10 Under 3, an orphan Over 10, a hub to split
Provisional notes (still marked as forming) Under 30 days old 30 to 60 days, decision due Over 60 days

Tag sprawl matters because a tag nobody reuses is a tag search can't use, and provisional notes need a decision at 30 days, since "emergent" quietly becomes a permanent status if nobody forces the call. We also keep a health score that starts at 100 and loses points for each stale note, expired note, dead reference and duplicate, with bands running excellent above 90, good above 70, fair above 50, and poor below that.

The GTM Knowledge Base Maintenance Schedule

  1. On arrival, capture it, turning each transcript, deck, thread or meeting note into a small structured file the day it arrives, with a one-sentence summary that works without the original, tags, and two or three links.
  2. At the end of every session, close it in writing with the Three-Line Session Close below, because that's the cheapest capture there is and it doesn't cost you a tool.
  3. Every Monday, run the weekly review, in which the Weekly Review skill runs a light shape check, looks at what is in flight, and writes a dated file, so next week has a baseline to compare against.
  4. Once a month, run the prune pass, in which the Dream skill flags notes that are stale, contradicted or duplicated, fixes what is safe to fix, and asks before it touches anything else.
  5. Each quarter, read the weekly files side by side, because a count that doubled between two quarters needs an explanation, and the files are where that explanation lives.

The monthly interval is our suggestion, and you can tune it to your volume, but the fixed schedule is the rule, and it's the part we shouldn't negotiate away, so write the cadence down where the team can see it.

Prune Without Losing the Record

Stale notes are worse than no notes, because people trust them and act on them in front of a customer. In the first full pass over one accumulated base, roughly three quarters of the notes were no longer accurate.

Each note has two zones, a top that holds compiled truth and gets rewritten as understanding changes, and a bottom that holds a dated, append-only timeline of exact quotes, never paraphrases. So when a belief turns out wrong, we rewrite the top and add a dated entry below, and the correction and the path to the mistake both stay visible.

Pruning's where the damage happens, so it needs one rule above the rest, and the rule's de-link, never de-line. Picture an index entry that runs 2,371 characters and links ten files, one of them dead. A naive cleanup deletes the whole entry, nine live references and a paragraph of history, just to fix one broken pointer. The correct repair strips the link markup around the dead reference and keeps every word, so it cost 252 characters of markup and zero words. We make the rule procedural, so nobody has to remember it, and any fix that runs without approval must be additive or markup-only. If a fix would remove words a human wrote, it goes on the ask-first list, and it stays there with no exceptions.

Clever rules can do damage too, and one rule meant to auto-correct vague dates matched 107 raw times, with only about 5 of those real, a false-positive rate near 95%, which is why we measure a cleanup rule on real data first, and you should keep it on the ask list until it earns the right.

Measure the Shape of the Base

A base can be mostly true and still be unusable, because tags fragment, notes sit alone, and half-finished items never get promoted or retired, and none of that shows up when you read a single note. So run a graph health check every week as part of the Monday review, and write a decision beside each gauge that crosses a line, because a warning nobody answers soon becomes wallpaper.

The Monday Review Runs on Three Rules

First, grade last week's priorities from evidence, meaning the commit log, the file dates and the artifacts that exist, and each priority ends up done, not done, or overtaken, since plans do get made irrelevant.

Second, write null for anything we didn't check, never zero, because zero is a measurement, and a zero recorded for a metric nobody looked at becomes the floor under next week's wrong decision. Third, make every priority checkable later by a file, a pull request, a person or a command. "Make progress on the scraper" fails that test, and "Publish three articles" passes it.

The Three-Line Session Close

Print it, and run it at the end of every working session with no tooling at all.

  1. What got done. Past tense and specific. "Rewrote the import and got the row counts matching Friday's export," not "worked on the import."
  2. The state it's in. The file, the stage, what is verified and what is still assumed. "Running on staging, three checks passing, timing still unmeasured," not "nearly done."
  3. One next action, which has to pass four tests:
    • Imperative. It starts with a verb. "Merge the branch," not "continue the deployment."
    • Named object. The verb has a real thing attached. "Run the import test against the Q3 file," not "run the test."
    • Single step. One thing, not five.
    • Resumable cold. Someone who wasn't in the session could do it without asking a question.

Skipping the close costs you every day without an invoice, and the first twenty minutes of the next session go to re-deriving all three lines.

Go Deeper

Monday, Working

Picture PlotIQ, a fictitious deathcare software company we use in our examples. A renewal lead needs one fact about a funeral home account, and the answer is one search away, so nobody has to rebuild it from memory. The call transcript was captured the day it arrived, with the buyer's exact words in the timeline. Last month's prune pass retired two older notes that contradicted it, and the Monday review wrote all of it down.

Nobody remembered any of it. The loop did.


Join the Guild and get the weekly operator brief. Subscribe free.

Run the Three-Line Session Close at the end of your next work session, and keep the three lines for tomorrow.

The GTM skills framework is free on GitHub, with fourteen sales methodology skills and the operating layer that keeps them honest. It runs in Claude Code, Codex, or as a custom GPT. github.com/rvanshur/vertical-gtm-skills

Related Reading

Guides

Case Studies

Playbooks