Simplification Audit¶

Essence¶

Simplification Audit reviews a simplified artifact after it has been created or adopted. Its question is not “how can we make this simpler?” but “what did simplification remove, and does any of that removed detail now matter for validity, fairness, safety, meaning, or operation?”

The archetype preserves the value of simplification while preventing hidden omission. A good audit does not restore all complexity. It identifies which omissions are harmless, which need caveats, which need exception routes, and which require revising or replacing the simplified artifact.

Compression statement¶

When simplification improves usability, speed, or tractability but may hide important variation, constraints, or cases, audit what was removed and decide whether to preserve the simplification, add exceptions, revise it, or escalate to a richer representation.

Canonical formula: simplified artifact + omission inventory + edge-case/distortion tests + consequence threshold + exception or revision path -> safer simplification without uncontrolled complexity creep

When to Use This Archetype¶

Use Simplification Audit when a simplified model, process, policy, interface, summary, dashboard, rubric, checklist, or solution is already being used and there is reason to suspect that omitted detail may matter. The trigger may be edge-case failure, stakeholder complaint, context drift, new use, higher stakes, subgroup harm, incident patterns, or user overconfidence in a compact representation.

Do not use it as the first step in making something simple. If the work is initial abstraction, compression, parsimony, approximation, or minimum-scope design, use those upstream archetypes. Simplification Audit is the downstream governance pass that asks whether the simplification still deserves trust.

Structural Problem¶

A simplified artifact gains usefulness by removing detail. That same removal can later become a hidden source of error. A dashboard hides caveats, a triage rule omits rare cases, a model drops variables, a policy removes context, or a process eliminates a step that had been silently protecting quality.

The structural problem is not complexity itself. The problem is unexamined omission after simplification. The system treats the simplified artifact as complete enough even though its omitted cases, assumptions, dependencies, or constraints may now affect decisions and outcomes.

Intervention Logic¶

The intervention begins by naming the simplified artifact and its intended preserved function. Reviewers then inventory omitted details: variables, cases, stakeholders, caveats, steps, assumptions, dependencies, context, exceptions, or boundary conditions that were removed for simplicity.

Next, the audit tests whether omissions matter. It uses edge-case testing, stakeholder probes, comparison to richer baselines, sensitivity checks, backtesting, red-team review, or model review. The audit then chooses a response: leave the simplification intact, add a caveat, add an exception route, revise the artifact, escalate high-stakes cases to richer analysis, or retire the simplification for the affected use.

Key Components¶

Simplification Audit organizes its components around a single governance question: which omissions made by a simplification have become decision-critical, and what should be done about them? The Simplified Artifact names the specific model, policy, dashboard, or process under review, so the audit targets a concrete simplification rather than complexity in general. The Simplification Intent records why the simplification was made — speed, usability, cost, tractability — so reviewers do not treat every removed detail as a defect. The Preserved Function or Invariant states what the artifact must still uphold, such as predictive validity, eligibility fairness, or safety margin. Together these three components define the standard against which omissions will be judged.

The next four components do the actual inspection work. The Omitted Detail List inventories what was removed — variables, cases, dependencies, exceptions, stakeholders — so omission becomes visible rather than implicit. The Omission Relevance Criterion sorts that list by consequence: which omissions remain safely absent, and which now affect decisions, equity, or safety. An Edge-Case Test stresses the artifact against boundary, rare, adversarial, or subgroup cases where simplification most often breaks. A Distortion Check looks for representational harm — whether the compact form misleads interpretation even when its facts are correct. Finally, three components convert findings into action: the Decision Consequence Threshold sets when revision becomes mandatory, the Exception Rule routes ineligible cases away from the simplified path, and the Revision Path ensures the audit ends in a concrete change rather than a list of grievances.

