Complexity Budgeting

Limit added complexity so refinements do not exceed the system's ability to understand, maintain, validate, or use them.

Version

v1 · 2026-08-24 · History

Solution archetype #

192

Problem family

Complexity, Entanglement & Change Burden

Problem subfamily

Unearned Scope & Accidental Complexity

Essence

Complexity Budgeting treats complexity as a scarce resource rather than an accidental byproduct of refinement. The point is not to keep every model, product, policy, or process permanently simple. The point is to ask whether each added feature, variable, rule, dependency, exception, or layer earns the comprehension, validation, maintenance, and coordination cost it creates.

The archetype becomes especially useful after a core model or core design already exists. At that point, the easy answer to every problem is to add another detail. Complexity Budgeting changes the question from “Could this addition help?” to “Is this the best use of the complexity budget, and can we still understand, validate, and maintain the result?”

Compression statement

When every refinement adds complexity cost, set a complexity budget so added detail must earn its place and low-value complexity is pruned before it becomes structural burden.

Canonical formula: Admit a refinement only if its expected value exceeds its complexity cost, the total complexity remains inside the budget for the current purpose, and the added detail can still be validated and maintained.

When This Archetype Applies

Partial catalog groundingSome structural conditions are represented by existing abstractions, but no sufficient condition set is fully represented.

Diagnostic problem

A model, design, process, policy, or system accumulates complexity faster than its added value, becoming harder to understand, validate, maintain, govern, or adapt.

What this problem means

The structural problem is unmanaged accretion. A team begins with a workable core model, process, design, or rule. Then each stakeholder adds a small refinement: another feature, another caveat, another parameter, another approval, another dashboard, another exception. Each addition can be defended locally. But the total structure becomes harder to understand, harder to validate, harder to maintain, and easier to misuse.

This is not merely “too much complexity” in the abstract. Some complexity is valuable and necessary. The failure is that complexity is not being charged to any scarce resource. When there is no budget, the system accepts additions until the hidden costs show up as confusion, fragility, support burden, or false sophistication.

Applicability expression4 distinct conditions

Unbounded refinementandUnallocated complexity costsandCore obscured by complexityandFinite comprehensibility

Algebraic1∧2∧3∧4

2=a∨(b∧b′)∨c

′ context guard? connective not recorded∅ no catalog witness yet

groundedpartly groundedopen

4 conditions, all required.

4Required in every casenumbered 1–4

These hold no matter which pattern applies.

1

Unbounded refinement · grounded

Refinement is open-ended without a declared stopping or complexity budget. more

domainMoving the goalposts— An argumentative pattern in which, on being shown evidence that meets a previously stipulated standard, one party revises the standard upward to block the conclusion rather than accept it — repeated so that no finite evidence can settle the question.

How this was matched — 3 requirements, all needed

refinement remains open-ended without a declared bound

All of

• roleThe affected activity is an ongoing refinement process.
• polarityNo declared stopping criterion, complexity budget, or comparable effective bound constrains the refinement.
• relationThe missing bound leaves the refinement open-ended.

and — also required

2

Unallocated complexity costs · grounded · 3 illustrations, not alternatives

Added complexity costs are not charged to the feature, rule, exception, or owner that creates them. more

a

domainFeature Creep— Explain why a product accretes capabilities past net benefit as a governance failure, not a quality one — an approval gate that judges each addition in isolation against its stated cost while structurally blind to the compounding global cost of all additions together.

or — any one of these establishes this case

b

domainGolden Hammer Anti-Pattern— Diagnose a team applying its familiar technology to a poorly-fitting problem because the acquisition cost of an alternative is visible while the misfit cost is diffuse and downstream, so fluency reshapes what counts as the right tool before fit is ever asked.

AND both parts required

context guardthe downstream misfit cost consists of added complexity

suppliesA feature, rule, exception, owner, or comparable identifiable locus creates an increment of complexity. · The affected object is the cost imposed by that added complexity.

or — any one of these establishes this case

c

domainGold Plating— Diagnose a delivery overrun as producer-side unilateral scope expansion — quality or features added beyond the authorized envelope without the principal's sanction — whose real cost lives not in the polish but in the unbudgeted second-order burden it drags into downstream processes.

How this was matched — 3 requirements, all needed

added complexity cost is not charged to its creating locus

All of

