Completeness Audit

batch: First Iteration/Batch 07

slug: schema

slug: representation

slug: observability

components:
Intended Coverage Space
Scope Boundary Statement
Case or State Taxonomy
Coverage Map
Gap Analysis
Gap Resolution Policy
Completeness Evidence Record
Review or Appeal Path
Sampling Probe
Accountable Gap Owner
Audit Cadence
Exclusion Register

mechanisms:
Test Coverage Audit
Policy Gap Analysis
Stakeholder Inclusion Review
Data Completeness Check
Requirements Traceability Matrix
Risk Register Review
Coverage Checklist Walkthrough
Scenario Tabletop Review

essence_one_line: Systematically search for missing cases, gaps, states, stakeholders, paths, records, requirements, or risks so the system does not fail in unhandled regions.

compression_statement: When gaps in coverage create failure, ambiguity, inequity, blind spots, or false assurance, define the intended coverage space, map actual coverage against it, and repair, classify, escalate, or explicitly exclude the missing regions.

core_intuition: A system can look complete because the visible cases are handled. Completeness Audit works by making the implied universe explicit, then asking where actual rules, tests, records, responsibilities, or evidence fail to cover that universe. It turns “we did not think of that” into a findable, reviewable, and resolvable gap.

canonical_formula: declare intended coverage space → partition into cases/states/paths/stakeholders/requirements → map actual coverage → identify gaps and ambiguities → repair, exclude, escalate, or accept with rationale → record evidence and repeat as the system changes

structural_problem: A model, policy, process, dataset, taxonomy, design, test suite, or governance structure fails because relevant cases, states, paths, stakeholders, requirements, records, or risks are missing, implicit, weakly represented, or treated as if they were outside the problem without justification.

condition: The system claims to cover a domain, population, lifecycle, state space, risk space, or requirement set.

why_it_matters: Completeness can only be audited when there is a claim about what should be covered.

condition: Failures are appearing in edge cases, exceptions, transitions, omitted stakeholders, missing records, or rare scenarios.

why_it_matters: These symptoms often indicate that the actual coverage is narrower than the assumed coverage.

condition: Actors rely on a checklist, matrix, test suite, policy, taxonomy, or dataset as evidence of coverage.

why_it_matters: Artifacts can create false assurance unless they are checked against the intended coverage space.

condition: A system is entering a new context, population, scale, legal regime, market, or operating environment.

why_it_matters: New contexts often introduce cases that were absent from the original design assumptions.

condition: The cost of omissions is high, such as safety, rights, eligibility, financial, scientific, or public-trust consequences.

why_it_matters: High-stakes domains need explicit evidence that likely gaps were searched for and disposed of responsibly.

condition: Different groups disagree about whether an omission is outside scope, an edge case, or a defect.

why_it_matters: The audit makes boundary assumptions and exclusion decisions visible enough to review.

symptom: Repeated “we did not handle that case” failures.

diagnostic_hint: List recent incidents and classify whether they came from missing cases, missing states, missing owners, missing data, or missing rules.

symptom: Coverage artifacts exist but no one can explain what universe they are supposed to cover.

diagnostic_hint: Ask for the intended coverage space and explicit exclusions before accepting the artifact as evidence.

symptom: Boundary cases are decided ad hoc or routed through informal escalation.

diagnostic_hint: Look for decisions made by workaround, personal judgment, or one-off exception without a recorded disposition rule.

symptom: Stakeholders, records, scenarios, or requirements appear only after a failure, complaint, audit, or external review.

diagnostic_hint: Compare who or what appeared after failure against the original coverage map.

symptom: Different teams believe different things are covered.

diagnostic_hint: Compare actual coverage maps across teams; disagreement may reveal implicit gaps or duplicate assumptions.

symptom: A default path absorbs too many cases without evidence that those cases are genuinely equivalent.

diagnostic_hint: Audit the default bucket and separate true defaults from unexamined omissions.

root_tension: Completeness requires a bounded claim about “everything relevant,” but the relevant universe may be large, changing, contested, or only partly visible. The intervention balances tractability against the risk that an implicit omission becomes a hidden failure point.

case: The problem is that known cases are handled incorrectly, not that cases are missing.

why_not_this: Validation, quality assurance, debugging, or rule correction may be closer when the coverage universe is already explicit and complete enough.

case: The main need is to classify items consistently into an existing taxonomy.

why_not_this: Canonical Classification is closer when category consistency is the intervention rather than discovering missing categories or cases.

case: The main need is to link sources, requirements, decisions, or outputs through a chain.

why_not_this: Traceability Linking is closer when the issue is provenance or downstream connection; it can support Completeness Audit but is not the same pattern.

case: The system needs to preserve a condition during operation.

why_not_this: Invariant Guarding or Closure-Preserving Operation is closer when the issue is preventing invalid transitions rather than finding unhandled regions.

case: The coverage space is unbounded and the organization refuses to define a practical boundary.

why_not_this: The audit cannot succeed until a provisional boundary, sampling logic, or risk-based scope is declared.

structural_intervention: Make the intended coverage universe explicit, partition it into auditable units, map actual coverage against those units, identify missing or ambiguous regions, and assign each gap a repair, exclusion, escalation, deferral, or acceptance-with-rationale disposition.

step: Declare the coverage claim.

logic: State what the system is supposed to cover: cases, states, stakeholders, scenarios, requirements, records, risks, obligations, paths, or evidence types.

step: Draw the boundary and name edge uncertainty.

logic: Record what is inside, outside, and ambiguous so omissions cannot hide behind vague scope.

step: Partition the coverage space.

logic: Create a taxonomy, matrix, scenario set, stakeholder map, state model, data schema, or requirement list that can be compared against actual coverage.

step: Map actual coverage.

logic: Link rules, tests, owners, records, mitigations, artifacts, or evidence to the units they cover.

step: Identify gaps and weak coverage.

logic: Mark missing, weak, duplicate, stale, ambiguous, disputed, and overclaimed coverage rather than counting only presence/absence.

step: Assign a gap disposition.

logic: Repair the gap, explicitly exclude it with rationale, escalate it, defer it with owner and trigger, or accept residual risk with evidence.

