Validate the newest snapshot, not the newest valid one

An older result can hide a new failure#

A source can return several snapshots with the same identity. If the dashboard validates them all and chooses the newest one that passes, its page can look healthy while the producer's latest update is broken.

The model chooses first. It sorts by the time the data describes, falling back to generation time, and sends only the newest record for each identity to validation. A failure in that record remains a visible problem instead of triggering a quiet search for older data.

Separate an old payload from a broken one#

Validation checks the supported version, expected fields, required capabilities and canonical payload digest. An unknown version is incompatible. Malformed content, a changed digest, an invalid consumer time or a snapshot apparently generated in the future needs review.

An otherwise valid payload that has expired is stale and can remain labelled on screen. An invalid snapshot has no accepted payload. Each source retains its own status, reason and refresh error, so a failure in one service doesn't erase a usable result from the other.

Test the selection order, not just the validator#

The model test supplies an older valid snapshot beside a newer malformed one. It expects review status and no accepted payload for that identity. Other definitions cover missing sources, expired data, changed digests and future timestamps. These checks were inspected, not rerun against live data.

The browser receives the combined response rather than opening either database. A new snapshot version can require a consumer update, but private table changes don't have to become frontend changes.