• roleA feature, rule, exception, owner, or comparable identifiable locus creates an increment of complexity.
• roleThe affected object is the cost imposed by that added complexity.
• polarityThe added complexity cost is not charged to the same locus that created it.

and — also required

3

Core obscured by complexity · open

Accumulated approach complexity obscures the core model, task, or user experience. more

and — also required

4

Finite comprehensibility · open

The capacity to understand, maintain, and validate the system is finite. more

Other requirements and context (1)

Why these sit outside the expression

Supporting context — it may accompany or help interpret the situation, but it is not a load-bearing condition in a sufficient diagnostic set.

• Supporting contextLocal additions look reasonable.

Coverage

2 of 4 conditions grounded · 2 open.

Read the methodology · Download the trigger-logic data

When to Use This Archetype

Use Complexity Budgeting when refinements are accumulating faster than value. It fits situations where every additional detail has a plausible local reason, but the whole system is becoming harder to reason about. Typical signs include feature bloat, model sprawl, rule proliferation, growing exception lists, dependency overload, long support scripts, confusing dashboards, and validation matrices that expand faster than evidence capacity.

It is most useful when complexity has ongoing cost. A one-time complicated task may simply require effort. A complexity-bearing system, by contrast, must be explained, used, tested, monitored, updated, governed, and repaired over time. Those future costs are what the budget makes visible.

Structural Problem

The structural problem is unmanaged accretion. A team begins with a workable core model, process, design, or rule. Then each stakeholder adds a small refinement: another feature, another caveat, another parameter, another approval, another dashboard, another exception. Each addition can be defended locally. But the total structure becomes harder to understand, harder to validate, harder to maintain, and easier to misuse.

This is not merely “too much complexity” in the abstract. Some complexity is valuable and necessary. The failure is that complexity is not being charged to any scarce resource. When there is no budget, the system accepts additions until the hidden costs show up as confusion, fragility, support burden, or false sophistication.

Intervention Logic

Complexity Budgeting works by making the hidden cost of detail explicit. First, identify where complexity enters: features, variables, assumptions, interfaces, rules, dependencies, categories, exceptions, or validation cases. Then define cost dimensions that matter for the setting: cognitive load, maintenance burden, testing burden, support load, coordination overhead, user confusion, or future change risk.

Next, set a budget for the current purpose and stage. A prototype, teaching model, executive summary, production system, and safety-critical process may need different budgets. Each proposed addition must then provide a value justification. It should explain what decision improvement, risk reduction, user value, safety benefit, learning, robustness, or compliance value the added complexity buys.

The budget does not simply reject additions. It allocates complexity deliberately. High-value detail can be admitted. Low-value detail can be pruned. Some additions can be deferred until evidence or lifecycle stage changes. Others can be accepted as explicit exceptions with owners and review dates. The key is that complexity becomes a visible spend rather than an unmanaged default.

Key Components

Complexity Budgeting treats complexity as a scarce resource that must be allocated rather than absorbed by default. The Complexity Metric defines how complexity cost will be observed — feature count, rules, dependencies, model parameters, validation cases, support load, onboarding effort — so the conversation has units rather than aesthetics. The Complexity Budget sets the allowable envelope for a given purpose and lifecycle stage, stating the current limit and when it may change. The Value Justification requires each proposed addition to name the decision improvement, risk reduction, user value, safety benefit, or compliance value that the added complexity buys; "someone requested it" does not count. The Decision Impact Test goes further by checking whether the proposed addition materially changes the decision, outcome, risk posture, or user value the system is meant to support, blocking detail that is technically interesting but practically inert.

The next group of components governs how complexity actually enters, leaves, or stays in the system. The Addition Gate creates the decision point where proposed refinements are admitted, deferred, consolidated, or rejected, preventing accretion through many small local choices. The Pruning Rule defines how low-value or obsolete complexity is removed or merged when budget pressure appears, so the budget is not only an admission barrier. The Exception Protocol allows justified overruns for high-value or safety-critical reasons while keeping them visible and reviewable, preventing the budget from hardening into simplification ideology. The Rollback Path makes admissions less irreversible by specifying how an accepted addition can be removed when its promised value fails to materialize. The Review Cadence schedules recurring reassessment so the budget is not forgotten after the initial design, and the Budget Owner holds accountability for disputes about value, cost, exceptions, and hidden burden. The Complexity Ledger records accepted additions, rejected proposals, deferrals, exceptions, owners, and review dates so decisions remain revisitable.