step: Record evidence and schedule re-audit.

logic: Preserve the coverage map, gap decisions, owners, and review cadence so completeness does not decay invisibly.

rule: Coverage must be judged against a declared universe, not against available artifacts alone.

implication: A test suite, checklist, dataset, or risk register is not evidence of completeness until its intended coverage space is explicit.

rule: Every discovered gap needs a disposition.

implication: Finding gaps without repair, exclusion, escalation, deferral, or acceptance merely creates an unmanaged backlog.

rule: Explicit exclusion is preferable to silent omission.

implication: A justified exclusion can be reviewed; a silent omission cannot.

rule: Sampling can support but not automatically prove completeness.

implication: When exhaustive enumeration is impossible, sampling logic and residual uncertainty must be recorded.

rule: Boundary disputes are audit findings, not distractions.

implication: Disagreement over scope often reveals the most consequential gaps.

rule: Re-audit when the covered universe changes.

implication: New populations, risks, requirements, data sources, operating environments, or use cases can invalidate prior completeness evidence.

why_preserve: The audit must remain tied to a specific claim about what should be complete.

why_preserve: Every gap should have a recorded resolution, exclusion, escalation, deferral, or risk acceptance decision.

why_preserve: Scope assumptions and exclusions must stay inspectable so future reviewers can challenge them.

why_preserve: Coverage evidence must support the declared coverage claim rather than an easier or narrower substitute claim.

why_preserve: Cases, stakeholders, paths, or records affected by omissions should not disappear simply because they are rare, inconvenient, or politically weak.

outcome: Fewer unhandled cases and edge failures.

how_it_emerges: Missing regions are searched for before they become incidents.

outcome: Clearer scope and exclusion rationale.

how_it_emerges: The audit records what is inside, outside, ambiguous, and intentionally excluded.

outcome: Better accountability for gaps.

how_it_emerges: Each gap has an owner, disposition, evidence trail, or review path.

outcome: Reduced false assurance.

how_it_emerges: Artifacts are checked against the intended universe instead of being treated as proof by their existence.

outcome: More robust policies, designs, datasets, and processes.

how_it_emerges: Coverage is broadened, repaired, or explicitly bounded before the system is relied on.

outcome: Improved fairness and legitimacy in stakeholder-sensitive systems.

how_it_emerges: Omitted or boundary stakeholders become visible enough to include, justify exclusion, or provide appeal.

prose_essence:
Completeness Audit is the intervention of making an implied “whole” explicit and then checking whether the actual system covers it. The whole might be a set of cases, states, stakeholders, data records, requirements, risks, user journeys, legal exceptions, clinical pathways, or test conditions.

The archetype is not the mathematical property of completeness and it is not a generic review. It uses completeness as a design pressure: if the system claims to cover a domain, it should either cover the relevant regions, explicitly exclude them, or acknowledge residual uncertainty.

A good completeness audit turns hidden omissions into visible decisions. The result may be a repaired rule, a new test, an added stakeholder path, a filled data gap, a documented exclusion, a risk acceptance, or an escalation to someone with authority.

prose_when_to_use:
Use Completeness Audit when failure is likely to come from something being missing rather than from something known being done poorly. Common triggers include edge-case failures, missing records, unhandled exceptions, excluded stakeholders, orphaned requirements, untested behavior, undocumented risks, and ambiguous scope boundaries.

It is especially useful when people are relying on a coverage artifact such as a checklist, policy table, risk register, test suite, data schema, requirements matrix, or stakeholder map. Those artifacts can be useful, but they do not prove completeness until they are compared against the universe they are supposed to cover.

This archetype is also valuable after a system expands into a new population, legal environment, scale, domain, product line, or operating mode. Expansion often exposes gaps that were invisible in the original context.

prose_structural_problem:
The structural problem is a mismatch between assumed coverage and actual coverage. A policy may assume all relevant applicants are represented, a test suite may assume all important user paths are tested, a dataset may assume all needed populations are observed, or a risk register may assume all significant hazards are listed.

These failures often appear as surprises: “we did not think of that case,” “there is no owner for this path,” “that population was not in the model,” “the default rule does not fit,” or “the matrix has no row for this requirement.” The deeper issue is that the coverage space was never made explicit enough to compare against reality.

Completeness Audit addresses this by defining the relevant set, partitioning it into auditable units, mapping actual coverage, finding gaps, and assigning each gap a disposition.

prose_intervention_logic:
The intervention starts with a coverage claim. What, exactly, is supposed to be complete? The answer must be concrete enough to audit: cases, states, paths, stakeholders, requirements, records, risks, obligations, evidence types, or scenarios.

Next, draw the scope boundary. Boundary cases matter because omissions often hide at the edge. The audit should record what is inside, what is outside, and what is contested or uncertain.

Then partition the space. A taxonomy, state model, requirements list, scenario set, stakeholder map, data schema, or risk model creates units that can be checked.

After that, map actual coverage. Link current rules, tests, owners, records, evidence, mitigations, procedures, or artifacts to the units they cover.

Finally, identify gaps and assign dispositions. A gap can be repaired, explicitly excluded, escalated, deferred with an owner and trigger, or accepted with a recorded rationale. The archetype is incomplete if gaps are merely discovered and then left unmanaged.

prose_key_components:
### Intended Coverage Space

Defines the population, state space, case universe, stakeholder set, requirement set, or scenario set that the audit is supposed to cover. The intended coverage space prevents the audit from becoming an open-ended search for everything. It establishes what must be complete enough for the system purpose, while making the limits of that claim inspectable.
### Scope Boundary Statement

States what is inside, outside, and ambiguous at the edge of the audit boundary. Completeness cannot be judged without a boundary. This component also records contested or uncertain boundary cases so missing coverage is not hidden inside vague scope language.
### Case or State Taxonomy

Breaks the intended coverage space into meaningful classes, states, paths, stakeholders, requirements, risks, or scenarios. The taxonomy gives the audit something to compare against. It may be hierarchical, matrix-based, temporal, stakeholder-based, scenario-based, or data-field based depending on the domain.
### Coverage Map

