Twenty rows, nineteen periods: a quality escalation

Declare the expected population before counting arrivals

Open the report and select the quality preset. This invented monthly record declares twenty expected period dates from January 31, 2023 through August 31, 2024. Those dates define the comparison population; they are not publication timestamps or evidence that a real scheduler ran. The supplied rows intentionally remove June 30, 2023 and append a second March 31 record. The final row count therefore still equals twenty.

A count-only check would miss both defects. The correct comparison retains expected count, observed count and unique count separately: 20, 20 and 19. Inspect the actual keys as well as the totals. A duplicate can inflate a feature's influence and compound a return twice; a missing period can remove a loss or gain. Neither defect can be resolved by assuming that the two count effects cancel economically.

Keep nulls and clocks as separate observations

The first feature is null and the second model return is null. There are no benchmark-return nulls. Each reported null share uses supplied rows as its denominator, including the duplicated row, so one divided by twenty is five percent. That statistic describes the received batch, not the proportion of all expected cells after reconciliation. Zero would mean an observed numerical value and must not be substituted for either null.

The fixture declares last_updated as August 29, 2024 at 12:00 UTC and as_of as September 2 at 12:00 UTC. Their difference is 96 hours, above the example's 48-hour review level. This arithmetic concerns supplied delivery metadata. It says nothing about the age of March's observation, whether a server actually executed, or whether the apparent update time was independently verified. Those questions require different evidence.

Withhold calculations whose population is ambiguous

The duplicate prevents an unambiguous current feature sample, so the drift block is withheld even though nineteen nonmissing features remain. The performance block is withheld for three separate reasons: a duplicated period, a missing expected period and an incomplete model/benchmark return pair. The report retains each reason. It does not present a shorter observed-window return under a complete-window label or silently choose one March row.

Missing features and missing returns have different consequences. In a separate valid input with unique expected dates and complete return pairs, a feature null alone would permit performance and an observed-subset drift diagnostic if enough features remain. Here the duplicate independently blocks drift. This distinction matters when investigating the smallest justified correction: changing a return cannot repair identity ambiguity, and filling a feature cannot establish a missing period's outcome.

Preserve the failed candidate and request evidence

The resulting status is escalate. Export the full report with its input, missing and duplicate identities, null counts, timestamp arithmetic and withholding reasons. In the fictional workflow, a data steward would obtain the authoritative source record for the duplicated date and the missing period, then create a corrected candidate with a documented reason. Deleting one row or inventing an unavailable return merely to obtain a clean status would erase the uncertainty.

Keep the original failed candidate beside any corrected version. A previous accepted report can remain available with its original timestamp, but should not be relabelled as newly refreshed. Re-run the same contract and compare changed rows and findings before a hypothetical acceptance decision. W3C's quality vocabulary offers context for recording quality measurements and provenance; it does not prescribe this site's counts, policy levels or fictional escalation decision.

Keep in the decision record

• Twenty received rows can still omit an expected period.
• Null values, duplicate identities and delivery age answer different questions.
• Preserve withholding reasons and failed inputs before proposing a correction.

Source notes

1. W3C: Data Quality Vocabulary, Working Group Note
2. Federal Reserve: revised model risk guidance and its scope

Sources inform the stated methods and governance context. All example monitoring observations are synthetic. No regulatory approval or production monitoring certification is implied.

Continue the analysis