Every Grasp Score is computed from repository metadata with the method below — published in full because a score you can't interrogate is a score you shouldn't trust.
In March 2026, Addy Osmani named comprehension debt — the widening gap between how much code exists and how much of it any living person still understands. He named the condition. Grasp defines the measurement: the Comprehension Index — a methodology for quantifying how much of a codebase carries living human understanding, computed from repository metadata alone.
This is a different question than every code metric before it. Cyclomatic complexity, the Maintainability Index, cognitive complexity — they all score the code: how tangled it is, how hard it reads. The Comprehension Index scores what none of them can see — the people's grasp of it: who wrote the code that still ships, who is still here, and what keeps changing with no living author behind it. Put simply: comprehension debt is the condition, the Comprehension Index is how you measure it, and the Grasp Score is the number this instrument produces.
The engine analyzes commit history (authors, timestamps, which files changed, co-author trailers) and, where API access exists, pull-request records (open/merge times, review events). For free scans we clone with git's --filter=blob:none, which means file contents are never transferred at all — the git protocol itself withholds them. We never read, store, or transmit source code.
| Term | Exact meaning |
|---|---|
| Active human | A human author (bots and AI agents excluded) with at least one commit in the last 90 days, anchored to the repo's newest commit. |
| Living knowledge | The share of a module's recent work (3-year window) attributable to currently-active humans. The org-level, size-weighted version is the Grasp Score. |
| AI-attributed floor | Work from commits authored or co-authored by identifiable AI agents and bots (co-author trailers, bot accounts). A floor: squash merges strip trailers, so true AI share is higher. We never report suspicion as fact. |
| Departed share | Work by human authors with no commits in the active window. In open-source repos this includes drive-by contributors, which overstates attrition versus a company roster. |
| Bus factor | Number of active humans each holding ≥10% of a module's human-authored work. |
| Heat | Commits touching the module in the last 180 days. |
| Risk (0–100) | The unknown share (1 − living knowledge), weighted 55%, plus up to 25% more when the module is hot and up to 20% more when ownership is thin. High risk = unknown code that still changes, held by few. |
Automation bots (CI, dependency updaters, release tooling), lockfiles, build output, and binary assets are excluded. Modules below a minimum activity threshold are not scored.
Line-weighted (full clones) weights authorship by lines added — it matches "what share of the code by volume has a living author," but verbose and generated authorship dominate. Touch-weighted (blobless free scans) counts each file-touching commit once — closer to how comprehension actually forms, but a 3,000-line generated commit counts the same as a one-line fix. The two proxies err in opposite directions, scores are comparable only within a mode, and every report states which mode produced it. In our published 22-repo benchmark the findings hold under both modes — when two differently-biased instruments agree, the conclusion is stronger than either alone.
Both of those are windowed churn views (default 3 years, disclosed on every report) — deliberately, because unwindowed activity counting punishes old projects for long-rewritten code. Diligence engagements add a third, windowless survivorship view: git-blame attribution of every line in the current tree, answering "who wrote the code as it exists today?" A line written fifteen years ago that still ships counts fully, credited to its author's current status. Churn shows where risk is accumulating now; survivorship shows the standing inventory of the asset. The two views are labeled and never mixed.
Where pull-request records are available we join PR timing with diff sizes to measure approval latency versus change size, merges with no recorded human review, merges reviewed only by AI bots, and comment-free approvals. Coverage is labeled on the output: full (every PR, with API credentials), sampled (size-stratified sample under public rate limits), or partial. The review record has known blind spots — pairing, pre-coordinated work, and review outside the platform's review feature are invisible to it — so these are process signals, never verdicts on individuals.
Living authorship is the right comprehension proxy in 2026 because authorship is still where comprehension mostly comes from. As agent-written code becomes the default, that assumption expires: in a repo where agents write most lines, low human authorship becomes true of healthy teams too, and comprehension migrates to other work — review, steering, specification, verification. Two distortions grow together as this happens: authorship share compresses toward zero even for well-run teams, while our AI-attribution floor undercounts more (squash merges strip trailers), overstating what remains. We are explicit about the consequence: authorship share will eventually retire as the headline number, and engagement share will replace it. The engine already collects the successor signals — human review depth on AI-authored change, human follow-up edits, touch-weighted steering patterns, and human authorship of steering artifacts (specs, rules files, tests). Baselines will move with the industry too: scores are most meaningful relative to same-era peers, which is what our benchmark corpus exists to provide. The formula is versioned and will change; the question it answers — who still understands this system? — will not.
Living authorship is a proxy for comprehension — someone can understand code they didn't write, and write code they don't understand. Identity resolution from git emails is heuristic. AI attribution is a floor, not an estimate. Open-source "departed" overstates attrition. Blobless free scans truncate contributor history to the 3-year window. Content-curation repositories (link lists, awesome-lists, docs collections) are built by many one-time contributors by design, so authorship-based scores there reflect the contribution model, not decay — when ≥70% of a repo's analyzed changes are documentation or content files, its report carries a banner saying exactly that, and the active-maintainer count is the better health signal. The score itself is never adjusted: we disclose interpretation rather than fudge numbers. Treat every score as a potential indicator that tells you where to look, not a diagnosis. Believe a number is wrong? Tell us — we correct verified errors and version our reports.