## TL;DR
Treat order forms as superseding, not additive. Collect the renewal date from each order form with its execution date, mark the latest-executed form's date as current, and mark the older ones superseded. The agent concatenated three renewal dates because nothing told it that a newer order form replaces the older one's terms.

```text
renewal date drifted across three order forms  -  the agent reported all three as current
```

## Steps
1. Extract the renewal date from each order form separately, paired with that form's execution date.
   Expected: three (order form, execution date, renewal date) triples
2. Mark the latest-executed order form's renewal date as current and the rest as superseded.
   Expected: exactly one renewal date carries the "current" label
3. If the latest order form does not mention renewal, say so explicitly; do not silently carry an old date forward.
   Expected: "no renewal term in the current order form" instead of a stale date
4. Render a renewal history table: order form, execution date, renewal date, status.
   Expected: the operator sees the drift across forms at a glance
5. Add a regression case with three order forms and assert exactly one current renewal date.
   Expected: multi-date output cannot regress without failing the test

## Use this when
- Multiple order forms each state a renewal date and the agent reports all of them.
- Renewal or term dates drift across successive order forms.
- You are validating date extraction on deals with several order forms.
- The "current" renewal date in a report does not match the latest paperwork.

## Not for this skill when
- The order forms cover different service lines with genuinely separate renewals; then multiple current dates are correct.
- There is only one order form in the bundle.
- The renewal date lives in the MSA, not the order forms.
- The dates differ because of amendments, not because of successive order forms.

## Variant phrasings
### agent reported multiple renewal dates as current
### renewal date superseded across order forms
### order form renewal dates conflict in extraction output
### which order form's renewal date is current

## Why it happens
Extractors collect dates per document and merge at the end, and the merger has no model of supersession: three order forms look like three sources confirming a date rather than three versions of it. Order forms feel additive because each one adds services, but their term mechanics replace. The pipeline's mental model (more documents, more evidence) is backwards for dates that supersede.
## Edge cases
- Order forms cover different products with independent renewals. Group by service line first, then apply latest-wins within each group.
- The latest order form is undated. Use signature date, then counterparty countersignature date, then flag uncertainty; never silently pick.
- An amendment (not an order form) sets the latest renewal date. The amendment layer outranks order forms; check it before declaring current.
- Auto-renewal already triggered between forms. Note the triggered renewal in the history table so the timeline stays truthful.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_RGt_F-iGjndmZctI7xHcUg