You can measure how much of your codebase anyone still present understands, without reading a line of the source, using history your repositories already keep. This page is the practical version: what to compute, what it means, and where the honest limits are. The full formal treatment lives on the methodology page.
Git records who wrote every change and when each author was last seen. Those two facts, joined, answer a question no dashboard asks: what share of recent work belongs to someone who is still here?
Weight every changed line by its author's recency (full weight for someone who committed today, declining weight as their silence stretches) and you get living knowledge: the fraction of the recent codebase held by people who could plausibly still explain it. The Grasp Score is this number, computed per module and rolled up, with the weighting published and a harsher binary variant (author active in the last 90 days, yes or no) shipped next to it so you can see how much the curve is doing.
A single number hides too much, so the score travels with three companions.
AI attribution, as a minimum. Count only hard evidence: Co-authored-by trailers naming agents, and commits from bot accounts. This undercounts, deliberately. A developer who pastes assistant output under their own name is invisible to it, which is why it is reported as "at least this much" and never as an estimate of the true share.
Inactive share. Work belonging to authors with no commit inside the activity window. On a public repository this includes drive-by contributors who were never "staff" to begin with, so it overstates attrition there; on a company repository with a real roster it is close to exact.
Heat and concentration. Poorly-understood code that nobody touches is a parked risk. Poorly-understood code under active churn, held up by a bench one person deep, is where incidents come from. Ranking modules by unknown share amplified by churn and thinness of ownership produces what I call the dark-code ranking, and it is usually the first thing a team disagrees with productively.
Everything above is computable from git log with patience and a weekend. If you want the one-command version, the free scanner runs it on any public GitHub repository in about a minute, metadata only, and the Scoreboard shows it across repositories you already know, so you can calibrate what a 40 or a 90 feels like before scanning your own.
For a private estate there is a self-hosted fleet scan: your token, your infrastructure, and the clones are deleted as it goes.
Engagement is a proxy for comprehension, not a measurement of what is in anyone's head. A recent commit does not prove understanding, and silence does not prove ignorance; a maintainer on parental leave reads as departed at ninety days, which is exactly why the score ships with a stability label showing how much one person's clock moves it. Squashed merge history credits one author with everyone's work and destroys co-author evidence at merge time, so squash-heavy repositories get their concentration figures labelled as upper bounds. Content-curation repositories (link lists, docs collections) score low by their contribution model rather than by decay, and the scanner detects and says so rather than adjusting the number.
Every one of these limits is disclosed on the report it affects. The rule I hold the instrument to: disclose, never fudge.
Run it: scan a public repo free. Read the numbers in the wild: The State of Comprehension Debt 2026. The formal method: methodology.