Four further components anchor the budget to specific limits that complexity tends to externalize. The Maintainability Threshold defines the maximum operational burden that maintainers, support teams, or future designers can safely absorb, surfacing burden often pushed quietly onto downstream actors. The Assumption Budget limits the number, strength, or fragility of premises a model or plan is allowed to carry, preventing sophisticated-looking structures built on too many unsupported conditions. The Validation Load Budget tracks whether the system can still be tested, monitored, and validated after additions, watching the explosion of cases and interactions rather than only development effort. The User Comprehension Limit protects the people who must rely on the system from designer sophistication that outruns realistic understanding. Together these prevent the most common evasion: declaring a system simpler because its complexity has been moved somewhere harder to see.

Component	Description
Complexity Metric ↗	Defines how complexity cost will be observed, estimated, or scored in the current system. The metric may count features, rules, dependencies, model parameters, interface states, validation cases, support load, onboarding effort, or cognitive burden. It does not need to be mathematically perfect, but it must make complexity discussable and comparable.
Complexity Budget ↗	Sets the allowable complexity envelope for a model, design, process, policy, or subsystem at a given purpose and lifecycle stage. A budget can be numeric, categorical, time-boxed, capacity-based, or review-based. It should state the current limit and the conditions under which the limit can be changed.
Value Justification ↗	Requires each added detail to state the benefit it provides relative to its complexity cost. Typical justifications include decision improvement, risk reduction, user value, safety, robustness, learning, compliance, or maintainability. “Someone requested it” is not enough unless the request maps to a value claim.
Addition Gate ↗	Creates a decision point where proposed refinements are admitted, deferred, consolidated, or rejected based on budget impact. The gate prevents complexity from entering through many small local decisions. It can be formal, such as an architecture review, or lightweight, such as a checklist in a planning ritual.
Pruning Rule ↗	Defines how low-value or obsolete complexity is removed, merged, simplified, or postponed when budget pressure appears. Without a pruning rule, the budget becomes only an admission barrier. The rule should clarify what evidence triggers removal and how removal avoids breaking essential behavior.
Review Cadence ↗	Schedules recurring reassessment of complexity load, value evidence, exceptions, and budget fit. Complexity accumulates gradually, so the review cadence prevents the budget from being forgotten after the initial design decision.
Budget Owner ↗	Assigns accountability for maintaining the budget and resolving disputes about value, cost, exceptions, or hidden complexity. The owner is not necessarily a single person; it may be a product lead, architect, governance body, model steward, process owner, or review council.
Decision Impact Test ↗	Checks whether added complexity materially changes the decision, outcome, risk posture, or user value that the system is meant to support. This component protects against detail that is technically interesting but practically inert. If complexity does not change use, decision, or safety in a meaningful way, it may not deserve budget.
Complexity Ledger ↗	Records accepted complexity, rejected additions, deferred details, exceptions, owners, and review dates. A ledger is useful when complexity decisions recur and must be audited or revisited.
Exception Protocol ↗	Allows budget overruns when high-value, safety-critical, legal, or strategic reasons justify them. The protocol prevents a budget from becoming a rigid simplification ideology. It should make the exception visible and reviewable.
Maintainability Threshold ↗	Defines the maximum operational burden that maintainers, support teams, or future designers can safely absorb. This is especially useful in software, governance, and operational process settings where complexity is often externalized to maintainers.
Assumption Budget ↗	Limits the number, strength, or fragility of assumptions that a model or plan is allowed to carry. Assumption budgets help prevent models from becoming sophisticated-looking structures built on too many unsupported conditions.
Validation Load Budget ↗	Tracks whether the system can still be tested, monitored, and validated after complexity is added. This component is useful when the bottleneck is not development effort but the explosion of cases and interactions that must be checked.
User Comprehension Limit ↗	Defines the amount of complexity an intended user, decision-maker, operator, or learner can realistically understand and use. This prevents teams from optimizing for designer sophistication while making the system unusable for the people who must rely on it.
Rollback Path ↗	Specifies how an accepted complexity addition can be removed if its value does not materialize. A rollback path makes admissions less irreversible and supports experimentation without permanent bloat.

Common Mechanisms

Mechanisms implement Complexity Budgeting in particular domains. They should not be mistaken for the archetype itself. A feature budget, model penalty, review ritual, or decision record is only one way to operationalize the deeper pattern: make complexity cost visible, allocate a limit, require value justification, decide what enters, and revisit what has accumulated.