Component	Description
Simplified Artifact ↗	Identifies the simplified model, policy, process, representation, scope, interface, summary, or solution being audited. The audit needs a concrete simplification target. It should name what was simplified and for which intended use, rather than auditing generic simplicity.
Simplification Intent ↗	States why the simplification was made: speed, usability, communication, cost reduction, tractability, delivery, standardization, or cognitive load reduction. This prevents the audit from treating every omitted detail as a defect. The omitted detail matters only if it undermines the purpose or creates unacceptable harm.
Preserved Function or Invariant ↗	Defines what the simplified artifact must still preserve for the task to remain valid, fair, usable, safe, or decision-supporting. Examples include predictive validity, eligibility fairness, safety margin, causal relation, service coverage, interface meaning, or operational reliability.
Omitted Detail List ↗	Catalogs the cases, variables, dependencies, constraints, stakeholders, exceptions, assumptions, or context that were removed or compressed away. This component is central: without an explicit inventory of what simplification removed, the audit cannot test whether the removal was safe.
Omission Relevance Criterion ↗	Decides which omitted details are still irrelevant and which might affect decisions, outcomes, equity, safety, interpretation, or maintainability. The criterion should be tied to consequences. Some omitted details can remain omitted; others require exception handling or revision.
Edge-Case Test ↗	Tests the simplified artifact against boundary cases, excluded cases, rare cases, adversarial cases, subgroup cases, or high-consequence cases. Edge-case testing distinguishes this archetype from a generic completeness review. The focus is on cases that simplification is likely to erase or mis-handle.
Distortion Check ↗	Assesses whether the simplification changes meaning, hides dependencies, shifts incentives, erases important variation, or misleads decisions. A simplification can be factually compact yet still distort a user’s interpretation or action. This check looks for harmful representational effects.
Decision Consequence Threshold ↗	Sets the level of stakes or error consequence at which the simplified artifact must be revised, qualified, escalated, or replaced by a richer version. A lightweight simplification may be acceptable for low-stakes screening but unacceptable for irreversible, high-impact, or rights-affecting decisions.
Exception Rule ↗	Defines when omitted or edge cases should bypass the simplified route and receive a richer analysis, human review, special handling, or explicit caveat. Exception rules preserve simplification for common cases while preventing omitted cases from being invisibly forced through an inadequate simplification.
Revision Path ↗	Specifies how the simplified artifact is corrected: revise the model, add a caveat, expand scope, restore a variable, create a variant, or add an escalation path. The audit should end in an action. A list of flaws without a revision path becomes criticism rather than a solution archetype.

Common Mechanisms¶

Simplification Review (simplification_review, review_workflow): Runs a structured review of what a simplified artifact preserved, omitted, distorted, and now requires as caveats, exceptions, or revisions. This is a mechanism under the archetype. It implements the audit but does not define the whole archetype by itself.
Omission Checklist (omission_checklist, checklist): Prompts reviewers to identify removed variables, stakeholders, dependencies, assumptions, constraints, cases, failure states, and boundary conditions. Useful for making omissions explicit. It should not become a generic completeness checklist detached from simplification decisions.
Edge-Case Testing (edge_case_testing, test_procedure): Applies the simplified artifact to boundary, rare, adversarial, subgroup, or high-stakes cases to see where it breaks or misleads. Implements the edge-case test component. It can be manual, empirical, simulated, or scenario-based.
Assumption Audit (assumption_audit, audit_method): Surfaces assumptions introduced by simplification and checks whether those assumptions still hold in the target context. A reusable mechanism across many archetypes; here it is specifically aimed at assumptions caused by simplification.
Model Simplification Audit (model_simplification_audit, model_review): Compares a simplified model, surrogate, scoring rule, or approximation against richer evidence, edge cases, residuals, and known validity limits. Can support the model-specific variant. It should be coupled with revision or escalation rules rather than merely reporting model limitations.
Approximation Validation (approximation_validation, validation_check): Checks whether a simplified approximation remains within acceptable error or validity bounds for the decision it supports. This overlaps with Bounded Approximation, but here it functions as an audit mechanism after simplification has already occurred.
Stakeholder Review (stakeholder_review, participatory_review): Asks affected users, operators, maintainers, or stakeholders whether the simplification omits cases or constraints they consider important. Especially useful when omission harms are visible to affected parties but not to designers of the simplification.
Red-Team Review (red_team_review, adversarial_review): Challenges the simplified artifact by searching for ways it can mislead, exclude, be gamed, or fail outside its convenient assumptions. Useful when simplification is high-stakes, politically attractive, or likely to be overtrusted.
Sensitivity Check (sensitivity_check, analysis_method): Varies omitted or simplified variables to test whether conclusions change materially when simplifying assumptions are relaxed. Helps determine whether an omission is harmless or decision-critical.
Backtest Against Full Cases (backtest_against_full_cases, retrospective_test): Compares the simplified artifact against historical or fully documented cases to identify missed exceptions, distortions, and systematic failure patterns. Works best when a richer baseline or case record is available.

