> ## Documentation Index > Fetch the complete documentation index at: https://agentconcepts.io/llms.txt > Use this file to discover all available pages before exploring further. # load-bearing > Element actually carrying weight in a system; "what if I removed this?" diagnostic. computer-science engineering-and-technology logic # Load bearing ## Description The structural property of an element actually carrying weight in a system — if you removed it, observable behavior would change. The diagnostic question — *"what if I removed this?"* — separates genuinely load-bearing pieces from decorative scaffolding. Often used as the criterion that decides which structural moves stay and which get cut. ## Triggers **User-initiated:** User asks a scope or removal question about something the agent has just worked on or is about to ship — "do we need X?", "is jitter really necessary?", "is this the right choice?", "are we settled on Y?". A removal-or-scope verb in the preceding user message is a strong signal (`drop`, `remove`, `don't need`, `keep`, `worth`, `necessary`, `overengineered`). Three recurring sub-shapes: * **Pre-commit scope-narrow** — user proposes dropping a piece pre-commit; agent applies the diagnostic to validate the cut. (Example: "yes go ahead with the backoff array change. is jitter really necessary?" → agent reasons about concurrency=1 vs ≥2 and drops jitter.) * **Post-commit retrospective** — user signals the thing-just-built was overengineered; agent applies the diagnostic retrospectively and often names the meta-habit that produced the false positive. (Example: "btw dont care about lgacy url at this point … we dont need migration" → agent retrospectively finds none of the legacy-URL pieces were doing work.) * **Multi-axis decision** — user asks "is X the right choice?" between alternatives; agent applies the diagnostic per-axis. (Example: "Are we settled on a leaflet? Is that the right thing, or are there alternatives?" → agent decomposes into load-bearing-for-engineering-cost vs load-bearing-for-UX.) **Agent-initiated:** Agent notices a proposed structural element (a config option, a layer of indirection, a safeguard, a guardrail) whose contribution to observable behavior is unclear. Candidate inference: "would observable behavior change if this were removed?" Also fires when the agent encounters its own recent work and an opportunity to retrospectively prune. **Vocabulary cues:** "do we need X," "is X necessary," "drop X," "remove X," "worth keeping," "overengineered," "load-bearing test," "observable behavior," "doing real work," "actually carrying," "decorative," "scaffolding," "is this pulling its weight." **Situation-shape signals:** A piece of code, configuration, or process step whose justification is "we've always done it this way" or whose original load-carrying context may have changed. Also: a proposed safeguard or generalization for a state that hasn't existed long enough to accumulate (e.g., a migration path for a feature live for a few hours). ## Exclusions * **Redundant systems by design** — no single element is load-bearing because removal triggers failover. The right question becomes "what's the failure-survival capacity?" * **Decorative or social purposes** — branding, aesthetics, ritual. The "weight" being carried isn't structural; the load-bearing question category-mismatches. ## Structure Internal structure of load-bearing: a table of its component slots and the concepts that fill them. ## Relationships Relationship neighborhood of load-bearing: a graph of the concepts it connects to and the concepts it is a part of. * [stack-layer](/concepts/stack-layer) — load-bearing is the auditing question for stacks: *which layers are load-bearing for the layer above?* Lets you target fixes at the actual fault layer rather than its symptoms. * [cargo-cult](/concepts/cargo-cult) — *anti-pattern relationship* — cargo cult is treating a non-load-bearing element as load-bearing. The load-bearing test is the diagnostic that flags it. * [surface](/concepts/surface) — load-bearing piece + non-load-bearing surface = the right architectural decomposition; load-bearing piece is the moat, surface is the polish. ## Examples In a building, a load-bearing wall is one that carries weight from the structure above down to the foundation. The distinction matters because removing or relocating a load-bearing wall during a renovation can compromise the structural integrity of the whole building, while a non-load-bearing partition wall can be moved or removed freely. Builders inspect the framing and the structural plans to identify which walls are load-bearing before any structural change; the cost of getting that diagnostic wrong is large. The structural primitive — distinguishing elements that *carry weight* from elements that merely *look like they carry weight* — is one of the most portable in the catalog. In a codebase, the load-bearing test asks: if I removed this function / configuration line / dependency, what would actually break? In a doctrine or argument, the test asks: which premise is doing the work and which is decorative? In a process, the test asks: which step actually changes the outcome and which is ritual? **Inference**: Before removing or relocating anything that has been in place for a while, run the load-bearing test: "what depends on this?" If the answer is "nothing observable," removal is cheap and often valuable (the element was decorative or cargo-cult). If the answer is "an important downstream property," the removal needs explicit replacement. In an argument, the load-bearing premise is the one the conclusion actually rests on: negate it and the inference collapses, whereas dropping an illustrative or rhetorical premise leaves the conclusion standing. The diagnostic — *which premise, if false, sinks the conclusion?* — separates the crux from the supporting color. It is why a skilled objector attacks the load-bearing premise directly rather than picking at incidental ones, and why "granting everything except X" is a way of locating X as the assumption doing the work. A load-bearing line of code is one whose removal changes observable behavior — delete it and a test goes red or the system misbehaves. Its opposite is dead code: a branch that can never execute, a null-check for a value that is never null, a config flag nothing reads — all of which can be deleted with nothing observable changing. The diagnostic — *what breaks if I remove this line?* — is how you tell load-bearing code from decorative scaffolding before you touch either, and it is the same question that separates a real safeguard from cargo-culted ceremony.