{ "schema": "org-writing@v1", "slug": "removal-conditions", "kg": { "id": "org:writing:removal-conditions", "type": "brick", "graph": "/kg.json" }, "title": "Removal conditions", "subtitle": "Record what would have to be true before a decision could safely be removed, not only why it was made", "abstract": "Why a rationale does not survive contact with the next maintainer, and what a removal condition adds that the standard architecture decision record leaves out.", "kind": "brick", "topics": [ "Provenance at machine scale" ], "courseMemberships": [ { "course": "org:courses:provenance", "topic": "Provenance at machine scale", "wall": "org:walls:engineering", "position": 5, "total": 5 } ], "publishedAt": "2026-08-03T00:00:00.000Z", "version": 1, "guidelinesVersion": 15, "brief": { "problem": { "text": "A load-bearing decision recorded with only its rationale is still deleted by the next hand, because a reason explains a past choice to somebody who is making a future one.", "claims": [ "find out why a fence was put across a road before clearing it away" ] }, "mechanism": { "text": "A removal condition turns a decision into a testable claim about the present, so taking it out means arguing with a sentence instead of deleting a line.", "claims": [ "carries no field for the conditions under which the decision could be reversed" ] }, "move": { "text": "Beside every load-bearing decision write the condition under which its removal becomes safe, and treat the absence of that sentence as an unfinished record rather than a tidy one.", "claims": [ "each carrying an explicit removal condition alongside its rationale" ] } }, "sources": [ { "repo": "mnstry-research", "path": "topics/engineering/ai-assisted-development/04-enforcement-patterns.md" }, { "repo": "mnstry-research", "path": "topics/engineering/ai-assisted-development/03-patterns-gaps-synthesis.md" } ], "canonicalPath": "/writing/removal-conditions/", "body": "Chesterton's fence is the most quoted piece of advice in engineering and the least operational. The reformer who finds a fence across a road is told to go and find out why a fence was put across a road before clearing it away, and the advice is right and stops one step short. Knowing why the fence went up in 1974 tells you nothing about whether the reason still holds. You now have a history lesson and the same decision to make, and the person who wrote the history is not in the room.\n\nLook at what the standard artifact for this actually records. An architecture decision record, in the template most teams inherited, has fields for context, for the decision, for its status, and for its consequences. Every one of them is about the past. None of them is about the conditions under which the decision stops being right, so the document arrives in front of a future maintainer as an explanation of a choice they are considering undoing, which is the one form of evidence least likely to stop them. Rationale is an argument the author had with themselves. It was already won.\n\nThe addition is one more field and it changes the register of the whole document. Alongside the reason, record what would have to be true before removal is safe. A removal condition turns a decision into a testable claim about the present rather than a report about the past, so taking it out means arguing with a sentence instead of deleting a line. The annotation form our engineering record uses is deliberately plain, a marker naming the decision as load-bearing, the rationale, the alternatives that were rejected, and the requirement that would have to be satisfied for the thing to go.\n\nOur own record carries five of these, and reading them back is instructive because none of the conditions are impossible. The documentation hierarchy can go on the day an equivalent way of surfacing context at the point of decision exists. The abstraction over a third-party service can go when we either commit to that vendor deliberately or build a different abstraction. The two parallel data paths collapse into one the moment we drop either the server-rendering requirement or the offline requirement, and not before. A disabled lint rule comes back when the upstream conflict that forced it off is fixed. Each is a sentence somebody can meet, and meeting it is how the decision retires with dignity instead of being deleted in a cleanup.\n\nThe discipline earns its keep now for a reason that did not apply when these records were invented. A model asked to simplify a file will remove what looks redundant, and it is genuinely good at making things look tidy, because tidiness is a property visible in the text. Load-bearing is not a property visible in the text. It lives in a conversation held two years ago between people who have moved on, and a marker with a removal condition is the only form in which that conversation is present at the moment of decision, which is the same problem the craft has everywhere else and the same answer. Move the context to where the decision is made. The cost is one sentence written while you still remember why, and what it buys is that your reasoning gets to defend itself, in your absence, against arguments you will never hear.", "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:removal-conditions:r01", "author": "G. K. Chesterton", "work": "The Thing (the fence parable, in the chapter The Drift from Domesticity)", "year": 1929, "relevance": "The received view the brick concedes and then turns. The parable establishes the duty to learn the reason before removing the thing, and stops there, which is precisely the gap a removal condition fills." }, { "id": "org:references:removal-conditions:r02", "author": "Michael Nygard", "work": "Documenting Architecture Decisions", "year": 2011, "relevance": "The template most teams inherited, with its sections for context, decision, status, and consequences. Its field list is the evidence for the brick's central observation, that the standard artifact records only the past." }, { "id": "org:references:removal-conditions:r03", "author": "MNSTRY engineering research record", "work": "Enforcement patterns for machine-assisted development, and the patterns and gaps synthesis that applies them", "year": 2026, "relevance": "The annotation discipline itself (load-bearing marker, rationale, alternatives considered, removal requirement) and the five real decisions in our own estate that carry it, each with a removal condition that can actually be met." } ], "claims": [ { "id": "org:claims:removal-conditions:c01", "claim": "Chesterton's parable, published in 1929, tells the reformer to find out why a fence was put across a road before clearing it away.", "basis": "The Thing, 1929, in the chapter The Drift from Domesticity.", "confidence": "verified", "sources": [] }, { "id": "org:claims:removal-conditions:c02", "claim": "The widely inherited architecture decision record template records context, decision, status, and consequences, and carries no field for the conditions under which the decision could be reversed.", "basis": "Nygard's 2011 template and its subsequent adoption; a statement about what the sections are, checkable against the published form.", "confidence": "verified", "sources": [] }, { "id": "org:claims:removal-conditions:c03", "claim": "Our own engineering record marks five load-bearing decisions, each carrying an explicit removal condition alongside its rationale and the alternatives that were rejected.", "basis": "The patterns and gaps synthesis in our research vault, which enumerates them; a description of our own record, read before authoring.", "confidence": "verified", "sources": [] }, { "id": "org:claims:removal-conditions:c04", "claim": "The annotation discipline pairs the marker with a lint rule that fails on removal and a review step that displays the removal condition before a deletion proceeds.", "basis": "Specified in our enforcement-patterns record as a phased rollout. A designed mechanism whose effect on removal behaviour has not been measured, which is why the brick argues from the annotation rather than from an outcome.", "confidence": "directional", "sources": [] } ], "concepts": [ { "id": "org:concepts:removal-condition", "name": "Removal condition", "definition": "A recorded statement of what would have to be true before a decision could safely be undone, kept beside the rationale rather than in place of it. A rationale explains a past choice to somebody making a future one and loses that argument; a removal condition states a testable claim about the present, so removing the decision means meeting a condition or arguing with a sentence instead of deleting a line.", "provenance": "canonical" } ], "researchContext": "Reserved by the craft essay's apparatus and authored here on that reservation.\nThe parent gestures at the discipline in a single sentence and deliberately\nwent no further, so the brick owns the mechanism sentence, the claim cluster,\nand the argument in full; the parent's body is unchanged.\n\nThe five decisions are described by shape rather than by name. No vendor,\nframework, repository path, or file is identified, and nothing about the\nsecurity posture appears, which leaves the removal conditions themselves\nlegible and the estate undisclosed. That is the same treatment the parent\nessay gave its failure modes.\n\nThe enforcement half of the source record (lint rule, review step, phased\nrollout) is graded directional and carried lightly, because it is a designed\nmechanism with no measured effect on removal behaviour yet. The brick's\nargument rests on the annotation being present at the moment of decision,\nwhich is the craft pillar's standing thesis about context, not on any claim\nthat the tooling works. The sync-pair and archaeology annotations held with\nthis material in the parent's apparatus remain unauthored and stay reserved." }, "contract": "https://mnstry.org/contracts/org/org-writing.v1.schema.json", "releaseHash": "0b11b93574e9446a5bfa14fe91ade4d0fac27550ca11c98aa01bfe76c7047295", "versions": [ { "version": 1, "cutAt": "2026-08-03", "note": "Initial publication, provenance wave", "visibility": "published", "path": "/writing/removal-conditions/", "contentHash": "sha256:27466b93a46f4b5b", "releaseHash": "0b11b93574e9446a5bfa14fe91ade4d0fac27550ca11c98aa01bfe76c7047295" } ] }