{
  "schema": "org-writing@v1",
  "slug": "context-loss",
  "kg": {
    "id": "org:writing:context-loss",
    "type": "brick",
    "graph": "/kg.json"
  },
  "title": "Context loss",
  "subtitle": "Systems decay because nobody could hold the information, not because nobody had the judgment",
  "abstract": "What architectural decay is actually made of, and why the remedy is moving information rather than hiring better people. The canonical treatment of context loss.",
  "kind": "brick",
  "topics": [
    "Craft"
  ],
  "courseMemberships": [
    {
      "course": "org:courses:craft",
      "topic": "Craft",
      "wall": "org:walls:engineering",
      "position": 1,
      "total": 5
    }
  ],
  "publishedAt": "2026-08-03T00:00:00.000Z",
  "version": 1,
  "guidelinesVersion": 15,
  "brief": {
    "problem": {
      "text": "Good engineers, thorough reviews, and competent organizations still produce systems that degrade, and the moral explanations, carelessness and inexperience, do not survive contact with the actual cases.",
      "claims": [
        "Architectural failures are predominantly caused by lost context"
      ]
    },
    "mechanism": {
      "text": "The information that would have prevented the failure exists but sits outside the head making the decision, and no amount of experience adds working-memory slots to hold it, because expertise enlarges what fits in a slot rather than adding one.",
      "claims": [
        "expertise increases chunk size rather than slot count"
      ]
    },
    "move": {
      "text": "Manufacture the presence of context at the point of decision instead of assuming it, and codify a pattern before asking any tool to enforce it.",
      "claims": []
    }
  },
  "sources": [
    {
      "repo": "mnstry-research",
      "path": "topics/engineering/ai-assisted-development/01-ai-architecture-entropy-talk.md"
    },
    {
      "repo": "mnstry-research",
      "path": "topics/engineering/ai-assisted-development/03-patterns-gaps-synthesis.md"
    }
  ],
  "canonicalPath": "/writing/context-loss/",
  "body": "The usual account of why a system decays is a moral one. Somebody cut a corner, somebody was rushed, somebody did not know better. The account has the advantage of suggesting a remedy, which is better people, and the disadvantage of not surviving contact with the cases. An engineer adds one argument to a cached function, an options object where a plain value used to go. It compiles, the types check, the tests pass, and the cache silently stops hitting from that day forward, because every call now constructs a fresh object and the cache is keyed on identity. Walk that change backwards looking for the careless moment and there is not one. The engineer could not see the cache's key strategy from where they stood. Neither could the reviewer.\n\nThe same shape recurs with different materials. A reusable hook for dismissing a popup attaches a single listener to the document, which is correct, and a hundred instances of that popup across an application attach a hundred listeners that all fire on every click anywhere, which is a different program than anyone wrote. A coupon check goes into a checkout function long enough that no living person reads it end to end, and work that used to run in parallel now waits in line behind it. Somebody memoizes a property access that was already instant, and the bookkeeping costs more than the operation it protects. In each case the information that would have prevented the mistake existed somewhere in the repository, the version history, or the head of a person who has since left. It was simply not present where the decision happened.\n\nThat is the whole mechanism, and it is anatomical rather than professional. Working memory holds something on the order of four to seven chunks, the range running from Miller's 1956 estimate to Cowan's tighter modern one, and thirty years of expertise buys bigger chunks rather than more slots. A modern codebase grows exponentially in dependencies, state machines, asynchronous flows, and caching layers. The practitioner talk this argument comes from puts the mismatch in an image we did not expect to meet in an engineering setting, because this program already runs on it. You cannot hold the design of the cathedral in your head while laying a single brick. The failure is not that anybody stopped caring about the cathedral. It is that the cathedral has never once been visible from the scaffold.\n\nWhich changes what a remedy looks like. If decay were a competence problem the answer would be hiring and training, and organizations have tried that for decades against a steadily rising tide. If it is a context problem the answer is logistical, and the work is manufacturing the presence of the right information at the moment of the decision, in a form a reviewer can act on. This is where a model earns its place, and not by being clever. It applies the same scrutiny to the ten thousandth file as to the first and does not tire before a release, which are not intellectual virtues but the absence of a body. An engineer at Vercel spent years on performance work and, by the talk's account, distilled some four hundred pull requests into a structured rules repository built to be queried by agents, which is the discipline stated exactly. The order of operations is the catch, since a pattern has to exist before anything can enforce it, and no model will infer a rule from a codebase that applies it inconsistently.\n\nSo the honest reframe is also the encouraging one. Nothing about the people has to change, and the thing that does have to change is a thing that can be built.",
  "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:context-loss:r01",
        "author": "A practitioner talk on machine intelligence and software entropy (speaker not named in the research record)",
        "work": "Recorded in the MNSTRY research vault as 'AI architecture and software entropy' (2026), source captured as a public video link",
        "year": 2026,
        "relevance": "The origin of the argument this brick owns: entropy as lost context rather than deficient judgment, the four canonical failure modes, and the cathedral image. Unnamed because the record does not name the speaker, and everything drawn from it is graded directional on that basis."
      },
      {
        "id": "org:references:context-loss:r02",
        "author": "George A. Miller; Nelson Cowan; William Chase and Herbert Simon",
        "work": "The Magical Number Seven, Plus or Minus Two (1956); The magical number 4 in short-term memory (2001); Perception in Chess (1973)",
        "year": 2001,
        "relevance": "The capacity constraint under the argument, and the chunking result that keeps it honest. Expertise enlarges what fits in a slot; it never adds slots."
      }
    ],
    "claims": [
      {
        "id": "org:claims:context-loss:c01",
        "claim": "Architectural failures are predominantly caused by lost context rather than deficient judgment.",
        "basis": "The practitioner talk's central thesis, consistent with the working-memory constraint and with the four failure modes it enumerates. A framework claim from a single unnamed source, not a measured finding.",
        "confidence": "directional",
        "sources": []
      },
      {
        "id": "org:claims:context-loss:c02",
        "claim": "Working memory capacity is limited to roughly four to seven chunks, and expertise increases chunk size rather than slot count.",
        "basis": "Miller 1956 and Cowan 2001 for the capacity range; Chase and Simon 1973 and the subsequent expertise literature for chunk size as the thing training changes.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:context-loss:c03",
        "claim": "An engineer at Vercel distilled roughly four hundred performance pull requests into a structured rules repository built to be queried by agents.",
        "basis": "Reported in the practitioner talk and repeated in our research record; single-source and not independently verified, which is why the brick attributes it to the talk in the text.",
        "confidence": "directional",
        "sources": []
      }
    ],
    "concepts": [
      {
        "id": "org:concepts:context-loss",
        "name": "Context loss",
        "definition": "The condition in which the information needed to prevent a failure exists but is spread across more files, people, and moments in time than can be present in one head at the moment of decision. Architectural decay is this rather than deficient judgment, which makes the remedy logistical (put the context where the decision happens) rather than moral (find better people).",
        "provenance": "canonical"
      },
      {
        "name": "Four canonical entropy failure modes",
        "definition": "Abstraction concealing cost, fragile abstraction (a cached call broken by a new object identity), opaque abstraction (a function long enough that its asynchronous shape is invisible), and optimization without proof. Each is a context failure rather than a judgment failure.",
        "provenance": "local"
      }
    ],
    "researchContext": "Extracted from \"The craft\" (essay parent), which keeps the narrative version.\nAll three claims are restated verbatim from the essay's apparatus and graded\nidentically; if the parent's grades change at a version cut, this apparatus is\ncorrected in the same commit. The brick's contribution is the reframe from\nremedy to logistics: if decay were a competence problem the answer would be\nhiring, and because it is a context problem the answer is building something\nthat puts information where a decision happens.\n\nThe cathedral sentence in the body is the talk's, reached independently of\nthis program's own kiln, brick, and cathedral progression. We name the\nconvergence rather than absorb it, on the reasoning set out in the parent\napparatus.\n\nThe enforcement-annotation discipline that answers this brick's problem in\ncode, marking a decision load-bearing together with the conditions that would\nhave to hold before it could be removed, is deliberately reserved for a later\nbrick and is not argued here."
  },
  "contract": "https://mnstry.org/contracts/org/org-writing.v1.schema.json",
  "releaseHash": "50b1a806225e1aa286128994e4a5cd50b1f652779915788540b5034d58e734d7",
  "versions": [
    {
      "version": 1,
      "cutAt": "2026-08-03",
      "note": "Initial publication, craft wave",
      "visibility": "published",
      "path": "/writing/context-loss/",
      "contentHash": "sha256:97d5e1e2ebf2c791",
      "releaseHash": "50b1a806225e1aa286128994e4a5cd50b1f652779915788540b5034d58e734d7"
    }
  ]
}