Data freshness for APIs, dashboards and AI

Freshness is not one timestamp

A business workflow can read a newly downloaded file whose contents are old. Distinguish the content's source or coverage timestamp, the collector's receipt timestamp and the downstream delivery or decision cutoff. Choose the measurement boundary for the customer task: inventory through a time, all expected documents in an index, a published source release or a particular API partition.

OpenTelemetry's log model similarly distinguishes an event timestamp from when the collector observed it. This checker uses its own documented metadata format; it is not an OpenTelemetry importer or conformance test. Source: OpenTelemetry log timestamps.

Choose limits for the job, not a universal score

Set age, collection-delay and minimum-count criteria separately. A nullable disabled criterion is not a pass. Include missing measurements and legitimate empty deliveries in your contract. For a known empty partition, a minimum count of zero may be appropriate; it is not the same as an unknown count.

Freeze the cutoff before comparing snapshots

Use the same explicit cutoff for the question you are asking. A snapshot received on Monday cannot demonstrate what your workflow knew on Friday, even when it describes Friday's content. Keep snapshots and revisions rather than overwriting the earlier record with today's source state.

This checker accepts one intended snapshot per feed ID and excludes post-cutoff measurements from the comparison. It does not select revisions from an archive or attest when a record first became public. Keep those acquisition and publication records separately. Standard timestamp formats make timezone treatment explicit; this tool intentionally accepts a narrower UTC-only subset. Source: W3C explicit-timezone timestamp model.

Separate four operational questions

1. Did the collector receive anything? Preserve receipt time and run outcome, including failed or empty runs.
2. Does the batch cover the intended period and entities? Retain coverage boundaries, partition IDs, expected revisions and reconciled counts.
3. Did the consumer receive the correct version? Track delivery receipts and idempotent effects. A source refresh is not a completed downstream update.
4. Does the workflow produce a useful result? Test extraction, retrieval and downstream business actions separately; current data can still produce the wrong answer.

Make the evidence actionable without inventing certainty

Retain the reference contract, selected observations, cutoff and full source-hashed report beside the collector run. A failure means a supplied criterion was exceeded or timestamps conflicted. Unknown means you need the missing measurement, not that a pipeline is necessarily broken. The operator decides response and acceptance criteria.

A useful implementation can route different failures to the right owner, isolate affected partitions, retain a known previous release with its age clearly labeled and reconcile after retry. Do not silently fill unknown timestamps, infer complete coverage from one newest row or treat a successful HTTP response as data correctness. Monitor sustained failures and recovery without flooding operators with unchanged alerts.

Snapshot analysis does not establish a contractual SLA, data quality, source rights or actual service availability. For a recurring service, agree on schedules, source constraints, response responsibilities, audit retention and operating costs separately.

From a useful check to a working data system

No purchase, account provisioning, messages or live data changes occur here. This checker is not included as an MCP tool in Developer Assurance Kit 1.1.0 or as a Data Workbench feature. Those are separate products.