Completeness Audit¶
Systematically search for missing cases, gaps, states, stakeholders, paths, records, requirements, or risks so the system does not fail in unhandled regions.
The Diagnostic Story¶
Symptom: Coverage artifacts exist — checklists, test suites, requirement matrices, policy documents — but nobody can explain what universe they are supposed to cover. Edge cases are decided ad hoc or routed through informal escalation. Relevant stakeholders, records, or scenarios appear only after a failure, complaint, or external audit. Different teams believe different things are included, and a default path quietly absorbs too many cases without evidence that they are genuinely equivalent.
Pivot: 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 defined disposition — repair, exclusion, escalation, deferral, or acceptance with rationale.
Resolution: Unhandled cases and edge failures decrease because gaps are found and assigned before deployment or enforcement. Scope and exclusion rationale become auditable rather than implicit. False assurance — treating a checklist as proof of coverage when it only documents what was thought of — becomes harder to sustain.
Reach for this when you hear…¶
[software testing] “Our test suite has ninety percent code coverage and it did not catch the bug because the coverage metric does not know which scenarios actually matter.”
[regulatory review] “We approved the policy for the standard cases, but the edge population we did not model is the one filing appeals.”
[product safety] “The hazard analysis covered the intended use but not foreseeable misuse, and that is exactly how the injury happened.”
When This Archetype Applies¶
No catalog groundingNone of the structural conditions is currently represented by an accepted prime or domain-specific abstraction.
Diagnostic 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.
What this problem means
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.
Show the applicability expression
Applicability expression3 distinct conditions
groundedpartly groundedopen
3 conditions, all required.
3Required in every casenumbered 1–3
These hold no matter which pattern applies.
Coverage claim · open
A system claims coverage of a domain, population, lifecycle, state space, risk space, or requirement set.
The source archetype describes the situation as follows: The system claims to cover a domain, population, lifecycle, state space, risk space, or requirement set. The normalized requirement above isolates the load-bearing portion used in this condition set.
Failures in omitted cases · needs review
Failures appear in edge cases, transitions, omitted stakeholders, missing records, exceptions, or rare scenarios.
The source archetype describes the situation as follows: Failures are appearing in edge cases, exceptions, transitions, omitted stakeholders, missing records, or rare scenarios. The normalized requirement above isolates the load-bearing portion used in this condition set.
Consequential coverage gap · open
At least one consequential case lies inside the intended coverage universe but outside the representational or procedural path that is treated as exhaustive.
This condition preserves a load-bearing part of the diagnostic problem that was not captured by a source-condition atom. It remains explicit because omitting it would weaken the sufficient condition set.
Other requirements and context (4)
Why these sit outside the expression
Supporting context — it may accompany or help interpret the situation, but it is not a load-bearing condition in a sufficient diagnostic set.
Supporting contextActors rely on a checklist, matrix, test suite, policy, taxonomy, or dataset as evidence of coverage.
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. In this archetype, the relevant contextual consideration is: Actors rely on a checklist, matrix, test suite, policy, taxonomy, or dataset as evidence of coverage. It helps interpret the situation or strengthens the practical case for examining the archetype.
Supporting contextA system is entering a new context, population, scale, legal regime, market, or operating environment.
This archetype is also valuable after a system expands into a new population, legal environment, scale, domain, product line, or operating mode. In this archetype, the relevant contextual consideration is: A system is entering a new context, population, scale, legal regime, market, or operating environment. It helps interpret the situation or strengthens the practical case for examining the archetype.
Supporting contextThe cost of omissions is high, such as safety, rights, eligibility, financial, scientific, or public-trust consequences.
Supporting contextDifferent groups disagree about whether an omission is outside scope, an edge case, or a defect.
Common triggers include edge-case failures, missing records, unhandled exceptions, excluded stakeholders, orphaned requirements, untested behavior, undocumented risks, and ambiguous scope boundaries. In this archetype, the relevant contextual consideration is: Different groups disagree about whether an omission is outside scope, an edge case, or a defect. It helps interpret the situation or strengthens the practical case for examining the archetype.
Coverage
0 of 3 conditions grounded · 2 open · 1 needing review.
Mechanisms / Implementations¶
- Test Coverage Audit: Checks whether tests cover intended functions, branches, conditions, requirements, risks, or user paths, and then identifies untested regions.
- Policy Gap Analysis: Compares a policy framework against relevant actors, situations, exceptions, rights, obligations, or edge cases to locate missing treatment.
- Stakeholder Inclusion Review: Examines whether the affected stakeholder set includes overlooked groups, boundary populations, indirect beneficiaries, or negatively affected parties.
- Data Completeness Check: Checks whether records, fields, observations, time periods, categories, or sources needed for valid use are present or explicitly marked missing.
- Requirements Traceability Matrix: Threads every requirement through to the design, code, and verification that satisfy it, so any requirement with no downstream link — or no passing test — is a visible coverage hole.
- Risk Register Review: Uses a risk register to reveal unlisted hazards, uncovered mitigations, ignored scenarios, or risk categories without owners.
- Coverage Checklist Walkthrough: Uses a structured checklist to walk through expected cases, states, criteria, or controls and flag omissions or ambiguous coverage.
- Scenario Tabletop Review: Walks a group through plausible scenarios, edge cases, incidents, or user journeys to discover missing rules, owners, data, or response paths.
Related Abstractions¶
Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.
Built directly on (3)
- Boundary Critique: Examines inclusion/exclusion assumptions.
- Completeness: No gaps in structure.
- Set and Membership: Groups and categorizes elements.
Also references 7 related abstractions
- Data Integrity: Accuracy and consistency preserved.
- Missing Data Mechanisms (MCAR, MAR, MNAR): MCAR, MAR, MNAR.
- Observability: Infer internal state externally.
- Representation: Model complex ideas.
- Sampling (Representativeness): Representative subset selection.
- Schema: Structured knowledge framework.
- Stakeholder Analysis: Identify involved parties.
Variants¶
Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.
Case Coverage Audit · subtype · recognized
Audit whether all relevant case classes, exception classes, and edge cases are represented and assigned a disposition.
State-Space Completeness Audit · subtype · recognized
Audit whether all relevant states, transitions, modes, or lifecycle phases are represented and covered by rules, tests, or responses.
Stakeholder Inclusion Audit · governance variant · recognized
Audit whether the affected stakeholder set includes overlooked actors, indirect stakeholders, boundary populations, and those with limited voice.
Requirements Coverage Audit · implementation variant · recognized
Audit whether every relevant requirement, obligation, decision, or specification is linked to implementation, test evidence, owner, or disposition.
Data Completeness Audit · domain variant · recognized
Audit whether required records, fields, observations, periods, categories, or source types are present or explicitly classified as missing.
Scenario or Path Coverage Audit · subtype · recognized
Audit whether relevant scenarios, user journeys, escalation paths, or incident paths have defined handling and ownership.
Exhaustive Case Handling · subtype · promote to full archetype candidate
Define explicit handling for every relevant case class so cases do not fall through implicit gaps.
Editorial Notes¶
Problem Classification¶
Classification: Correctness, Conformance & Formal Validity Failure → Coverage, Partition & Set Accounting
Problem kernel: relevant cases and paths are missing from the declared space
Rationale: A policy, model, taxonomy, or test claims completeness while stakeholders, states, requirements, or risks remain unrepresented.
Independent corroboration: The earliest necessary condition in the frozen evidence is: 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. That is a coverage partition and set accounting problem because A declared possibility or membership space has gaps, overlaps, missing combinations, collisions, unreachable targets, or unreliable accounting of covered and uncovered regions.
Review outcome: Independent reviewer agreement; high confidence.