## TL;DR
EXPIRED is a terminal failure for a copy job, not a success variant: the agent misread it because its status handling treated anything non-error-shaped as healthy. Enumerate the copy job statuses from the API documentation, map each to success, in-progress, or failure explicitly, and make unknown or expired states raise an alert. Re-audit past reports for copies marked healthy under EXPIRED and list the recovery points that never actually arrived offsite.

```text
agent misread AWS Backup copy job "EXPIRED" status as success and reported the offsite copy healthy
```

## Use this when
- The job or restore fails with this symptom: agent misread AWS Backup copy job EXPIRED status as success and reported the offsite copy healthy.
- You are working on an agent reporting AWS Backup cross-account copy health and the failure repeats on the same target or schedule.
- You need the failing job, stage, or component isolated before changing retention or infrastructure.

## Not for this skill when
- A copy that expired because its source point aged out before copying due to a long outage, where the fix also includes re-copying from a surviving point.
- The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. List recent copy jobs with their raw statuses and compare against what the agent's reports claimed for the same jobs. Verify: the misread set is enumerated
2. Build the explicit status map from the service's documented values, with EXPIRED and FAILED on the failure side. Verify: every status has a deliberate mapping
3. Update the reporting logic to use the map and to alert on failure-side statuses, including unknown future ones. Verify: reporting reflects real copy outcomes
4. Produce a corrected exposure list: points whose only offsite copy is an expired job, ordered by age. Verify: the true offsite gap is known and actionable

## Variant phrasings
### agent misread aws backup copy job expired as success
The verbatim phrasing.
### aws backup copy expired status healthy report wrong fix
The status-map phrasing.
### agent offsite copy health expired jobs exposure audit
The audit phrasing.

Compatibility: Agent interpretation of AWS Backup copy job statuses

## Why it happens
Status vocabularies include terminal states that are neither success nor an obvious error string, and a reader that pattern-matches on error-like words waves them through. EXPIRED means the copy window closed without a copy, so every report built on the misread overstated the organisation's offsite protection.

## Edge cases / pitfalls
- Statuses differ subtly between backup jobs and copy jobs; keep separate maps per job type.
- An unknown status should page a human once and be added to the map, never default to success.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_zIlaJMbKVe8-Z2jGAnZSjg