These mechanisms implement the archetype; they are not the archetype itself. An edge-case test, checklist, model audit, or stakeholder review only becomes Simplification Audit when it is tied to an omission inventory, relevance criteria, consequence thresholds, and a path for revision, caveat, exception, or escalation.

Parameter / Tuning Dimensions¶

Important tuning dimensions include audit depth, frequency, edge-case severity threshold, acceptable residual risk, breadth of stakeholder sampling, sensitivity-test range, consequence threshold, exception volume, documentation burden, and revision cost.

A shallow audit preserves speed but may miss harmful omission. A deep audit improves safety and fairness but can undermine the usability that justified simplification. Sensitive exception rules catch more edge cases but can create exception overload. Strict consequence thresholds protect high-stakes uses but may force richer analysis more often.

Invariants to Preserve¶

The simplified artifact must remain tied to its intended use. The audit must make omitted detail visible enough to inspect. Harmless omissions should remain omitted. Decision-critical omissions should trigger caveats, exceptions, revisions, or escalation. The audit must preserve useful simplicity rather than collapsing into uncontrolled complexity restoration.

Another invariant is actionability: material audit findings must connect to a response. A report that merely lists possible omissions but changes nothing is not a full implementation of the archetype.

Target Outcomes¶

The target outcomes are safer simplification, clearer validity limits, reduced oversimplification harm, better handling of edge cases, improved fairness and reliability in simplified systems, and less uncontrolled complexity creep. The archetype helps a system keep the benefits of simple artifacts while governing where they break.

It also improves trust. Users can rely on simplification more confidently when they know its omissions have been inspected, its exceptions are explicit, and its remaining risks are documented.

Tradeoffs¶

Simplification Audit trades speed against assurance. More review catches more omitted risk but slows the use of simple artifacts. It trades rule clarity against exception handling: more exceptions protect boundary cases but make the system harder to explain and maintain. It trades communication simplicity against caveat accuracy: adding context can prevent distortion but can also make a summary unreadable.

The best implementation does not maximize detail. It restores only the detail needed to preserve the artifact’s function, validity, fairness, or safety.

Failure Modes¶

Common failure modes include audit as complexity creep, checklist theater, average-case blindness, caveat dumping, false security from a one-time audit, and unbounded exception growth. The mitigations are relevance criteria, consequence thresholds, edge-case tests, stakeholder probes, explicit revision paths, re-audit triggers, and residual-risk documentation.

A particularly common failure is treating an audit as a reason to distrust all simplification. That is the wrong lesson. The archetype exists because simplification is valuable enough to protect, but risky enough to govern.

Neighbor Distinctions¶

Essential Structure Extraction (essential_structure_extraction): Essential Structure Extraction creates a task-relevant abstraction by stripping incidental detail; Simplification Audit inspects an existing simplification to see whether removed detail has become necessary.
Task-Relevant Compression (task_relevant_compression): Task-Relevant Compression designs compact representations; Simplification Audit checks whether compactness removed information that users now need.
Bounded Approximation (bounded_approximation): Bounded Approximation authorizes a simplified estimate by setting error bounds; Simplification Audit reviews whether a simplification still respects its validity domain and whether omitted details have become consequential.
Parsimony Filter (parsimony_filter): Parsimony Filter removes unsupported assumptions or features before adoption; Simplification Audit later tests whether removed assumptions, variables, or steps should be restored or handled as exceptions.
Minimum Sufficient Solution (minimum_sufficient_solution): Minimum Sufficient Solution finds the smallest solution that meets the core requirement; Simplification Audit examines whether that minimum has become insufficient in edge cases, new contexts, or higher-stakes use.
Uncertainty Explicitness (uncertainty_explicitness): Uncertainty Explicitness makes unknowns and confidence visible; Simplification Audit asks whether simplification has hidden or erased uncertainty, then decides whether to revise, caveat, or escalate.
Completeness Audit (completeness_audit): Completeness Audit searches for missing cases, states, stakeholders, or paths in general. Simplification Audit is narrower: the missing material was removed by a simplification and must be judged against the simplification’s intended function.
Boundary Critique Audit (boundary_critique_audit): Boundary Critique Audit interrogates inclusion and exclusion boundaries broadly. Simplification Audit focuses on simplification-induced omissions, though boundary critique can be one mechanism for finding them.
False Convergence Prevention (false_convergence_prevention): False Convergence Prevention prevents apparent agreement or stability from being mistaken for real convergence. Simplification Audit addresses omitted detail and distortion created by simplified artifacts, even when there is no apparent convergence problem.

