Data Completeness Check¶
Test / assessment — instantiates Completeness Audit
Checks whether records, fields, observations, time periods, categories, or sources needed for valid use are present or explicitly marked missing.
A Data Completeness Check tests a dataset against a required-data specification — the records, fields, observations, time periods, categories, and sources that must be present for the data to be validly used — and reports, for each required slot, whether it is present, silently absent, or explicitly declared missing. Its defining idea, and what separates it from its twin the Test Coverage Audit, is that it audits the presence of data, not the exercise of behavior: it asks "is the information this analysis depends on actually here?" rather than "does a test drive this code path?" And it treats a silent null and a documented "not applicable / not collected" as fundamentally different states — the first is a gap, the second is a recorded decision.
Example¶
A national statistics office is assembling quarterly labour-force microdata. The required footprint is explicit: every sampled household, for each of thirteen core fields, across all four reference weeks, from all eight regional collection centres. The completeness check runs across the assembled file and finds three different absences. Region 6 submitted no records at all for week 3 — a missing source-and-period, the classic unit nonresponse. The "hours worked" field is null for about 4% of employed respondents — item nonresponse scattered through otherwise-present records. And the "informal sector" category has zero records in two regions where it should be common — a suspicious silent gap that presence-testing surfaces for follow-up. Crucially, respondents recorded as retired have "hours worked" legitimately blank; those are registered as declared N/A, so they are not counted as gaps. Separating declared-missing from silently-missing is the entire point of the exercise, and it draws on the standard vocabulary of missing-data mechanisms.[n1]
How it works¶
The check enumerates the required slots — records by fields by periods by sources — and tests each for a present value, then sorts every absence into two piles: those pre-registered as legitimately absent, and true silent gaps. Unlike its sampling siblings, it runs exhaustively over the dataset rather than probing a sample, because the population of required slots is finite and enumerable. Its distinctive discipline is the present-vs-declared-missing sort: a null that is expected and documented is closed; a null that is neither is a gap that blocks valid use. The output is a per-slot gap ledger, not a verdict on whether the present values are correct.
Tuning parameters¶
- Required-footprint strictness — which fields, periods, and sources are mandatory versus optional. Over-strict floods the ledger with false gaps; over-loose lets real ones hide.
- Presence definition — non-null, versus non-null-and-in-range, versus plausibility-checked. Stronger definitions catch garbage that is present but invalid.
- Declared-missing discipline — how aggressively legitimate N/As are pre-registered so they never read as gaps, and how their reasons are kept inspectable.
- Granularity — cell-level versus field-level versus source-level completeness accounting.
- Fail threshold — what per-field completeness rate blocks downstream use versus flags a caveat.
When it helps, and when it misleads¶
Its strength is turning "the data looks fine" into a per-slot presence ledger, where the declared-missing register keeps legitimate blanks from being chased and silent gaps from hiding behind them. Its failure mode is that present is not the same as correct: a field can be fully populated with default or garbage values and still pass, so a "100% complete" result can give false assurance of a quality it never inspected — especially when the 100% counts placeholder "0" or "unknown" entries as present.[n1] The guarding discipline is to pair presence with plausibility, and to derive the required footprint from what the downstream use actually needs rather than from whatever happened to be collected.
How it implements the components¶
intended_coverage_space— the required-data specification (which records, fields, periods, and sources must appear for valid use) is the coverage universe this check audits against.gap_analysis— for each required slot it separates present from absent, and among absences separates true silent gaps from weak or placeholder presence.exclusion_register— legitimately-absent values (N/A, not-collected-by-design) are recorded as declared exclusions with their reasons, so they are not mistaken for gaps and the exclusions stay inspectable.
It does not check whether an automated test suite exercises behavior, adversarially probe whether coverage is real, or emit a coverage-and-mutation metric as standing evidence — coverage_map, sampling_probe, and completeness_evidence_record are the work of its twin Test Coverage Audit, which audits executed behavior rather than present data.
Related¶
- Instantiates: Completeness Audit — it supplies the presence-side completeness ledger over a dataset.
- Sibling mechanisms: Coverage Checklist Walkthrough · Policy Gap Analysis · Risk Register Review · Scenario Tabletop Review · Stakeholder Inclusion Review · Test Coverage Audit · Requirements Traceability Matrix
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Data Completeness Check operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it checks whether records, fields, observations, time periods, categories, or sources needed for valid use are present or explicitly marked missing.
Independent corroboration: The frozen evidence defines Data Completeness Check as 'Checks whether records, fields, observations, time periods, categories, or sources needed for valid use are present or explicitly marked missing', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Data Science & Analytics
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Data-quality management cohered completeness checks that compare datasets with required record, field, period, category, and source specifications while distinguishing silent absence from declared missingness.
Related originating lineages:
- Statistics & Experimental Design — Missing-data theory supplied distinctions among unit and item nonresponse and among mechanisms of missingness.
Review resolution: Data-quality practice established explicit completeness rules and exception reporting; statistical missing-data analysis is a genuine secondary lineage.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Statistical practice distinguishes unit nonresponse (a whole record or source absent) from item nonresponse (specific fields absent within a present record), and classifies the mechanism of missingness (missing completely at random, at random, or not at random, after Donald Rubin). The distinction matters because a declared, understood absence can be handled honestly, while a silent one biases any downstream use that assumes the slot was filled. ↩a ↩b