# Reopened work after a report closes

Illustrative planning brief; no automatic product import.

Synthetic case: A was accepted on day 10 inside a day 1–14 report. It reopened on day 15. The reviewer wants to erase its original acceptance from the issued report.

## Decision

Retain the issued period’s accepted event under the stated event policy, add a later reopening note and create a restated version only under an explicit correction policy.

## Owned work

- Freeze the issued snapshot
  - Owner role: Report owner
  - Acceptance evidence: The day 1–14 note and its acceptance policy are retained.
- Review the later event
  - Owner role: Task owner
  - Acceptance evidence: The day 15 reopening is a separate dated event with its own evidence.
- Choose correction handling
  - Owner role: Delivery lead
  - Acceptance evidence: A restatement, if required, cites the original report and explains the rule.

## Workflow

1. Keep the original event evidence and period boundary.
2. Distinguish later events from corrections to incorrect original evidence.
3. Publish an explicit subsequent note or versioned restatement; do not silently replace the issued report.

## Judgment

This policy does not decide product task state or legal reporting obligations. Reopening alone does not prove the original event was recorded incorrectly.


## Filled review note

Subsequent note: A reopened on day 15, outside the issued period. Original event retained; any correction receives a linked report version.


## Workflow questions

### Does reopening automatically erase the earlier acceptance?

No under this event-based example. Preserve what happened and its date; use an explicit restatement policy for corrections.

### What makes this different from defect triage?

Triage handles the new failure; this kit handles the already-issued reporting period and its version history.

## Product connection

Bring this manual reporting policy and its owned checks into your TeamBoostAI work discussion. Native report/export fields and historical reconstruction depend on your account and implementation; this worksheet does not import or change product records.

Confirm account availability before adopting this manual outline.

## Decision workshop

Synthetic examples only. Manual worksheet; no automatic import or product writes.

### Synthetic reporting records

Item | Event date | Observed event | Period treatment
--- | --- | --- | ---
A | Day 10 | Accepted | Inside issued period
A | Day 15 | Reopened | After cutoff

### Version changes

Boundary | Draft | Revised
--- | --- | ---
Event boundary | Day 1–14 remains the issued window | Day 15 is a later event
Version handling | Original snapshot retained | Restatement needs a named rule and reason

### Draft or earlier version (review its limits)

Issued note: A accepted within day 1–14; one accepted event.

### Revised example

Subsequent note: A reopened on day 15, outside the issued period. Original event retained; any correction receives a linked report version.

### Decision situations

- The acceptance was correct; reopening occurred later: Retain the issued event and add the dated later-event note.
- The original acceptance evidence was incorrect: Hold the published figure and prepare a versioned correction with evidence.
- I cannot distinguish later event from original error: Locate the original acceptance and event dates before choosing a reporting route.

### Complete message drafts (review before use)

#### Later-event note

A was accepted during the issued period and reopened afterward. The original period is retained under its event rule; the new failure has a separate owner and next check.

#### Correction request

The issued acceptance may be incorrect. Please review the original evidence before approving a linked restatement.

### Method references

- The Kanban Guide, May 2025: https://kanbanguides.org/the-kanban-guide/2025.5/ — Clock and work-item definitions; examples and local rules are our own.