Connects actual rules, tests, records, actions, artifacts, or responsibilities to the cases they are expected to cover. The coverage map turns completeness from a feeling into an auditable relation between intended coverage and actual coverage. It can reveal both gaps and redundant or conflicting coverage.
### Gap Analysis

Identifies missing, weakly covered, ambiguous, duplicate, or overclaimed regions in the coverage map. Gap analysis distinguishes true gaps from intentionally excluded cases. It also separates missing knowledge from missing handling, missing representation, missing ownership, and missing evidence.
### Gap Resolution Policy

Defines how discovered gaps are repaired, explicitly excluded, escalated, deferred, or accepted with rationale. A completeness audit is not complete when a gap is merely found. The intervention needs a disposition path so gaps do not become another undocumented backlog.
### Completeness Evidence Record

Captures the evidence that the audit was performed, what coverage was checked, what gaps were found, and how each gap was resolved. This record supports review, accountability, future re-audit, and learning. It is especially important when the audit affects safety, eligibility, rights, money, or public trust.
### Optional Components

**Review or Appeal Path** — Allows affected actors to challenge omissions, exclusions, or misclassified boundary cases. Useful when the audit could miss stakeholders or cases that insiders do not see. It is not always required for low-stakes technical completeness checks.
**Sampling Probe** — Uses representative sampling, stress cases, or adversarial examples to discover gaps when exhaustive enumeration is impossible. Sampling probes are helpful for very large or evolving coverage spaces, but they must not be mistaken for proof of total completeness.
**Accountable Gap Owner** — Assigns responsibility for deciding and completing the disposition of each discovered gap. Without ownership, the audit can create awareness without closure. Ownership should be linked to authority and resources.
**Audit Cadence** — Defines when the completeness audit is repeated or triggered by changes in the system, population, policy, data, or environment. Completeness decays as the world changes. Cadence prevents a one-time audit from becoming stale evidence.
**Exclusion Register** — Records intentionally excluded cases and the reason they were excluded. This prevents deliberate omissions from being rediscovered as accidental gaps and makes the moral, policy, or technical assumptions behind exclusions inspectable.

prose_common_mechanisms:
### Test Coverage Audit

This is an implementation mechanism for Completeness Audit, not the archetype itself. Checks whether tests cover intended functions, branches, conditions, requirements, risks, or user paths, and then identifies untested regions. It works when it is anchored to an explicit coverage space and followed by gap disposition.
### Policy Gap Analysis

This is an implementation mechanism for Completeness Audit, not the archetype itself. Compares a policy framework against relevant actors, situations, exceptions, rights, obligations, or edge cases to locate missing treatment. It works when it is anchored to an explicit coverage space and followed by gap disposition.
### Stakeholder Inclusion Review

This is an implementation mechanism for Completeness Audit, not the archetype itself. Examines whether the affected stakeholder set includes overlooked groups, boundary populations, indirect beneficiaries, or negatively affected parties. It works when it is anchored to an explicit coverage space and followed by gap disposition.
### Data Completeness Check

This is an implementation mechanism for Completeness Audit, not the archetype itself. Checks whether records, fields, observations, time periods, categories, or sources needed for valid use are present or explicitly marked missing. It works when it is anchored to an explicit coverage space and followed by gap disposition.
### Requirements Traceability Matrix

This is an implementation mechanism for Completeness Audit, not the archetype itself. Maps requirements to design elements, tests, owners, decisions, or deliverables so uncovered or orphaned requirements become visible. It works when it is anchored to an explicit coverage space and followed by gap disposition.
### Risk Register Review

This is an implementation mechanism for Completeness Audit, not the archetype itself. Uses a risk register to reveal unlisted hazards, uncovered mitigations, ignored scenarios, or risk categories without owners. It works when it is anchored to an explicit coverage space and followed by gap disposition.
### Coverage Checklist Walkthrough

This is an implementation mechanism for Completeness Audit, not the archetype itself. Uses a structured checklist to walk through expected cases, states, criteria, or controls and flag omissions or ambiguous coverage. It works when it is anchored to an explicit coverage space and followed by gap disposition.
### Scenario Tabletop Review

This is an implementation mechanism for Completeness Audit, not the archetype itself. Walks a group through plausible scenarios, edge cases, incidents, or user journeys to discover missing rules, owners, data, or response paths. It works when it is anchored to an explicit coverage space and followed by gap disposition.

prose_failure_modes:
**False completeness** happens when checked boxes or filled matrices are mistaken for true coverage. Mitigate it by requiring an explicit coverage-space statement and independent challenge of boundary assumptions.

**Scope creep audit paralysis** happens when the audit keeps expanding without a stop rule. Mitigate it with risk-based scope, residual uncertainty notes, and review triggers.

**Silent exclusion** happens when cases or stakeholders are treated as out of scope without being named. Mitigate it with an exclusion register and appeal path.

**Taxonomy blind spots** happen when the chosen categories hide combinations, transitions, minority cases, or unusual pathways. Mitigate this by checking intersections, real incidents, scenarios, and boundary cases.

**Unowned gap backlog** happens when gaps are found but no one has authority or responsibility to resolve them. Mitigate it with gap owners and disposition states.

**Stale completeness evidence** happens when the system changes after the audit. Mitigate it with cadence and change-triggered re-audit.

prose_neighbor_distinctions:
Completeness Audit differs from **Canonical Classification** because classification standardizes categories, while completeness audit asks whether relevant categories or members are missing.

It differs from **Traceability Linking** because traceability connects sources, requirements, decisions, and outputs. Traceability can support completeness auditing, but the audit is about missing coverage and gap disposition.

It differs from **Quality Assurance** because QA checks known standards or outputs. Completeness Audit questions whether the relevant cases, states, standards, or evidence are missing.

It differs from **Validation Rule** because validation applies known criteria. Completeness Audit asks whether the criteria and cases are complete enough.

It differs from **Closure-Preserving Operation** because closure keeps operation outputs inside a valid domain. Completeness Audit identifies missing regions of the domain or response set.

