Completeness Audit¶
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.
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.
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
When to Use This Archetype¶
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.
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.
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.
Key Components¶
Completeness Audit converts an implicit "everything relevant" into an inspectable claim and then checks whether the system actually covers it. The Intended Coverage Space defines the population, state space, case universe, stakeholder set, or scenario set that the audit is supposed to cover, preventing the work from becoming an open-ended search for everything. The Scope Boundary Statement records what is inside, outside, and ambiguous at the edge, because omissions most often hide at the boundary and vague scope language is itself a hiding place. The Case or State Taxonomy partitions the coverage space into auditable units — classes, states, paths, requirements, scenarios, or stakeholder groups — giving the audit something concrete to compare actual coverage against.
The audit's diagnostic spine maps reality to that taxonomy and assigns disposition to every gap it finds. The Coverage Map connects actual rules, tests, records, owners, or evidence to the cases they are meant to cover, turning completeness from a feeling into an auditable relation. The Gap Analysis identifies missing, weakly covered, ambiguous, duplicate, or overclaimed regions in that mapping, distinguishing true gaps from intentional exclusions and missing knowledge from missing handling. The Gap Resolution Policy is the move that prevents the audit from becoming a discovery exercise with no follow-through: every gap must be repaired, explicitly excluded, escalated, deferred with an owner and trigger, or accepted with recorded rationale. The Completeness Evidence Record captures what was checked, what was found, and how each gap was resolved, supporting accountability, future re-audit, and learning.
Several Optional Components strengthen the audit in higher-stakes or larger-scope settings: an appeal path for affected actors to challenge omissions, a sampling probe for spaces too large to enumerate exhaustively, an accountable gap owner so awareness translates to closure, an audit cadence that prevents one-time evidence from becoming stale as the system changes, and an exclusion register that documents deliberate omissions so they are not later rediscovered as accidents. These additions matter especially where the audit affects rights, eligibility, safety, money, or public trust — settings where silent omission and false assurance are the most consequential failure modes.
| Component | Description |
|---|---|
| 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. These often strengthen the draft when the situation calls for them.
| Component | Description |
|---|---|
| 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. |
Common Mechanisms¶
| Mechanism | Description |
|---|---|
| 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. |
Parameter / Tuning 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.
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.
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.
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.
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.
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.
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.
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.
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.