Omission Checklist¶
Checklist — instantiates Simplification Audit
A standardized prompt sheet that forces reviewers to name what a simplification removed — the variables, cases, stakeholders, and steps dropped for simplicity — before anyone judges whether the loss matters.
Omission Checklist is the front-end enumeration instrument of a simplification audit: a fixed set of standing prompts that a reviewer walks category by category to write down everything a simplification left out. Its one defining move is that it only lists — it makes the removed material explicit and complete, and it deliberately stops before judging any of it. "What cases were dropped? Which stakeholders? Which dependencies, steps, assumptions, boundary conditions?" Each prompt drags one class of omission into writing. Everything the checklist produces is a candidate, not yet a defect; the point is that no omission can be evaluated until it has first been named, and the checklist guarantees the naming is systematic rather than whatever the reviewer happens to remember. That completeness-before-judgment discipline is what separates it from the mechanisms that test, weigh, or act on the list it hands them.
Example¶
A city consolidates its fourteen-page building-permit application into a one-page "express" form for small residential projects — decks, sheds, minor interior work. Months later, a few express permits turn out to have skipped review that mattered, and the planning office runs an Omission Checklist before deciding anything. A reviewer takes the standing prompt categories and diffs the express form against the full application, writing down each field the short form no longer asks: distance to a mapped wetland, presence of a shared access easement, whether the parcel falls inside a historic overlay district, and any prior stop-work order on the address. For every dropped field the reviewer records the stated reason it was cut — "rare for small projects," "slows intake," "usually caught later." The output is a flat inventory of roughly eleven omitted items, each tagged with its cut-reason, and nothing more. No item is yet marked dangerous; the wetlands-setback field and the historic-overlay field sit in the same list as the truly harmless ones. That undifferentiated inventory is exactly what the rest of the audit needs to start work on.
How it works¶
- Run a standing prompt taxonomy. A reusable set of categories — variables, cases, stakeholders, dependencies, steps, assumptions, exceptions, boundary conditions — so the same lens is applied every time and coverage does not depend on the reviewer's memory.
- Diff against a fuller reference. Compare the simplified artifact to its richer predecessor, a domain template, or an expert's mental full-model, and record each thing present there but absent here.
- Capture intent per item. Note why each was removed, so the list separates deliberate trims from accidental losses without yet asking whether the trim was wise.
- Optimize for coverage, not verdicts. The instrument's whole value is that the inventory is complete; a missed omission is invisible forever, while a listed-but-harmless one costs almost nothing.
The discipline that keeps it honest is that every prompt is tied to a simplification decision — "what did this trim remove" — not to generic presence-checking, which is what would turn it into an ordinary completeness checklist detached from the simplification.
Tuning parameters¶
- Prompt granularity — how fine the standing categories are. Finer prompts catch subtler omissions but lengthen the pass and invite fatigue.
- Diff source — predecessor artifact, canonical template, or expert recall. A concrete predecessor is most reliable; expert recall is fastest but leaves gaps exactly where the expert's blind spots are.
- Intent-capture depth — a one-word cut-reason versus a documented rationale per item. Deeper capture helps later triage but slows the enumeration.
- Stop point — pure list, or a light pre-sort that flags "obviously fine" items. Pre-sorting saves downstream effort but risks smuggling judgment into a step meant to stay neutral.
When it helps, and when it misleads¶
Its strength is cheapness and repeatability: it converts "we forgot we even dropped that" into a written record, and because it is a fixed instrument, two different reviewers produce comparable inventories. It is the reason a simplification audit can be systematic rather than a memory test.
Its failure mode is checklist theater — boxes ticked without thought, so the inventory looks complete while the reviewer never actually looked.[n1] Its subtler failure is drift into a generic completeness checklist: if the prompts stop asking "what did the simplification remove" and start asking "is field X present," the instrument loses its tie to the simplification and floods the audit with irrelevant missingness. The guarding discipline is to keep every prompt anchored to a simplification decision and to pair the finished list with a downstream relevance judgment, so the inventory becomes an input to a decision rather than inert paperwork.
How it implements the components¶
simplified_artifact— the checklist opens by naming the specific simplified artifact and the fuller thing it replaced, giving the inventory a defined target rather than auditing simplicity in the abstract.simplification_intent— each dropped item is recorded with the reason it was cut, so deliberate trims are visibly separated from accidental losses.omitted_detail_list— its output is this inventory: the enumerated catalog of removed variables, cases, stakeholders, dependencies, steps, and assumptions.
It stops at listing — it does not decide which omissions matter (omission_relevance_criterion); that judgment belongs to Sensitivity Check and to the umbrella Simplification Review, which also owns the routing to exception_rule and revision_path the checklist never touches.
Related¶
- Instantiates: Simplification Audit — the checklist is the enumeration front-end the whole audit is built on.
- Sibling mechanisms: Sensitivity Check · Approximation Validation · Backtest Against Full Cases · Model Simplification Audit · Simplification Review · Stakeholder Review · Assumption Audit · Edge-Case Testing · Red-Team Review
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Omission Checklist operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it a standardized prompt sheet that forces reviewers to name what a simplification removed — the variables, cases, stakeholders, and steps dropped for simplicity — before anyone judges whether the loss matters.
Independent corroboration: The frozen evidence defines Omission Checklist as 'A standardized prompt sheet that forces reviewers to name what a simplification removed — the variables, cases, stakeholders, and steps dropped for simplicity — before anyone judges whether the loss matters', so its operative form is Assessment, Review & Assurance.
Nearest alternative: Representation, Specification & Plan — Omission Checklist includes features of a static representation, map, specification, schema, or prospective plan that externalizes information, but its defining operation is a bounded evaluation of existing evidence or work that produces a finding or disposition.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: Safety and design-review practice developed checklists that force attention to predictable omissions before a simplified artifact is approved.
Related originating lineages:
- Medicine & Healthcare — Clinical checklist practice demonstrated how standardized prompts can prevent omission of critical actors, steps, and conditions.
- Organizational & Management Science — Decision-review checklists contribute naming omitted stakeholders and process steps.
- Ethics of Technology & AI Governance — Model documentation and impact assessment materially develop disclosure of excluded groups and assumptions.
Review resolution: Both independent reviews agree on primary origin engineering_design; reconciliation resolves reported_ambiguity, alternate_origin_disagreement, origin_mode_disagreement, domain_reach_disagreement. Formative alternate lineages retained: medicine_healthcare, organizational_management, tech_ethics_ai_governance. The broader reach of later applications is kept separate as domain_reach=universal; origin_mode=cross_disciplinary_synthesis describes the historical relationship among lineages. Confidence is conservatively reconciled to medium, and encyclopedia_synthesis=true preserves the reviewers' boundary judgment.
Attribution caveat: The checklist's specific focus on what simplification removed is an encyclopedia synthesis over the general checklist lineage. The checklist is deliberately generic, so the primary reflects the longest technical tradition of auditing model simplifications.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
The inventory it produces is a candidate list, not a defect list: an item's presence on it says only that the simplification removed something, never that the removal was wrong. Every downstream mechanism inherits whatever this list contains, and inherits nothing it omits — which is why the one quality that matters here is coverage, not discernment.
[n1] The disciplined-checklist tradition — the WHO Surgical Safety Checklist and Atul Gawande's The Checklist Manifesto — is the reference point: a checklist adds value only when each item forces a real look, and degrades into ritual box-ticking otherwise, which is precisely the failure this instrument must guard against. ↩