It differs from **Exhaustive Case Handling** because exhaustive handling defines behavior for every case. Completeness Audit may precede that work by discovering which cases exist and which are missing.

prose_cross_domain_examples:
In software, a team maps tests to functions, branches, user paths, error states, and requirements. Missing regions lead to new tests, risk acceptance, or explicit exclusions.

In public policy, an agency audits eligibility rules against household types, documentation states, language needs, accessibility needs, appeals, and boundary populations.

In data analytics, a report team checks that all required time periods, regions, populations, fields, and source categories are present or explicitly classified as missing.

In risk management, a team compares a risk register against operating modes, severe scenarios, handoffs, and controls to find unlisted hazards or uncovered mitigations.

In healthcare, a pathway is audited for comorbidities, contraindications, discharge states, follow-up barriers, and handoff failures.

In education, a curriculum team maps learning objectives to assessments and learner supports, then resolves uncovered objectives or unsupported learner groups.

prose_non_examples:
A generic review that asks whether something “looks complete” is not a Completeness Audit unless it defines what coverage space should be complete.

A test suite passing all current tests is not a Completeness Audit unless the tests were mapped against the intended behavior or risk space.

A default “other” category is not completeness. It may hide missing cases unless the default bucket is audited and justified.

A sorted or classified list is not completeness. It may be orderly while still missing members.

A validation rule that rejects missing required fields is not the same as auditing whether the required fields or populations are complete.

prose_tradeoffs:
Completeness competes with tractability. A system can always imagine more edge cases, but the audit must eventually use risk, stakes, and decision needs to set scope.

Explicit exclusion improves honesty but can create discomfort. It may reveal that a system deliberately excludes cases, stakeholders, or obligations that some actors believe should be included.

Broad coverage can be shallow, while narrow coverage can be deep. A good audit chooses scope and granularity consciously rather than accidentally.

Completeness artifacts can become bureaucratic theater. A matrix with every row filled is not useful if the rows are the wrong rows.

Finally, a completeness audit can delay action when used to pursue impossible certainty. Pair it with termination criteria, staged remediation, and residual-risk decisions when perfect coverage is impossible.

prose_invariants_to_preserve:
The audit must preserve a declared coverage space. Without a defined universe, completeness cannot be evaluated.

It must preserve boundary visibility. Scope decisions, exclusions, and ambiguous cases should remain inspectable.

It must preserve gap disposition traceability. Every discovered gap should have a recorded outcome: repair, exclusion, escalation, deferral, or accepted residual risk.

It must preserve alignment between evidence and claim. A checklist or matrix should support the actual coverage claim, not an easier substitute claim.

When people are affected, it must preserve visibility for rare, boundary, or low-power cases. A completeness audit should not convert omission into neutral-sounding scope language.

prose_target_outcomes:
The primary outcome is fewer failures caused by missing cases, states, stakeholders, paths, requirements, records, or risks.

A second outcome is clearer scope. The system becomes more honest about what it covers, what it excludes, and what remains uncertain.

A third outcome is better accountability. Gaps acquire owners, dispositions, evidence, and review paths.

A fourth outcome is reduced false assurance. Artifacts are treated as evidence only after being checked against the intended coverage universe.

A fifth outcome is better fairness and legitimacy in stakeholder-sensitive systems, because omitted groups and boundary cases become visible enough to address or justify.

prose_parameter_dimensions:
The most important tuning dimension is the **coverage boundary**. A narrow boundary makes the audit tractable but may miss important cases. A broad boundary improves discovery but can become slow, expensive, or politically contested.

The second dimension is **granularity**. A coarse taxonomy can hide gaps inside broad buckets, while a fine taxonomy can create overwhelming detail. The right grain depends on risk, stakes, and decision needs.

A third dimension is **evidence threshold**. Some contexts only need plausible coverage; safety-critical, legal, medical, or financial contexts may require stronger evidence and independent review.

A fourth dimension is **exhaustive versus sampled audit strategy**. Exhaustive enumeration is valuable when the space is finite and high-stakes. Sampling, stress cases, adversarial probes, and scenario walkthroughs are more realistic when the space is large or evolving.

A fifth dimension is **gap disposition strictness**. Low-risk gaps may be recorded for later; high-risk gaps may require repair before launch. Disposition should also account for whether exclusion affects rights, safety, eligibility, or legitimacy.

A sixth dimension is **cadence**. Completeness evidence decays when the population, environment, law, data sources, requirements, risks, or operating modes change.

prose_variants_and_near_names:
Important variants include case coverage audits, state-space completeness audits, stakeholder inclusion audits, requirements coverage audits, data completeness audits, and scenario or path coverage audits.

Near names include coverage audit, gap audit, completeness check, missing case audit, policy gap analysis, and requirements coverage review. These names should point back to Completeness Audit when the intervention includes coverage-space definition, coverage mapping, gap identification, and gap disposition.

Mechanism names such as coverage matrix, checklist, requirements traceability matrix, risk register, and data completeness check should not be promoted to separate archetypes unless they reveal a distinct transferable intervention beyond implementing the audit.

Exhaustive Case Handling is preserved as a promotion candidate because it may become a separate archetype when the work shifts from finding missing cases to assigning explicit behavior for every case.

Case Coverage Audit

variant_type: subtype

short_definition: Audit whether all relevant case classes, exception classes, and edge cases are represented and assigned a disposition.

distinctive_feature: Focuses on classes of cases and exceptions rather than on records, stakeholders, requirements, or scenarios.

distinct_from_parent: The parent can audit any coverage space; this variant specializes the coverage space as case classes.

still_same_parent_because: It still follows the same pattern: define coverage space, map actual coverage, identify gaps, and assign dispositions.

condition: Rules, decisions, tests, or procedures work for common cases but fail on edge cases.

why_it_matters: The main incompleteness is a missing class of cases rather than a missing data field or stakeholder group.

condition: A default branch silently absorbs cases that need explicit handling.

why_it_matters: The audit reveals whether defaults are legitimate simplifications or hidden gaps.

Case or State Taxonomy

role: Defines case classes.

Gap Resolution Policy

role: Assigns handling or exclusion.