10 documented mechanisms across 4 implementation forms.

The grouping reflects forms represented among the mechanisms currently documented for this archetype; an absent form is not necessarily an impossible implementation.

Analysis, Modeling & Optimization · 2 mechanisms

• Minimum Description Length Penalty — Scores competing models by their total description length — the bits to encode the model plus the bits to encode its residual error — and selects the most compressive, so added machinery must pay for itself in fit.
• Model Complexity Penalty — Penalizes added parameters, features, rules, or tuning unless the additional performance gain generalizes and justifies the extra complexity.

Decision, Gate & Allocation · 2 mechanisms

• Change Control Gate — Requires each proposed change to a live system to clear a structured review of complexity, risk, and maintainability — and to carry a tested rollback — before it is admitted.
• Design Complexity Review — A recurring forum where a batch of proposed additions is deliberated together against complexity cost, value, alternatives, and whether the intended users can still comprehend the result.

Record, Log & Register · 2 mechanisms

• Architecture Decision Record — Records why a complexity-adding placement choice was accepted — the criterion applied, the host-dependency it commits to, and the conditions that would reopen it — so the decision is revisited on evidence, not relitigated from memory.
• Complexity Ledger — Keeps a running register of accepted complexity — each addition with its owner, promised value, budget consumed, exception status, and next review date — so accreted detail stays auditable and revisitable.

Rule, Policy & Commitment · 4 mechanisms

• Assumption Budget — Caps and scores the load-bearing assumptions a model, plan, or forecast is allowed to rely on, so fragile premises must be retired or evidenced before more are added.
• Feature Budget — Sets a standing cap on how many user-facing features, options, or screens a product may carry, pegged to what its intended users can actually comprehend and use.
• Maintainability Threshold — Sets a measured, reviewable ceiling on operational burden — support load, dependency count, alarm rate, or operator workload — turning future maintenance cost into a present, enforceable limit.
• Scope Budget — Fixes the total scope of a release, project, or plan so that any addition must displace a lower-value item already inside the envelope, or wait for the next cycle.

Parameter / Tuning Dimensions

The first tuning dimension is budget strictness. A tight budget preserves clarity and maintainability but can suppress necessary nuance. A loose budget encourages adaptation but may permit slow bloat. Good budgets are often stage-dependent: early exploration may allow more experiments, while operational systems may require stricter maintenance and validation limits.

The second dimension is complexity metric choice. Some contexts count features, model parameters, dependencies, categories, approval steps, or validation cases. Other contexts need qualitative measures such as user comprehension, policy accessibility, maintainability, or cognitive load. A narrow metric is easy to apply but easy to game; a broad metric is harder to measure but better at exposing hidden burden.

The third dimension is evidence threshold. Low-cost, reversible additions may need only lightweight justification. High-cost, irreversible, safety-sensitive, or fairness-sensitive complexity should require stronger evidence and clearer ownership. The evidence threshold should rise with complexity cost, risk, irreversibility, and externalized burden.

The fourth dimension is pruning aggressiveness. Some systems need regular pruning to stay usable. Others must preserve historical compatibility, legal commitments, or expert features. Pruning should be tied to value evidence and risk, not to an aesthetic preference for simplicity.

The fifth dimension is review cadence. A budget reviewed too frequently becomes bureaucracy. A budget reviewed too rarely becomes stale. The cadence should match the speed at which complexity enters and the cost of accumulated burden.

Invariants to Preserve

The first invariant is core purpose legibility. The system should still be explainable in terms of what it is trying to decide, provide, model, teach, regulate, or coordinate.

The second invariant is validation capacity. Added complexity should not create more states, interactions, edge cases, or assumptions than the team can responsibly test or monitor.

The third invariant is maintainability. Future maintainers, operators, reviewers, and users must be able to understand and repair the structure without heroic effort.

The fourth invariant is admissibility of valuable nuance. Complexity Budgeting is not an anti-detail ideology. It must leave room for detail that materially improves safety, fairness, robustness, accuracy, or user value.

The fifth invariant is cost visibility. Complexity pushed onto users, downstream teams, front-line operators, or future maintainers still counts. A design is not simpler merely because the complexity has been externalized.

Target Outcomes

The desired outcome is a better signal-to-complexity ratio. The system retains complexity that improves decisions, behavior, safety, or usability and rejects complexity that mainly creates surface area or maintenance burden.

