engineering-and-technology

​

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: 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).

​

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

​

Relationships

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

​

Examples