## TL;DR
Superseded updates deployed from a stale mirror waste windows and can leave hosts thinking they are patched while missing the current cumulative fix. Pin the agent to authoritative catalog sources, check catalog freshness before every wave - a sync timestamp and the expected latest cumulative KB for each target release - and refuse to build a wave from a catalog older than your threshold. Validate each selected update is not superseded at selection time, not just when the mirror first synced.

```text
agent downloaded patch catalog from stale mirror and deployed superseded updates
```

## Use this when
- Hosts installed an update that was already superseded by a newer cumulative release at install time.
- The agent mirror or local catalog copy syncs infrequently or its last successful sync is unknown.
- Compliance scans after the wave still show the current cumulative update as missing on freshly patched hosts.

## Not for this skill when
- An older update is required as a prerequisite for a specific stack and is installed intentionally in sequence. Document it as a prerequisite, not a catalog error.
- The mirror is current and the wrong update was chosen by selection logic. That is a selection bug, not staleness.

## Steps
1. Measure the staleness you actually have: record the mirror last successful sync time, compare its latest cumulative update for one target release against the vendor current release information, and list any updates the last wave deployed that were superseded on their install date. Those three facts turn a suspicion into a sized problem. Verify: you have the sync age, the catalog gap for a sample release, and the count of superseded updates actually deployed
2. Fix the mirror health before the agent logic: repair or replace the sync mechanism, confirm sync errors alert to a human instead of failing silently, and run a full synchronization so the catalog is current. Check the content behind the metadata too, because a fresh catalog pointing at old content files recreates the problem at download time. Verify: the mirror syncs successfully on schedule, its failures alert, and metadata and content are both current for a sample update
3. Add a freshness gate to the agent pre-flight: before building a wave, the agent reads the catalog sync timestamp and compares the newest cumulative KB per target release with an expected value it fetches or is configured with for that month. If the catalog is older than your threshold or the expected KB is absent, the wave does not build and the agent reports stale catalog as the reason. Verify: a test with an artificially aged catalog stops at pre-flight with a stale catalog report and builds no wave
4. Add supersedence validation at selection time: when the agent selects an update for a host, it checks the catalog supersedence information and, if the update is superseded and not marked as a required prerequisite, replaces it with the superseding update or flags the host for review. Log every replacement so the wave plan shows what changed and why. Verify: a test selection containing a superseded update is corrected to the superseding update with the change logged
5. Close the loop with post-wave verification: after the wave, the agent compliance check confirms hosts no longer report the current cumulative update as missing. A host patched from a healthy catalog should not immediately appear unpatched for the same month release, and any that do become a named exception list. Verify: post-wave compliance shows freshly patched hosts clean for the current release, with exceptions named rather than discovered later

## Why it happens
Patch catalogs are snapshots of a moving target: every month, new cumulative updates supersede the old ones, and a mirror that stops syncing keeps offering the old snapshot as if it were current. An agent has no natural sense of time - it trusts its catalog completely - so it will cheerfully deploy last month cumulative update, report success, and leave the fleet one release behind while believing it is compliant. Freshness is therefore a property the workflow must check explicitly, with a timestamp, an expected current release, and a supersedence check at the moment of selection, because those are the three points where staleness can enter.

## Variants and edge cases
### Air-gapped fleet with a manually updated mirror
Manual media rotation is the freshness risk. Put the catalog age on the import checklist, stamp each import, and let the agent gate on that stamp so an old import is caught before a wave.

### Mirror is fresh but one product line is stale
Per-product sync failures can hide inside an overall successful sync. The freshness gate should sample each target product line the wave will use, not just the global timestamp.

### Superseded update deployed because the new one is blocked
Sometimes the superseding update is held for a known issue. Record that as an intentional exception with an expiry, so the agent reports deployed superseded by decision, not by staleness.

Compatibility: Applies to patch agents using WSUS, offline catalogs, vendor update APIs, or mirrored repositories for Windows and Linux fleets.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Kva9in0UbrFW2lstaQzUQA