A second outcome is a more maintainable refinement path. Teams can explain why complexity was added, who owns it, what value it is supposed to produce, and when it should be reviewed.

A third outcome is better prioritization. When complexity is budgeted, additions must compete with one another. This creates a clearer tradeoff conversation than accepting every locally plausible request.

A fourth outcome is reduced false sophistication. A model, policy, product, or process should not look better merely because it has more moving parts. Complexity should be justified by practical value.

Tradeoffs

Complexity Budgeting trades some flexibility for discipline. It may slow down additions that feel immediately useful, but it protects against accumulated burden that later makes the system hard to change. It also trades perfect measurement for actionable judgment. Complexity is not always easy to measure, but a rough and transparent cost model is often better than pretending complexity is free.

The main danger is overcorrection. A budget can become a simplification weapon if it rejects valuable nuance, edge-case protection, accessibility work, or safety controls. The right stance is not “less complexity is always better.” The right stance is “complexity must earn and keep its place.”

Failure Modes

A common failure mode is an over-tight budget. The system becomes clean but underpowered, ignoring important heterogeneity or risk. The mitigation is to maintain an exception protocol and reserve budget for high-impact complexity.

A second failure mode is metric gaming. Teams reduce the counted complexity while increasing uncounted burden elsewhere. The mitigation is to track multiple complexity dimensions and explicitly count burden imposed on users, maintainers, downstream teams, and future validation.

A third failure mode is bureaucratic review spiral. The budget mechanism becomes more cumbersome than the complexity problem. The mitigation is to scale review intensity to cost, risk, and reversibility.

A fourth failure mode is hidden exception accumulation. Exceptions pile up until they become the new unmanaged complexity. The mitigation is a ledger with owners, sunset conditions, and review dates.

A fifth failure mode is underfitting. A model or process becomes too simple for the real variation it must handle. The mitigation is a decision-impact test and a safety or fairness review before pruning important detail.

Neighbor Distinctions

Parsimony Filter asks whether assumptions, entities, or details are unsupported or unnecessary. Complexity Budgeting asks how much complexity the system can afford and whether each addition earns its spend.

Minimum Sufficient Solution asks for the smallest solution that meets the core requirement. Complexity Budgeting can continue after minimum sufficiency, allowing justified complexity while preventing uncontrolled accumulation.

Progressive Fidelity Increase adds realism or detail in layers. Complexity Budgeting governs how much complexity each layer is allowed to introduce.

Layered Model Validation tests whether an added layer improves the model or system. Complexity Budgeting asks whether the improvement is worth the added cost and whether the total burden remains supportable.

Refinement Stop Rule is a merge-sensitive neighbor. It focuses on when to stop refinement because marginal value no longer justifies cost. Complexity Budgeting is an ongoing allocation discipline throughout refinement, not only a terminal stopping criterion.

Technical Debt Containment manages deferred maintenance and accumulated obligations. Complexity Budgeting can prevent some debt by refusing complexity before it becomes embedded.

Cross-Domain Examples

In machine learning, a team may refuse extra predictors unless they improve out-of-sample decisions and remain explainable. The complexity metric may include variable count, interaction count, validation burden, and reviewability.

In software architecture, a platform team may cap service dependencies and configuration modes. A new dependency must show operational value, ownership, monitoring, and rollback before it is admitted.

In product design, a release may use a feature budget. A proposed feature must either replace lower-value complexity or pass a user-value and support-cost test.

In public policy, a benefits program may budget eligibility categories and reporting rules. More nuance can improve fairness, but too much administrative complexity can make the program inaccessible.

In organizational process design, a company may budget approvals, dashboards, templates, and handoffs. Each control must justify the time and coordination burden it adds.

In research design, investigators may budget exploratory analyses and subgroup comparisons to avoid interpretive sprawl and false sophistication.

Non-Examples

A manager saying “keep it simple” without a cost metric, budget, admission rule, pruning rule, or review cadence is not Complexity Budgeting. It is only a preference.

Removing all edge cases because they are inconvenient is not Complexity Budgeting. High-impact edge cases may deserve complexity spend.

Using a regularization penalty automatically is not the full archetype unless the complexity-value tradeoff is explicitly tied to the model’s purpose and decision use.

Stopping refinement only because time ran out is not Complexity Budgeting. A budget must define and allocate complexity cost, not merely end work by deadline.

