{
  "schema": "org-writing@v1",
  "slug": "bus-factor-zero",
  "kg": {
    "id": "org:writing:bus-factor-zero",
    "type": "brick",
    "graph": "/kg.json"
  },
  "title": "Bus factor zero",
  "subtitle": "The old worst case was the one person who understood it leaving, and the new one is nobody having understood it",
  "abstract": "Why the classic measure of project resilience stops working when a machine writes the code, and what has to be written down instead. The canonical treatment of bus factor zero.",
  "kind": "brick",
  "topics": [
    "Craft",
    "Deskilling"
  ],
  "courseMemberships": [
    {
      "course": "org:courses:craft",
      "topic": "Craft",
      "wall": "org:walls:engineering",
      "position": 5,
      "total": 5
    },
    {
      "course": "org:courses:deskilling",
      "topic": "Deskilling",
      "wall": "org:walls:economics",
      "position": 4,
      "total": 5
    }
  ],
  "publishedAt": "2026-08-03T00:00:00.000Z",
  "version": 1,
  "guidelinesVersion": 15,
  "brief": {
    "problem": {
      "text": "Teams still measure resilience by how many people hold a system in their heads, a measure that assumes at least one person once did, which generated code quietly stops guaranteeing.",
      "claims": [
        "bus factor of one"
      ]
    },
    "mechanism": {
      "text": "Generation outruns comprehension, so a system can reach production having never been understood by anyone including its author, and the mental model that maintenance depends on was never formed rather than merely lost.",
      "claims": [
        "outpaces the rate at which a human can read"
      ]
    },
    "move": {
      "text": "Externalize the reasoning while it still exists, record decisions rather than only code, and treat any artifact nobody can explain as unfinished no matter how well it runs.",
      "claims": []
    }
  },
  "sources": [
    {
      "repo": "mnstry-research",
      "path": "topics/engineering/monorepo/solo-spiral-methodology.md"
    },
    {
      "repo": "mnstry-research",
      "path": "topics/engineering/ai-assisted-development/03-patterns-gaps-synthesis.md"
    }
  ],
  "canonicalPath": "/writing/bus-factor-zero/",
  "body": "Software teams have measured a certain kind of fragility for decades with a grim little metric. The bus factor is the number of people who would have to be hit by a bus before the project could not continue, and a bus factor of one is the classic emergency: a single person holds the mental model, and everything from vacations to resignations becomes a risk to the system rather than to the person. Every remedy the industry built for this assumes the same thing, that the understanding exists and needs distributing. Pair programming distributes it. Code review distributes it. Documentation preserves it. Onboarding transfers it.\n\nNone of those work on a system nobody ever understood. That is the case a fluent generator makes ordinary, and it is one worse than the classic emergency rather than a variation of it. A model produces a subsystem faster than any person can read it, a solo developer or a small team accepts it because it passes, and the code enters production carrying no mental model anywhere. There is nothing to distribute. Six weeks later a bug appears in it and the author is in the position of a stranger reading someone else's work, except that the someone else cannot be asked, was never a someone, and left no reasoning behind because reasoning was not what it was producing.\n\nThe distinction that matters is between knowledge lost and knowledge never formed. Losing it is recoverable in principle, since archaeology on a repository is slow and miserable but it works, and the person who wrote the strange thing usually wrote it for a reason that can be reconstructed from what else was true at the time. Knowledge never formed leaves nothing to excavate. The code has no intent behind it, only the statistical residue of a million other codebases, so the question every maintainer eventually asks, why is it like this, has no answer at all rather than a hidden one. Systems in that state cannot be safely refactored, because you cannot tell load-bearing from accidental, and everything therefore has to be treated as load-bearing, which is another way of saying the system is frozen.\n\nNothing about this is an argument for generating less. It is an argument that comprehension has to be produced deliberately now, since it is no longer a free byproduct of typing. The reasoning has to be externalized while it still exists, in decision records that say why this database and not that one, why this threshold and not a rounder number, what was rejected and what would have to become true to revisit it. The generated explanation is worth having and is not the same artifact, because a model asked to explain code will tell you what it does with total fluency and cannot tell you what anyone intended. And the practical gate is the one sentence a person has to be able to say without looking, which is why this is safe.\n\nBus factor zero is not a caution about ambition. It is a reminder that a system is not finished when it runs, it is finished when somebody understands it, and that has always been the standard we were quietly meeting by accident and can now choose to meet on purpose.",
  "apparatus": {
    "note": "The human-facing essay is deliberately practical; this apparatus carries the full references, evidence-graded claims, article-local concepts, and research context behind it. Canonical concept definitions come from the concept registry.",
    "references": [
      {
        "id": "org:references:bus-factor-zero:r01",
        "author": "MNSTRY engineering research record",
        "work": "AI-augmented solo spiral development methodology (2026), on the bus factor dropping to zero and on knowledge graphing as the mitigation",
        "year": 2026,
        "relevance": "The origin of the brick's argument. Names the trap directly, that using a model to write code the developer does not understand takes a bus factor of one down to zero, and prescribes decision records as the externalization."
      },
      {
        "id": "org:references:bus-factor-zero:r02",
        "author": "MNSTRY engineering research record",
        "work": "Synthesis on AI-assisted architecture patterns and gaps (2026), on preserving why rather than what",
        "year": 2026,
        "relevance": "The maintainer's half of the problem: without recorded rationale, nothing distinguishes a load-bearing decision from an accidental one, so a system in that state cannot be safely refactored."
      },
      {
        "id": "org:references:bus-factor-zero:r03",
        "author": "Michael Nygard",
        "work": "Documenting Architecture Decisions (the architecture decision record format)",
        "year": 2011,
        "relevance": "The standard artifact the brick asks for. An ADR records the decision, its context, the alternatives, and the consequences, which is the reasoning that generated code does not leave behind."
      }
    ],
    "claims": [
      {
        "id": "org:claims:bus-factor-zero:c01",
        "claim": "The bus factor is a standard measure of project resilience, and a bus factor of one describes a project whose mental model is held by a single person.",
        "basis": "Long-established usage in software engineering practice and its literature.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:bus-factor-zero:c02",
        "claim": "Generation outpaces the rate at which a human can read and internalize code, so a system can reach production with no person holding a mental model of it.",
        "basis": "Practitioner observation in our engineering research record, and a straightforward consequence of the throughput difference; not a measured comprehension rate.",
        "confidence": "directional",
        "sources": []
      },
      {
        "id": "org:claims:bus-factor-zero:c03",
        "claim": "A system whose rationale was never recorded cannot be safely refactored, because load-bearing decisions are indistinguishable from accidental ones.",
        "basis": "The research record's gap analysis and ordinary maintenance experience; a practice claim about what recorded rationale buys, not a measured outcome.",
        "confidence": "directional",
        "sources": []
      }
    ],
    "concepts": [
      {
        "id": "org:concepts:bus-factor-zero",
        "name": "Bus factor zero",
        "definition": "The state of a system nobody has ever understood, including its author, reached when generation outruns comprehension. One worse than the classic bus factor of one, because the remedies for that case (pairing, review, documentation, onboarding) all assume an understanding exists somewhere to be distributed. Knowledge lost can be excavated; knowledge never formed leaves nothing to excavate, so load-bearing and accidental become indistinguishable and the system freezes.",
        "provenance": "canonical"
      },
      {
        "name": "Knowledge lost versus knowledge never formed",
        "definition": "Lost understanding can be excavated from a repository, since the strange decision was made for a reason that other facts of the time can reconstruct. Understanding that never formed leaves nothing to excavate, because the artifact has no intent behind it.",
        "provenance": "local"
      },
      {
        "name": "The explanation gate",
        "definition": "The shipping condition this brick proposes: a person can say, without looking, why the thing is safe. A system is finished when somebody understands it, not when it runs.",
        "provenance": "local"
      }
    ],
    "researchContext": "Extracted from \"The craft\" (essay parent), which keeps the narrative version.\nThe bus factor material appears in the parent only as a consequence of the\nverification inversion; this brick is its canonical home and carries the\ndistinction the parent has no room for, between knowledge lost and knowledge\nnever formed.\n\nAttribution note. The bus factor is common engineering usage rather than\nanyone's coinage, and the extension to zero comes from our own research\nrecord, which states it as the trap of using a model to write code the\ndeveloper cannot maintain. Nygard's decision-record format is named because\nthe brick asks for that specific artifact and it has an author. No claim is\nmade here about how often projects reach this state, because we have no\nmeasurement of that and the argument does not need one.\n\nBoundary with the sibling bricks. Verification inversion owns why checking\nbecame the job and the competence illusion owns why checking is hard; this\nbrick owns what remains when the checking is skipped, which is not a defect\nbut an absence."
  },
  "contract": "https://mnstry.org/contracts/org/org-writing.v1.schema.json",
  "releaseHash": "a692abd493fc2a70bd31a2636e700ad7326dc7f77e226b6cfc39a278035eb32b",
  "versions": [
    {
      "version": 1,
      "cutAt": "2026-08-03",
      "note": "Initial publication, craft wave",
      "visibility": "published",
      "path": "/writing/bus-factor-zero/",
      "contentHash": "sha256:540443235fcd931b",
      "releaseHash": "a692abd493fc2a70bd31a2636e700ad7326dc7f77e226b6cfc39a278035eb32b"
    }
  ]
}