Coverage Checklist Walkthrough

role: Walks through expected cases.

example_domains:
software edge cases
policy eligibility
clinical decision paths
legal exceptions

domain: software

example: Audit whether every API error state has a defined response.

domain: policy

example: Audit whether eligibility rules handle applicants with mixed status or missing documentation.

cause: Unusual cases are treated as ordinary defaults without justification.

mitigation: Require explicit review of defaulted cases.

State-Space Completeness Audit

short_definition: Audit whether all relevant states, transitions, modes, or lifecycle phases are represented and covered by rules, tests, or responses.

distinctive_feature: Uses state and transition structure as the coverage space.

distinct_from_parent: The parent covers many coverage universes; this variant treats states and transitions as the audited universe.

still_same_parent_because: The core intervention is still gap discovery and disposition within an intended coverage space.

condition: A system moves through states or phases and some states are unhandled.

why_it_matters: Uncovered states often produce undefined behavior, unsafe transitions, or stalled processes.

condition: The system has lifecycle stages, modes, statuses, or transitions that are represented inconsistently.

why_it_matters: Completeness must include the dynamic path, not just static categories.

Case or State Taxonomy

role: Enumerates states and transitions.

Coverage Map

role: Maps states to rules or tests.

Scenario Tabletop Review

role: Walks through transition paths.

example_domains:
workflow design
incident response
medical care pathways
software state machines

domain: workflow

example: Audit whether each application status has an owner, next action, and exit path.

cause: States are listed but transitions between them are not covered.

mitigation: Audit both nodes and edges in the state model.

Stakeholder Inclusion Audit

short_definition: Audit whether the affected stakeholder set includes overlooked actors, indirect stakeholders, boundary populations, and those with limited voice.

distinctive_feature: Treats stakeholder membership and voice as the audited coverage space.

distinct_from_parent: The parent can be technical or procedural; this variant emphasizes legitimacy, affectedness, and participation.

still_same_parent_because: It still maps intended stakeholder coverage to actual inclusion and resolves omissions.

condition: A decision, design, or policy claims broad validity but was built from an incomplete actor set.

why_it_matters: Omitted stakeholders can reveal missing harms, use cases, obligations, and legitimacy concerns.

condition: Boundary cases are politically, ethically, or socially consequential.

why_it_matters: The audit must address whose perspectives define completeness.

Scope Boundary Statement

role: Defines affectedness boundaries.

Review or Appeal Path

role: Allows omitted actors to challenge coverage.

Stakeholder Inclusion Review

role: Reviews actor inclusion.

example_domains:
public policy
product design
community planning
research ethics

domain: public policy

example: Audit whether proposed transit changes considered disabled riders, shift workers, and indirect service users.

cause: Stakeholders are named but not empowered to change the coverage map.

mitigation: Pair inclusion review with appeal and disposition rules.

Requirements Coverage Audit

short_definition: Audit whether every relevant requirement, obligation, decision, or specification is linked to implementation, test evidence, owner, or disposition.

distinctive_feature: Uses requirements-to-evidence mapping as the coverage check.

distinct_from_parent: The parent is broader; this variant is artifact-heavy and often uses traceability matrices.

still_same_parent_because: The transfer pattern remains a coverage-space audit and gap-disposition process.

condition: Requirements or obligations exist in one artifact but are not reliably implemented, tested, or owned.

why_it_matters: Completeness failure appears as orphaned requirements or unverified obligations.

condition: The organization needs evidence that nothing important fell through handoffs.

why_it_matters: Traceability makes missing coverage visible across artifacts.

Coverage Map

role: Links requirements to evidence.

Completeness Evidence Record

role: Documents audit evidence.

Requirements Traceability Matrix

role: Maps requirements to deliverables/tests.

example_domains:
software engineering
regulated systems
procurement
curriculum design

example: Map each security requirement to implemented controls and tests.

cause: Every requirement has a row but the evidence is weak or stale.

mitigation: Audit evidence quality and update cadence, not only row presence.

Data Completeness Audit

short_definition: Audit whether required records, fields, observations, periods, categories, or source types are present or explicitly classified as missing.

distinctive_feature: Treats missing records, fields, observations, or source categories as the coverage gap.

distinct_from_parent: The parent covers all forms of missing cases; this variant is data-record focused and often requires missingness classification.

still_same_parent_because: It still defines expected coverage and compares actual records against that expectation.

condition: Decisions, models, reports, or operations depend on data that may be partially missing.

why_it_matters: The main gap is not a missing policy response but missing or unclassified evidence.

condition: Missingness itself changes interpretation or fairness.

why_it_matters: The audit must record whether missing data are random, systematic, expected, or excluded.

Intended Coverage Space

role: Defines expected records/fields.

Gap Analysis

role: Classifies missingness.

Data Completeness Check

role: Checks records and missing fields.

example_domains:
data pipelines
health records
surveys
financial reporting

domain: analytics

example: Audit whether every required time period and region has observations before publishing a trend report.

cause: Missing values are treated as zero, absent, or irrelevant without classification.

mitigation: Separate absent, unknown, not applicable, withheld, and uncollected values.

Scenario or Path Coverage Audit

short_definition: Audit whether relevant scenarios, user journeys, escalation paths, or incident paths have defined handling and ownership.

distinctive_feature: Uses paths through a system as the coverage units.

distinct_from_parent: The parent can audit static lists; this variant audits dynamic sequences and scenario paths.

still_same_parent_because: The core logic remains coverage-space definition, gap detection, and gap disposition.

condition: The system can fail along a path rather than in a single missing case.

why_it_matters: Point-in-time coverage can miss gaps that only appear across sequences or combinations.

condition: The domain involves incidents, journeys, escalation, lifecycle paths, or contingency planning.

why_it_matters: Completeness must include path coverage, not only category coverage.

Coverage Map

role: Maps paths to owners/responses.

Gap Resolution Policy

role: Assigns missing path repair.

Scenario Tabletop Review

role: Rehearses paths to find missing coverage.

example_domains:
incident response
service design
emergency planning
customer support

example: Walk through outage scenarios to find missing communication owners or escalation triggers.

