A clean total concealed
two mismatched records.
The aggregate reconciliation says $600 on both sides. A more granular comparison shows offsetting differences. This is a deliberately fabricated example of the same class of mismatch exercised in RUNBIRD ModelIntel's prototype validation.
Decision
HOLD FOR VERIFICATION
Passing the total reconciliation is insufficient to certify row-level accuracy. Two records differ, even though their changes offset to zero.
What to do
- Confirm the source and comparison exports represent the same period, grain, and refresh snapshot.
- Confirm the join key and relevant business rules.
- Inspect rows B and C in the authorized source system.
- Request a business owner's decision on whether the differences are expected.
What we can and cannot conclude
Observed: The provided synthetic files have a zero total delta and two differing row values.
Not established: Which side is correct, whether a business error exists, or whether a production report would be impacted.
Reusable pattern: Compare at a controlled grain, record exceptions, then attach provenance and unresolved decisions.
Record-level evidence
| Key | Source | Model export | Delta |
|---|---|---|---|
| ORDER-A | $100 | $100 | $0 |
| ORDER-B | $200 | $220 | +$20 |
| ORDER-C | $300 | $280 | −$20 |
| Total | $600 | $600 | $0 |
Test definition
key = order_id
metric = amount
tolerance = $0.01
comparison = model - source
required grain = 1 row / order
Disposition
Two row-value mismatches detected. Aggregate equality alone does not support a validation pass.
Sample values are invented. Matching date, RLS/filter, and refresh conditions are assumed for illustration only—not verified against a live model.
The synthetic comparator test is grounded in RUNBIRD's recorded ModelIntel v0.5.9 validation, which reported 2 mismatched rows and zero net delta in a three-row fabricated fixture. The presentation here is an explanation of that test, not a live deployment.
Discuss an investigation →