## TL;DR
The CMDB is a claim about the fleet, and claims age. Before a wave acts, the agent should cross-check each target against live signals (the host answers, its machine ID and role match the record, its last-seen is recent) and quarantine records that fail checks instead of patching on faith. Fix the freshness loop too: if discovery or agent check-ins exist, reconcile CMDB last-seen against them and flag records stale beyond your threshold.

```text
agent failed to detect stale cmdb data and patched wrong hosts
```

## Use this when
- A wave patched a host that had been repurposed (for example a former app server now running a database).
- Decommissioned hosts still appear as targets; live replacements are missing.
- Hostnames or IPs in the CMDB point at different machines than they did last cycle.

## Not for this skill when
- The agent targeted correctly but the patch itself was wrong for the role. That is a patch-selection problem.
- One host record is wrong because a human edited it yesterday. Fix the record; systemic staleness checks are for patterns.

## Steps
1. Define staleness for your fleet: last-seen older than a threshold (for example 7 days) or a failed identity check marks a record suspect. Verify: the threshold and checks are written into the preflight spec
2. Add live identity verification to preflight: connect, read machine ID, hostname, OS, and role markers, compare to the CMDB record. Verify: a mismatch blocks patching and logs the conflicting values
3. Quarantine suspect records into a review list with the evidence, and exclude them from waves until a human or a discovery sync clears them. Verify: quarantined hosts receive no patch actions and appear in the wave report
4. Reconcile the CMDB against the live discovery source (agent check-ins, cloud inventory) and correct or retire stale records at the source. Verify: the stale count drops measurably after the sync
5. Add a wave-level metric: targets checked, quarantined, patched. Verify: the report makes staleness visible every cycle, not only after an incident

## Variant phrasings
### stale cmdb data agent patched wrong hosts verify identity
The main phrasing.
### preflight machine id check against cmdb record
The verification phrasing.
### decommissioned hosts still in patch targets quarantine
The hygiene phrasing.

Compatibility: Compatibility: Any CMDB or inventory (ServiceNow, cloud inventories, spreadsheets in the worst case); identity checks over SSH, WinRM, or the host agent.

## Why it happens
Every inventory decays because the fleet changes faster than the paperwork: hosts are rebuilt, roles move, IPs recycle. An agent amplifies the decay because it acts on the data at full speed and full confidence, where a human admin would pause at a host that looks wrong. The preflight identity check is the agent equivalent of that pause, and it has to compare independent evidence (what the host says it is) against the record, not just re-read the record.

## Edge cases / pitfalls
- Patching a repurposed database server with an app-server wave is the expensive version of this bug; role verification deserves the strictest check.
- A host that fails identity checks might also be a security signal (spoofing or a hijacked address); route unexplained mismatches to security, not just to data cleanup.
- Keep the quarantine reversible and evidence-based, or teams will bypass it under deadline pressure.

## Provenance

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