# Reconcile accepted work with deployed work

Illustrative planning brief; no automatic product import.

Synthetic case: Five outcomes are accepted, three of those are deployed, and a fourth deployed ID belongs to a different acceptance cohort.

## Decision

Report three-of-five deployed within the accepted cohort and disclose the out-of-cohort deployed record separately.

## Owned work

- Freeze the acceptance cohort
  - Owner role: Acceptance owner
  - Acceptance evidence: The five accepted IDs and window are written.
- Match deployment evidence
  - Owner role: Release coordinator
  - Acceptance evidence: A,B,C have deployment evidence; X is outside the selected cohort.
- Review availability wording
  - Owner role: Report owner
  - Acceptance evidence: 3/5 refers only to this accepted cohort; no universal availability is claimed.

## Workflow

1. Separate acceptance and deployment event meanings.
2. Match stable IDs before comparing the two sets.
3. Keep out-of-cohort records visible in a separate reconciliation line.

## Judgment

Deployment does not prove user entitlement, adoption or successful operation. This worksheet does not inspect an environment.


## Filled review note

Matched cohort note: three of the five accepted outcomes have deployment evidence; X is a separate out-of-cohort record.


## Workflow questions

### Why not say four of five deployed?

One deployed ID is outside the accepted cohort. Join the sets before forming the fraction.

### Does accepted mean available to customers?

No. Deployment and actual availability have their own evidence boundaries.

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

View | Stable IDs | Treatment
--- | --- | ---
Accepted cohort | A,B,C,D,E | 5 outcomes
Deployed from that cohort | A,B,C | 3 outcomes
Other deployed record | X | Outside selected cohort

### Version changes

Boundary | Draft | Revised
--- | --- | ---
Identity matching | Counts compared without joining IDs | Accepted IDs matched to their deployment evidence
Availability | Deployment treated as customer access | Entitlement and observed operation remain unverified

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

Draft: four deployed records compared with five accepted records.

### Revised example

Matched cohort note: three of the five accepted outcomes have deployment evidence; X is a separate out-of-cohort record.

### Decision situations

- Both event sets have stable IDs and a common cohort: Report the matched cohort and separate other records.
- Cohort boundaries differ: Hold the fraction until the sets are reconciled.
- Deployment evidence is missing: Describe acceptance without claiming deployment.

### Evidence dependencies

- Accepted IDs → Matched cohort: selected IDs
- Deployment evidence → Matched cohort: proved events

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