Related Abstractions

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (3)

• Complexity: Measures system intricacy.
• Parsimony (Occam's Razor): Prefer simplicity.
• Progressive Refinement from Core Model: Incremental refinement.

Also references 6 related abstractions

• Diminishing Returns (Law of): Reduced output gains.
• Overfitting: Poor generalization.
• Resource Management: Allocation of finite assets.
• Threshold: Safe vs harmful levels.
• Trade-offs: Balancing competing priorities.
• Uncertainty: Incomplete knowledge.

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Feature Budgeting · subtype · recognized

Limit product, service, release, or workflow features so added capability must justify user, support, and maintenance complexity.

• Distinct from parent: The parent archetype covers all complexity-bearing refinements; this variant specializes the budget around features, options, or workflow branches.
• Use when: A roadmap is accumulating many small features or options; The user experience is becoming harder to learn or support; Teams need a principled way to reject or defer reasonable but low-value requests.
• Typical domains: product management, service design, internal tools, workflow design
• Common mechanisms: Feature Budget, Scope Budget

Model Complexity Budgeting · subtype · recognized

Limit variables, parameters, interactions, assumptions, or segments in a model unless they improve validated decision value enough to justify complexity.

• Distinct from parent: The parent applies to any complexity-bearing system; this variant focuses on analytic and explanatory model structure.
• Use when: A model is gaining predictors, segments, caveats, or interaction terms faster than interpretability or validation can keep up; Added model detail improves apparent fit but not practical decisions; Stakeholders need a transparent reason to keep or remove modeling detail.
• Typical domains: machine learning, forecasting, scientific modeling, policy analysis
• Common mechanisms: Model Complexity Penalty, Minimum Description Length Penalty

Assumption Budgeting · subtype · candidate

Limit the number, strength, or fragility of assumptions a model, plan, policy, or strategy may rely on before evidence, simplification, or review is required.

• Distinct from parent: The parent budgets any complexity; this variant budgets assumptions as a specific hidden complexity source.
• Use when: A plan or model looks plausible only because many assumptions are stacked together; Assumptions differ in fragility and need to be rationed or stress-tested; Decision-makers need to know whether sophistication is coming from evidence or from assumption load.
• Typical domains: strategy, policy analysis, forecasting, risk assessment
• Common mechanisms: Assumption Budget Checklist, Complexity Ledger

Validation Load Budgeting · risk or failure variant · candidate

Limit refinements by the amount of testing, monitoring, evidence, or review capacity required to keep the system trustworthy.

• Distinct from parent: The parent budgets general complexity; this variant budgets the test and evidence burden created by complexity.
• Use when: The limiting resource is validation capacity rather than development capacity; Added options or interactions create a combinatorial test burden; The system is safety-sensitive, regulated, or high-stakes enough that unvalidated complexity is risky.
• Typical domains: medical devices, regulated software, simulation, policy pilots
• Common mechanisms: Design Complexity Review, Change Control Gate

Interface Complexity Budgeting · implementation variant · candidate

Limit the number of states, options, dependencies, messages, or coordination requirements exposed through an interface.

• Distinct from parent: The parent budgets any complexity source; this variant budgets interface surface specifically.
• Use when: Interfaces are becoming hard for users, teams, or systems to understand; The burden of complexity is being shifted to integration partners or operators; Interface growth threatens interoperability, safety, or usability.
• Typical domains: software APIs, operations handoffs, service design, governance interfaces
• Common mechanisms: Change Control Gate, Architecture Decision Record

Near names: Complexity Cap, Detail Budget, Feature Budget, Scope Budget, Complexity Cost Accounting, Model Complexity Control.

Editorial Notes

Problem Classification

Classification: Complexity, Entanglement & Change Burden → Unearned Scope & Accidental Complexity

Problem kernel: complexity grows faster than demonstrated value

Rationale: Added detail, features, and rules increase validation and maintenance burden without earning their cost through purpose or evidence.

Independent corroboration: The earliest necessary condition in the frozen evidence is: A model, design, process, policy, or system accumulates complexity faster than its added value, becoming harder to understand, validate, maintain, govern, or adapt. That is a unearned scope and accidental complexity problem because A design, model, process, or successor system acquires more features, assumptions, detail, and support burden than its demonstrated purpose, evidence, understanding, or value warrants.

Review outcome: Independent reviewer agreement; high confidence.