cause: Only normal paths are covered; failure and edge paths are ignored.

mitigation: Include stress, adverse, edge, and recovery scenarios.

Exhaustive Case Handling

short_definition: Define explicit handling for every relevant case class so cases do not fall through implicit gaps.

distinctive_feature: Moves beyond audit into complete rule/action assignment for each case class.

distinct_from_parent: Completeness Audit discovers and disposes of gaps; Exhaustive Case Handling may become a design archetype for assigning behavior to every case.

still_same_parent_because: Until drafted separately, it remains a natural subtype that depends on the same completeness logic.

source_primes: completeness set_and_membership closure

condition: The dominant work is designing a handling rule for every case, not merely finding missing cases.

why_it_matters: The intervention may be sufficiently action-oriented to deserve a standalone draft.

condition: Unhandled cases cause safety, rights, operational, or correctness failures.

why_it_matters: Exhaustive handling adds fallback, exception, and default rules after the audit reveals the coverage universe.

Case or State Taxonomy

role: Enumerates cases.

Gap Resolution Policy

role: Defines handling dispositions.

Coverage Checklist Walkthrough

role: Checks cases before handling assignment.

example_domains:
software branching
policy exception tables
clinical decision trees
incident playbooks

example: Replace a fall-through default with explicit handling for every enumerated event type.

cause: The taxonomy is incomplete but the handling table appears complete.

mitigation: Run a completeness audit before treating the handling table as exhaustive.

near_names:
Coverage Audit
Completeness Check
Gap Audit
Missing Case Audit
Policy Gap Analysis
Requirements Coverage Review
Coverage Matrix


Complexity Budgeting

type: archetype

source: generated

batch: First Iteration/Batch 28/Wave 2

aliases:
complexity budget
complexity cap
detail budget
feature budget
scope budget
assumption budget
complexity cost accounting

slug: parsimony

slug: complexity

slug: overfitting

slug: threshold

slug: uncertainty

components:
Complexity Metric
Complexity Budget
Value Justification
Addition Gate
Pruning Rule
Review Cadence
Budget Owner
Decision Impact Test
Complexity Ledger
Exception Protocol
Maintainability Threshold
Assumption Budget
Validation Load Budget
User Comprehension Limit
Rollback Path

mechanisms:
Feature Budget
Model Complexity Penalty
Design Complexity Review
Architecture Decision Record
Scope Budget
Assumption Budget
Maintainability Threshold
Complexity Ledger
Minimum Description Length Penalty
Change Control Gate

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

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.

core_intuition: Complexity is not free. Even useful details consume attention, testing capacity, maintenance effort, interpretability, and coordination bandwidth. A complexity budget turns that hidden cost into an explicit resource allocation problem: spend complexity only where it produces enough decision value, robustness, learning, safety, or user benefit.

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.

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

condition: Refinement is open-ended

meaning: There is always one more variable, feature, rule, exception, metric, dependency, or stakeholder request that could be added.

condition: Local additions look reasonable

meaning: Each individual addition has a plausible justification, but the combined burden degrades the whole system.

condition: Complexity costs are not charged

meaning: Teams track benefits or requirements but do not track the cognitive, maintenance, validation, onboarding, support, or coordination load created by additions.

condition: The core model or experience is being obscured

meaning: A previously understandable core is becoming harder to explain because too many refinements are layered on top of it.

condition: Validation capacity is finite

meaning: Added detail creates more combinations, cases, interactions, and failure modes than the team can test or monitor responsibly.

symptom: Feature bloat

diagnostic_meaning: The product, system, or process contains many capabilities that consume surface area or support time without strong use or value evidence.

symptom: Model sprawl

diagnostic_meaning: A model contains variables, parameters, segments, caveats, or exceptions that are difficult to explain and only weakly improve decisions.

symptom: Maintenance fragility

diagnostic_meaning: Changes become expensive because too many dependencies, options, rules, or special cases must be considered.

symptom: Review overload

diagnostic_meaning: Decision bodies spend more time debating complexity than using the system to make decisions.

symptom: False sophistication

diagnostic_meaning: Complexity creates the appearance of rigor even though the added detail does not materially improve behavior, prediction, safety, or user outcomes.

symptom: Unclear ownership

diagnostic_meaning: No one is accountable for deciding when the total complexity level has become too high.

root_tension: Refinement can increase realism, capability, and nuance, but each refinement also consumes scarce interpretability, maintenance, testing, coordination, and attention capacity. The tension is not simplicity versus complexity in the abstract; it is value-producing complexity versus unmanaged complexity debt.

case: Complexity is mandated by safety, law, or ethics

why_not_primary: A budget may still manage implementation burden, but it must not be used to discard required protections, rights, disclosures, or safety checks.

case: The system is under-specified and missing core functionality

why_not_primary: Use Core Model First, Progressive Fidelity Increase, or requirement clarification before imposing a tight budget.

case: The issue is a one-time search stopping decision

why_not_primary: A Refinement Stop Rule or marginal stop rule may be the better pattern when the main question is when to stop a refinement sequence.

case: The problem is merely high compute cost

why_not_primary: Optimization, dimensionality reduction, or resource scheduling may be more central if human understanding and maintenance burden are not the limiting factors.

structural_intervention: Define what counts as complexity cost, set an explicit budget for the current purpose and lifecycle stage, require additions to justify their value, and prune or defer details that exceed the budget without sufficient benefit.

Name the complexity-bearing surface

logic: Identify where complexity accumulates: features, variables, parameters, rules, dependencies, screens, handoffs, categories, assumptions, data sources, interfaces, or validation cases.

Choose complexity cost dimensions

logic: Translate “complexity” into observable costs such as cognitive load, parameter count, dependency count, exception count, support burden, testing matrix size, maintenance effort, or governance overhead.

Set a budget for the purpose and stage

logic: Define the maximum acceptable complexity load for the current decision, audience, lifecycle stage, risk level, or validation capacity.

Attach value justification to additions

logic: Require each proposed refinement to explain what decision value, risk reduction, user benefit, robustness, learning, or safety improvement it buys.

