# Reconcile duplicate rows in a delivery summary

Illustrative planning brief; no automatic product import.

Synthetic case: The worksheet lists A at acceptance 09:00 twice, B at 10:00 once and A at a later acceptance 15:00 once. Removing every repeated task ID would also lose a different event.

## Decision

Under the explicit task-ID-plus-event-ID rule, retain three accepted events and record one duplicate row.

## Owned work

- Name the counted identity
  - Owner role: Report owner
  - Acceptance evidence: The policy uses event ID with task ID, not displayed title.
- Inspect repeated rows
  - Owner role: Reviewer
  - Acceptance evidence: The two A/e1 rows are duplicates; A/e3 remains a different event.
- Reconcile the ledger
  - Owner role: Coordinator
  - Acceptance evidence: Four source rows become three distinct events plus one retained duplicate note.

## Workflow

1. State whether the unit is task or accepted event.
2. Compare stable identity and event evidence before removing rows.
3. Keep exclusion reasons and reconcile source rows to the final count.

## Judgment

This event-count example is not a count of unique tasks. Do not promise automatic deduplication or assume repeated IDs always mean bad data.


## Filled review note

Reconciled note: three distinct acceptance events from four rows; one duplicate A/e1 excluded. Unique-task count is a separately named view.


## Workflow questions

### Why does A remain twice?

It has two distinct accepted event IDs under this stated event-count policy. A unique-task report would answer a different question.

### Why preserve a duplicate note?

It explains how four source rows became three counted events and makes the exclusion inspectable.

## 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

Task ID | Acceptance event ID | UTC time
--- | --- | ---
A | e1 | 09:00
A | e1 | 09:00
B | e2 | 10:00
A | e3 | 15:00

### Version changes

Boundary | Draft | Revised
--- | --- | ---
Counted unit | Raw row | Distinct accepted event
Repeat handling | Repeated rows counted without an identity check | Only duplicate event identity removed

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

Draft: four delivered tasks from four source rows.

### Revised example

Reconciled note: three distinct acceptance events from four rows; one duplicate A/e1 excluded. Unique-task count is a separately named view.

### Decision situations

- Stable event identities are present: Reconcile duplicate event rows and keep other events.
- Only task IDs are available: Use a task-level measure if justified; do not infer distinct acceptance events.
- Row identity is unclear: Hold the event count and recover identity evidence.

### Evidence dependencies

- Four source rows → Event identity check: same event?
- Event identity check → Three distinct events: retain exclusions

### 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.