# Retrospective action: confirm receipt fields early

Fictional example: Northstar customer portal. The observations and follow-up below are illustrative.

## Work reviewed
- Work or period: the first receipt-download change.
- Intended outcome: customers can retrieve a correct receipt for their own completed order.
- Actual result and evidence: the example team reviewed the PDF and access/failure checks. In real work, link the code and saved verification results.
- Participants: the contributor, reviewer, product owner and Support representative.

## Observation
- What happened: the payment-date timezone needed clarification after implementation had started.
- Effect: the contributor paused the PDF work while the product owner and reviewer agreed the field meaning.
- Possible explanation: a missing field decision may have caused the pause. One example does not prove every delay has this cause.
- What to preserve: the reviewer checked the actual PDF against the agreed fields.

## One improvement to try
- Change: add a short field-and-format review to the next document-download brief before implementation.
- Why this action: it gives the contributor a chance to resolve ambiguous output fields before building.
- Agreed owner: the product owner coordinates the review with the contributor and reviewer.
- Work link: create or reuse an action item and link the next brief.
- Success signal: note whether output-field questions remain after work starts, and whether the early review was useful. No numeric improvement is claimed.
- Review point: inspect the next relevant download change after its review.

## Follow-up
- What we tried: not yet observed in this fictional example.
- What changed: record the actual evidence after trying the review.
- Decision: pending that evidence.
- Next action: adjust the practice only after the team checks its effect.