Compare value against complexity cost

logic: Admit detail only when its value is strong enough for the cost and when the total complexity remains inside the available budget or an explicit exception is approved.

name: Prune, consolidate, or defer low-value detail

logic: Remove complexity that no longer earns its place, consolidate overlapping detail, or defer additions until evidence or risk justifies a higher budget.

Reassess the budget over time

logic: Revisit the budget when the system matures, users become more expert, risk increases, validation capacity improves, or the purpose changes.

rule: Complexity must spend a named budget

application: A proposal cannot add detail without stating which complexity dimension it consumes and who will maintain or validate it.

rule: Budget depends on purpose

application: A teaching model, executive dashboard, production control system, and safety review may each need a different budget because they serve different purposes.

rule: Value evidence must match cost

application: Small additions may need lightweight evidence; expensive or irreversible complexity requires stronger evidence, validation, or risk justification.

rule: Exceeding the budget triggers pruning or exception review

application: When the budget is exhausted, the team must remove lower-value complexity, consolidate detail, defer the addition, or explicitly raise the budget with documented consequences.

rule: Hidden externalized complexity counts

application: Complexity moved to users, maintainers, downstream teams, compliance staff, or edge-case operators still belongs in the budget.

invariant: Core purpose remains legible

why_it_matters: The system should still be explainable in terms of the decision, model, service, or process it is meant to support.

invariant: Validation remains possible

why_it_matters: Added complexity should not create so many combinations or edge cases that the system can no longer be tested responsibly.

invariant: Maintenance remains feasible

why_it_matters: Future operators and maintainers need enough capacity to understand, update, repair, and govern the accumulated detail.

invariant: Useful nuance is not indiscriminately suppressed

why_it_matters: The budget is not a crude anti-detail rule; high-value complexity must remain admissible when it earns its cost.

invariant: Complexity costs are visible

why_it_matters: The intervention works only if costs are surfaced rather than hidden inside individual teams, downstream users, or future maintenance.

outcome: Higher signal-to-complexity ratio

explanation: The system retains refinements that materially improve decisions or outcomes and rejects complexity that mainly adds noise, surface area, or maintenance load.

outcome: More maintainable designs and models

explanation: Teams can explain why each retained layer exists and can remove it when it no longer earns its place.

outcome: Less feature and rule bloat

explanation: Requests for additions are evaluated against a shared limit rather than accepted because they are individually plausible.

outcome: More disciplined progressive refinement

explanation: Complexity Budgeting supports refinement by making each added layer justify its value before the model, design, or process becomes overloaded.

outcome: Clearer tradeoff conversations

explanation: The team can discuss which complexity is worth spending on rather than arguing vaguely about whether something is “too complicated.”

prose_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?”

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

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

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

prose_key_components:
### Complexity Metric (`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 (`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 (`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 (`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 (`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 (`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 (`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 (`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 (`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 (`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 (`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 (`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 (`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 (`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 (`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.

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

### Feature Budget (`feature_budget`)

This procedure implements the archetype by limits how many features, options, screens, customizations, or workflow branches a product or service may add during a planning cycle. A feature budget implements the archetype in product and service design, but the archetype is broader than feature management.

### Model Complexity Penalty (`model_complexity_penalty`)

This method implements the archetype by penalizes additional variables, parameters, interactions, or degrees of freedom unless they improve predictive, explanatory, or decision value enough to justify the burden. The reconciliation controls classify model_complexity_penalty as a mechanism under Complexity Budgeting or Refinement Stop Rule, not a standalone archetype.

### Design Complexity Review (`design_complexity_review`)

This ritual implements the archetype by creates a recurring forum or checklist where proposed additions are evaluated for complexity cost, value, maintainability, and alternatives. This mechanism can be lightweight for small teams or formal for safety-critical, regulated, or large-scale systems.

### Architecture Decision Record (`architecture_decision_record`)

This document implements the archetype by records why a complexity-increasing architectural choice was accepted, what alternatives were rejected, and what future review or rollback conditions apply. An ADR is an artifact that supports budget memory; it is not the intervention pattern itself.

### Scope Budget (`scope_budget`)

This workflow implements the archetype by caps the total scope of a release, project, policy package, research plan, or process redesign so additions must displace lower-value items or wait. Scope budgeting is often where complexity costs become visible to planning and governance.

### Assumption Budget (`assumption_budget`)

This checklist implements the archetype by limits or scores the assumptions a model, plan, forecast, or strategy is allowed to rely on before stronger evidence or simplification is required. This mechanism is especially useful when sophistication is being purchased through fragile premises.

### Maintainability Threshold (`maintainability_threshold`)

This metric_or_dashboard implements the archetype by defines a measurable or reviewable threshold for support burden, dependency count, change risk, documentation load, or operator workload. The threshold turns invisible future maintenance cost into a present budget constraint.

### Complexity Ledger (`complexity_ledger`)

This document implements the archetype by tracks complexity additions, budget use, exceptions, owners, review dates, and promised value so that decisions remain revisitable. A ledger is useful when complexity is added by many actors over time.

### Minimum Description Length Penalty (`minimum_description_length_penalty`)

This method implements the archetype by uses description length or model simplicity as a penalty so added explanatory machinery must improve fit enough to compensate for extra complexity. This is a specialized analytic mechanism; the general archetype also covers design, governance, product, and operational complexity.

### Change Control Gate (`change_control_gate`)

This workflow implements the archetype by requires proposed changes to pass a structured review of complexity impact, value, risk, and maintainability before entering the system. A change gate helps prevent complexity from entering through small, individually reasonable requests.

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

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

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

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

prose_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.”

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

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

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

prose_variants_and_near_names:
Feature Budgeting applies the pattern to product features, workflow branches, options, or service capabilities. It is often the most visible variant because feature bloat is easy to recognize.

Model Complexity Budgeting applies the pattern to variables, parameters, assumptions, segments, and interaction terms. Its mechanisms include model complexity penalties and description-length penalties, but those mechanisms are not the archetype itself.

Assumption Budgeting applies the pattern to hidden premise load. A model or plan may be too complex not because it has many visible parts, but because it depends on too many fragile assumptions.

