Key Person Risk

Who holds the knowledge, and what happens if they leave. Mapnostics reads the commit history of every indexed file, works out who wrote which lines, and names the areas that would lose their only author.

The headline number is how many key people this codebase has: the fewest contributors who, between them, wrote most of it. Engineers know this measure as the bus factor.

How it works

Ownership comes from GitHub's commit history, one entry per line of every indexed file. Mapnostics groups those lines by contributor, then rolls them up two ways: across the whole repository, and per module.

• Lines owned — the share of surviving lines a contributor last touched. This is the primary measure, because it reflects what is still in the file rather than how often somebody pushed.
• Files owned — the share of files where that contributor holds more lines than anybody else.
• Speciality — the three directories a contributor has written the most lines in.
• Orphaned modules — directories where one contributor holds more than half the lines, and the directory is large enough to matter.

A module here is a directory, one level below whatever root every file shares. It is the same structural axis the Code Map collapses on. Directories are not business capabilities, and this page never claims they are.

Live demo

The scan reads the history in batches and reports its progress. The report appears as the batches land.

Risk bands

Four bands, evaluated worst first. A contributor takes the worst band that applies to them, and the repository takes the worst band any contributor holds.

• Critical — one person owns more than 50% of the lines in a significant module. Their departure orphans it.
• High — one person owns more than 30% of the whole codebase, spread across modules rather than concentrated in one.
• Medium — the top two people hold the majority of the code between them, so there are 2 key people or fewer.
• Low — ownership is spread across the team. No single departure orphans a module.

What counts as a significant module

A directory qualifies when it holds at least three files and at least 5% of the repository's attributed lines. Below that, one person owning all of it is normal rather than a finding — a two-file scripts/ folder written by one engineer is not a key-person risk.

Reading the report

The headline number is the fewest contributors whose combined share passes half the codebase. A count of 1 means one person's departure takes the majority of the code's knowledge with them.

Under it, each engineer gets a card: their line and file shares, their speciality directories, and any module their departure would orphan. Recommendations name the modules to run knowledge-transfer sessions on, in the order the risk ranks them.

• Lines and files routinely disagree. One person can hold most of the lines while owning few files, or the reverse. Both are shown, because reporting only one hides half the exposure.
• A partial banner appears while a scan is still running. The numbers are real but cover only the files read so far.
• A repository with no scan shows a prompt, never a green result. Not measured and no risk found are different answers.

The same scan powers the Code Map's ownership panel and the summary on the repo Dashboard. Running it from any one of them fills all three.

Sharing and MCP

Shareable reports carry a Key-Person Risk section: the key-people count, the risk band, the top contributor's share and how many modules a departure would orphan. Individual contributors are not named on a shared link, because anyone holding that link can read it without an account.

Over MCP, get_bus_factor returns the full report including contributors, or status: not_scanned when no scan has run. Pass include_contributors: false for the headline alone.

What it cannot see

• The commit history attributes a line to whoever last touched it. A repository-wide reformat, a lint autofix or a mass rename moves attribution to whoever ran it.
• Knowledge is not the same as authorship. Somebody who reviewed every pull request in a module holds knowledge that no commit record shows.
• Only indexed files are scanned. Files excluded from indexing carry no ownership, and the file count here will not match the Code Map graph, which draws only files with import edges.
• The scan reads the GitHub API per file, so it runs on demand rather than as part of indexing, and it needs the repository connection to still be valid.