DATIMORE · WEB-054 · SYNTHETIC EXAMPLE
Figures you can trace back to the records
A rule catalogue, test records and review log. Save or print this page to plan checks for your report.
All figures, identifiers, source documents and decisions are invented. This is a static illustration, not a client result or a tool that validates your data. It changes no real records.
1. Keep the original inputs
Review units still to dispatch for September orders, as at 30 September 2026. Assume these are all five orders, each appearing once, for one product in the same unit, with no returns or cancellations. Check those assumptions against the source before applying this example.
On a narrow screen, scroll tables sideways. Keyboard users can focus each table area and use arrow keys.
| Order ID | Customer ID | Order date | Ordered units | Dispatched units |
|---|---|---|---|---|
| O-101 | C-101 | 2026-09-01 | 10 | 4 |
| O-102 | Missing | 2026-09-02 | 8 | 3 |
| O-103 | C-103 | 2026-02-30 | 5 | 2 |
| O-104 | C-104 | 2026-09-04 | 6 | 7 |
| O-105 | C-105 | 2026-09-05 | 100 | 20 |
2. Agree the rules and the response
Here, invalid records and records awaiting review stay out of the final report. They are retained, not deleted or corrected by guesswork. A blocking error requires correction; a warning can be accepted unchanged after confirmation is recorded. If a record has both, resolve both before accepting it.
| Rule | Check | Response |
|---|---|---|
| R1 | Order ID, customer ID, date and both quantities must be present. Empty text, text containing only spaces and missing values fail. | Block until corrected |
| R2 | A real calendar date in year-month-day form, within 1–30 September 2026. Do not silently roll an impossible date into another date. | Block until corrected |
| R3 | Both quantities are numbers with no fractions; ordered is above zero, dispatched is zero or above. Check missing values first; never replace them with zero. | Block until corrected |
| R4 | Dispatched must not exceed ordered. Compare only after both quantities are present and valid. | Block until corrected |
| R5 | Ordered above 50 units? Ask the order owner to confirm; do not reduce it merely because it is large. This threshold is chosen only for this example. | Warning requiring a recorded decision |
3. Record review and rerun the checks
Only the first order record passes initially; the other four records remain on hold. Its subtotal of 6 units is not the report total. Hold the whole report until those four records are resolved. The document references below are invented evidence within the scenario, not customer files.
| Order | Initial result | Decision and reason |
|---|---|---|
| O-101 | Passes all rules; no warning. | 10 minus 4 = 6 units; accepted. |
| O-102 | R1: customer ID missing. | Order owner checks invented order document S-102 and confirms C-102. Add ID in a corrected copy; rerun passes. |
| O-103 | R2: 30 February is not a real date. | Order owner checks S-103 and confirms 3 September 2026. Correct the date; rerun passes. |
| O-104 | R4: 7 dispatched against 6 ordered. | Dispatch owner checks D-104 and confirms 4 dispatched. Correct the quantity; rerun passes. |
| O-105 | R5: order of 100 needs review. | Order owner checks S-105 and confirms 100 ordered. Accept the warning without changing the quantity; record the reason. |
Keep the original and a separate corrected copy. In real work, also record the reviewer, decision date, version and a source reference that authorized reviewers can access. If a value cannot be confirmed, keep the record and report on hold; do not bypass a rule to meet the delivery time.
4. Check the total against the records
| Order ID | Customer ID | Order date | Ordered units | Dispatched units | Still to dispatch |
|---|---|---|---|---|---|
| O-101 | C-101 | 2026-09-01 | 10 | 4 | 6 |
| O-102 | C-102 | 2026-09-02 | 8 | 3 | 5 |
| O-103 | C-103 | 2026-09-03 | 5 | 2 | 3 |
| O-104 | C-104 | 2026-09-04 | 6 | 4 | 2 |
| O-105 | C-105 | 2026-09-05 | 100 | 20 | 80 |
Still to dispatch = ordered minus dispatched. Total: 129 − 33 = 96 units, also 6 + 5 + 3 + 2 + 80 = 96. All five orders remain; three records were corrected and one warning accepted after confirmation. This is the example output, not a measured client improvement.
Passing these rules cannot prove every fact is correct. A date can exist on the calendar but still be wrong for the order. Confirm that all expected records arrived, each quantity belongs to the right order and the report owner has reviewed questions outside these rules.
5. Test before scheduling checks
| Case | Input | Expected result |
|---|---|---|
| Required value missing | Leave out each required field in turn. Also test the system’s missing-value marker (null), empty text and text containing only spaces. | R1 blocks; missing never becomes zero. |
| Impossible/out-of-period date | 2026-02-30, then 2026-08-31. | R2 blocks both. |
| Invalid quantity | Ordered 0 or 2.5; dispatched −1; then text instead of a number. | R3 blocks each case. |
| Valid boundaries | Ordered 1, dispatched 0; then both 1. | Pass; remaining is 1, then 0. |
| Inconsistent quantities | Ordered 6, dispatched 7. | R4 blocks. |
| Warning boundary | Ordered 50, then 51; dispatched 0. | 50 passes; 51 requires R5 review. |
| A possible date that is wrong for the order | Replace 2026-09-01 with 2026-09-02. | Passes this check; source review is needed to establish the error. |
| Number stored as text | Store “10” as text characters instead of a number that can be used in calculations. They may look identical on screen. | R3 blocks; this example does not silently convert text to numbers. |
| Block and warning together | Ordered 100, dispatched 101. Then correct dispatched to 20 without confirming the large order. | R4 blocks and R5 needs review. After correction, the record stays held until R5 is confirmed. |
Change one value at a time while other fields remain valid, except when deliberately testing combined failures. Repeat tests when rules or the way records reach you change.
6. A template for your report
Record the report, its period, its source and how you will confirm that all expected records are present.
For each field, write the check, its limits and what happens if the value is missing. State whether a failure blocks the record or needs review. Name who corrects it and what evidence is needed to accept a warning.
Add a passing and a failing test, the review time and the person who covers an absent reviewer.
For each record needing review, keep its ID, failed rule, original value and corrected value. Record the decision, reason, evidence, reviewer, date, version and result when the checks run again.
Background: IBM’s data validation overview, checked 3 October 2026. The rules, thresholds and calculations in this file are specific to the synthetic example, not universal business requirements.
Plan one rule here
| Field | Your notes |
|---|---|
| Report and period | |
| Source and how completeness is checked | |
| Field, rule and missing-value treatment | |
| Block or warning? Who reviews it? | |
| One passing and one failing test | |
| Evidence needed to accept correction or warning |