Validation Load Budgeting applies the pattern to testing and monitoring capacity. It asks whether added detail can be responsibly validated.

Interface Complexity Budgeting applies the pattern to APIs, handoffs, user interfaces, governance interfaces, and coordination boundaries. It protects the receiving actor from unbudgeted burden.

Near names include complexity cap, detail budget, feature budget, scope budget, complexity cost accounting, and model complexity control. These should usually be retained as aliases, mechanisms, or variants rather than drafted as separate archetypes.

raw_bundle_path: solution_archetypes/_Batches/First Iteration/Batch 28/Wave 2/complexity_budgeting_solution_archetype_output_bundle.zip

Feature Budgeting

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

distinctive_feature: The complexity-bearing surface is product or process feature surface area.

distinct_from_parent: The parent archetype covers all complexity-bearing refinements; this variant specializes the budget around features, options, or workflow branches.

still_same_parent_because: It still uses the same cost visibility, budget, value justification, admission gate, pruning, and review loop.

source_primes: complexity parsimony

use_when: A roadmap is accumulating many small features or options.

use_when: The user experience is becoming harder to learn or support.

use_when: Teams need a principled way to reject or defer reasonable but low-value requests.

Complexity Metric

role: Tracks feature count, surface area, support burden, or user comprehension load.

Value Justification

role: Requires user value or strategic need for each feature.

Pruning Rule

role: Retires low-use or low-value features.

Feature Budget

mechanism_type: procedure

Scope Budget

mechanism_type: workflow

example_domains:
product management
service design
internal tools
workflow design

concise_examples: A release admits a new feature only if another feature is cut or if the new feature passes a support-cost review.

failure_modes: The budget can become an excuse to reject accessibility or safety features that actually deserve complexity spend.

Model Complexity Budgeting

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

distinctive_feature: The budget is tied to explanatory, predictive, or decision-value gains from model detail.

distinct_from_parent: The parent applies to any complexity-bearing system; this variant focuses on analytic and explanatory model structure.

still_same_parent_because: The intervention remains cost visibility plus budgeted admission and pruning of added complexity.

source_primes: complexity overfitting parsimony

use_when: A model is gaining predictors, segments, caveats, or interaction terms faster than interpretability or validation can keep up.

use_when: Added model detail improves apparent fit but not practical decisions.

use_when: Stakeholders need a transparent reason to keep or remove modeling detail.

Complexity Metric

role: Counts or scores model degrees of freedom, assumptions, terms, or validation cases.

Decision Impact Test

role: Checks whether added model complexity changes decisions or outcomes.

Validation Load Budget

role: Keeps the model testable and interpretable.

Model Complexity Penalty

mechanism_type: method

example_domains:
machine learning
forecasting
scientific modeling
policy analysis

concise_examples: A forecasting team accepts a new interaction term only if it improves out-of-sample performance and does not break interpretability requirements.

failure_modes: Overly strict budgets can underfit or ignore important heterogeneity.

Assumption Budgeting

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

distinctive_feature: The budgeted complexity is not visible surface area but hidden premise load.

distinct_from_parent: The parent budgets any complexity; this variant budgets assumptions as a specific hidden complexity source.

still_same_parent_because: Assumptions still consume validation, explanation, and maintenance budget and require the same budget discipline.

source_primes: uncertainty parsimony complexity

use_when: A plan or model looks plausible only because many assumptions are stacked together.

use_when: Assumptions differ in fragility and need to be rationed or stress-tested.

use_when: Decision-makers need to know whether sophistication is coming from evidence or from assumption load.

Assumption Budget

role: Limits or scores the assumptions carried by the solution.

Value Justification

role: Requires each assumption to earn its place.

Assumption Budget Checklist

mechanism_type: checklist

Complexity Ledger

mechanism_type: document

example_domains:
strategy
policy analysis
forecasting
risk assessment

concise_examples: A strategy memo identifies the three assumptions it is allowed to depend on and flags any proposal that needs more.

failure_modes: A numerical assumption count can hide a single very fragile assumption that dominates risk.

Validation Load Budgeting

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

distinctive_feature: The budget is defined by what can be responsibly validated, not only by what can be built or understood.

distinct_from_parent: The parent budgets general complexity; this variant budgets the test and evidence burden created by complexity.

still_same_parent_because: It uses the same logic of admitting complexity only when its cost can be paid.

source_primes: complexity overfitting uncertainty

use_when: The limiting resource is validation capacity rather than development capacity.

use_when: Added options or interactions create a combinatorial test burden.

use_when: The system is safety-sensitive, regulated, or high-stakes enough that unvalidated complexity is risky.

Validation Load Budget

role: Tracks the testing and monitoring cost of added complexity.

Review Cadence

role: Reassesses whether validation capacity still covers the system.

Design Complexity Review

mechanism_type: ritual

example_domains:
medical devices
regulated software
simulation
policy pilots

concise_examples: A simulator refuses a new behavioral module until the team can test the additional interaction cases it creates.

failure_modes: Validation capacity can be underestimated, letting untested complexity into production.

Interface Complexity Budgeting

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

distinctive_feature: The budget is applied to the boundary where actors or subsystems interact.

distinct_from_parent: The parent budgets any complexity source; this variant budgets interface surface specifically.

still_same_parent_because: Interface additions still need cost visibility, value justification, admission, pruning, and review.

use_when: Interfaces are becoming hard for users, teams, or systems to understand.

use_when: The burden of complexity is being shifted to integration partners or operators.

use_when: Interface growth threatens interoperability, safety, or usability.

User Comprehension Limit

role: Protects the receiving actor from unmanaged interface burden.

Maintainability Threshold

role: Limits future support and integration cost.

example_domains:
software APIs
operations handoffs
service design
governance interfaces

concise_examples: An API team caps optional parameters and modes unless integration partners demonstrate clear value and support capacity.

failure_modes: Complexity may be hidden inside documentation or support burden rather than counted at the interface.

near_names:
Complexity Cap
Detail Budget
Feature Budget
Scope Budget
Complexity Cost Accounting
Model Complexity Control