The core boundary is simple: upstream archetypes create or justify simplification; Simplification Audit reviews whether a simplification has become unsafe, invalid, unfair, misleading, or insufficient because of what it removed.

Variants and Near Names¶

Recognized variants:

Model Simplification Audit (model_simplification_audit): Audits whether a simplified model, surrogate, scoring rule, or approximation has omitted variables, cases, or validity limits that matter for use. It remains a variant because It uses the same omission inventory, edge-case test, distortion check, exception rule, and revision path.
Process Simplification Audit (process_simplification_audit): Audits whether a streamlined process has removed checks, handoffs, context, or exceptions that are still needed for quality, fairness, safety, or reliability. It remains a variant because It still catalogs omissions, tests cases, checks distortion or harm, and defines exceptions or revisions.
Communication Simplification Audit (communication_simplification_audit): Audits whether a summary, dashboard, label, diagram, or brief has become misleading by removing uncertainty, caveats, context, or minority cases. It remains a variant because It uses omitted detail inventory, distortion checks, consequence thresholds, and revision paths for simplified representations.
Policy Simplification Audit (policy_simplification_audit): Audits whether a simplified rule or policy has erased exceptions, equity concerns, implementation constraints, or affected-party cases that still require treatment. It remains a variant because It still tests omitted details and edge cases and then adds exceptions, caveats, or revisions.

Aliases and near names:

Oversimplification audit (alias): Common near name emphasizing the failure mode rather than the intervention form.
Simplification review (alias): Plain-language alias for the same audit logic.
Omission audit (near_name): Useful retrieval term, but too broad unless tied to details omitted by simplification.
Abstraction audit (near_name): Near name when the simplified artifact is an abstraction; keep parent name broader because approximation, compression, and process simplification can also be audited.
Edge-case review (near_name): A common mechanism or emphasis under the archetype, not a full synonym by itself.
Model audit (related_mechanism_or_domain_variant): A model audit may implement this archetype when it specifically tests simplification-induced omissions; model audit is broader in other contexts.

Collapsed candidates include model audit, assumption audit, edge-case testing, and omission checklist when they function as mechanisms under this archetype. Boundary Critique Audit and Completeness Audit remain important neighboring candidates rather than collapsed Batch 027 outputs.

Cross-Domain Examples¶

public policy: A benefits agency audits a simplified eligibility rule and discovers that unusual household structures are wrongly excluded, so it adds an exception route and clearer documentation rather than abandoning the rule.
healthcare operations: A clinic reviews a simplified triage checklist after rare urgent cases are missed, then restores two warning signs and creates an escalation rule for ambiguous symptoms.
machine-learning governance: A screening model is audited for omitted context after average accuracy looks good but subgroup failures emerge; the team adds validity limits, human review triggers, and retraining requirements.
software deployment: A simplified release checklist is audited after incidents reveal that removed verification steps caught rare configuration errors; the team adds a conditional check for high-risk deployments.
executive reporting: A dashboard metric is reviewed because executives treat it as a complete measure of service quality; the team adds uncertainty, missing-case flags, and a companion drill-down path.
education: A simplified grading rubric is audited against student work that falls outside standard categories, leading to a clarified exception rule and examples for boundary cases.
supply-chain planning: A simplified demand model is tested against disruptions and seasonal anomalies, revealing that the omitted supplier lead-time variable matters above a certain order volume.

Non-Examples¶

Creating a simple diagram from a complex system for the first time. That is closer to Essential Structure Extraction or Task-Relevant Compression unless the task is to audit omitted details after the diagram is in use.
Choosing the simplest model that fits evidence before deployment. That is Parsimony Filter or model selection. Simplification Audit is the later review of whether the chosen simplification omitted something important.
Running a generic compliance audit with no connection to simplification. The trigger is not simplification-induced omission, so the archetype is not the right fit.
Adding every possible caveat to a summary. This defeats the simplification rather than auditing which omissions are decision-critical.
Using a full-fidelity analysis because simplification is unacceptable. The archetype governs safe simplification; if simplification is not allowed, there is nothing to audit as a simplification.