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. Most-cited form across the saved-insights corpus, often used as the criterion that decides which structural moves stay and which get cut.

Encounters

• “Load-bearing instruction” — KCC CLAUDE.md guidance: rules that genuinely change agent behavior, vs. boilerplate that doesn’t.
• “The bottom of the stack is loose” — program-identity work: when the lowest layer of an abstraction stack has hidden failure modes, everything above carries unsupported weight.
• “Load-bearing test” — cog-sci framework critique: the test for whether a proposed metadata field or structure deserves to exist (would observable behavior change without it?).
• “Load-bearing pattern” — various design decisions: which architectural choices are doing actual work vs. inherited shape.
• “Load-bearing reason” — uniformity-dividend entry: uniformity without a load-bearing reason is cargo cult.

When it applies / triggers on

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?“. 53% of corpus matches (168/315) have a removal or scope verb in the preceding user message (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: Engine 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).

Composes with

• 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 (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 — load-bearing piece + non-load-bearing surface = the right architectural decomposition; load-bearing piece is the moat, surface is the polish.

When it doesn’t apply

• 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.

Sources

• Civil-engineering metaphor (load-bearing walls).
• Heavily used in James’s reasoning across KCC and analogy projects; the most reached-for form in the saved-insights corpus.

Canonical exemplars from corpus (T2 2026-05-17)

• Legacy-URL overengineering retrospective (cwd: campconnect, session: idx=2): “The load-bearing test would have caught this… ‘If I removed this, would observable behavior change?’ … none of them were doing work.”
• Jitter at concurrency=1 (cwd: campconnect, session: idx=4): “At concurrency=1: only one in-flight call → jitter changes nothing. At concurrency≥2: jitter actively prevents synchronized retry storms → load-bearing.”
• Leaflet vs Google Maps multi-axis (cwd: campconnect, session: idx=7): “The library + tile choice IS load-bearing for engineering cost … but barely load-bearing for UX … So we let engineering economics drive.”
• Fail-open all the way down (cwd: campconnect, session: idx=6): “The single load-bearing fix is putting an explicit audience signal somewhere — whichever stage you put it at, every later stage gets to assume it’s been done.”

Trigger pattern (T2): Load-bearing surfaces when the user prompts a scope question or proposes a removal/simplification (e.g., “do we need X?”, “is Z necessary?”) after the agent has worked on or just shipped the thing in question — three sub-shapes: pre-commit scope-narrow, post-commit retrospective, and multi-axis decision.