Reports & decisions / GUIDE + WORKSHEET
Spot stale data before sending a report
Distinguish page refresh from source freshness and design reporting checks for missing batches, delayed records, and partial data.
THE STARTING POINT
Check the age and completeness of the source data, not just the time the dashboard rendered. Record the last successful ingestion, the latest relevant business event, and whether expected batches arrived. Show a clear stale or partial state when the report cannot support its intended decision.
Separate three different clocks
A page may load now using a table refreshed yesterday containing source records last updated a week ago. Record the presentation time, ingestion time, and relevant source event time separately. A newest-record timestamp alone can also mislead if one fresh record hides a missing batch. Pair age checks with expected coverage where the workflow allows it.
Define acceptable delay for the decision
A weekly planning report and a same-day dispatch board have different freshness needs. Specify the maximum useful delay in terms of the decision, then account for scheduled quiet periods. Decide how to handle a source that is intentionally unavailable. Avoid labeling all data live when some inputs are batch-based or manually maintained.
Make incomplete data visible before distribution
Choose whether a failed check should stop sending the report, show a partial report, or alert an owner. Include the affected source and the consequence for interpretation. Keep the last known good output available when that is useful, clearly dated. Verify the recovery by checking that missing records arrived, not just that the refresh job restarted.
WORKED EXAMPLE / ILLUSTRATIVE
A fictional Monday report
The dashboard renders at 09:00, but the weekend import did not complete. Showing 'updated at 09:00' alone would conceal the gap. The report instead identifies the missing source period and avoids presenting a complete-week total.
| Clock/check | Observed state | Meaning |
|---|---|---|
| Page rendered | Monday 09:00 | Only the view is current |
| Last complete import | Friday 18:00 | Weekend coverage unverified |
| Publication state | Partial: weekend import missing | Owner investigates before distribution |
MAKE IT USEFUL
Freshness and completeness rules
Write rules per source, then define the combined report behavior.
Your notes stay in this page and are not sent to Smithers. Download or copy them before leaving; refreshing clears them.
Before you put it to work
- Separate render time from data time.
- Check coverage as well as newest record.
- Label partial reports clearly.
- Verify backfilled records after recovery.
A recent timestamp is not evidence that all expected data arrived. Freshness and completeness are related but different checks.
IF THIS LOOKS FAMILIAR
Your tools. Your particular mess.
The worksheet is yours to use. If the difficult part is making it work with the systems you already have, that's the kind of thing we help with.