A silo is a graph shape, not a personality

“Bus factor” slides usually fail for two reasons. They measure the wrong thing, and they feel like surveillance. Helix refuses both.

A silo is a file (or a folder) whose indexed changes have a single author. That is a shape on the graph: one AUTHORED person, no REVIEWED diversity, maybe an OWNS edge with no backup TOUCHED. It is not a judgment about the person.

Why the shape matters

When the only author of src/checkout.ts is out, the next change is slower and more dangerous. That is not because the author is a bottleneck by character. It is because the merge history did not spread the knowledge.

The Silo agent encodes that as a pattern. Pulse lists single-owner files. Helix Review holds a pull request if the owner of a silo is not on it. Ask Helix can answer “which files are silos?” with citations.

if (authors.size === 1 && reviewers.size === 0) {
  encode("silo", fileId, { owner: [...authors][0] });
}

Deterministic. Replayable. Clickable.

What not to do with it

Do not turn silos into a leaderboard. Do not page people for having expertise. The product move is the opposite: make the shape visible so the team can staff reviews, plan leave, and invite a second owner before the file becomes folklore.

CODEOWNERS is an assignment. A silo is what actually happened. They should inform each other. They are not the same claim.

Folders make the shape organizational

A file silo is a local risk. A directory with one TOUCHED person is a team risk. Helix lifts the same idea through CONTAINS so “who owns src?” is not a Slack poll.

Graph engineering is comfortable with uncomfortable facts as long as they stay facts. The moment you hide the shape to spare feelings, you also hide the staffing problem.

See the silos in a repository you care about. Open Helix and let the Silo loop mark them. Then decide, with evidence, who else should review.