# Accepted-outcome event map

Use this with the workflow owner, operator, and measurement owner before designing a success dashboard. Completing it provides a measurement design, not data access, action approval, a production release, or a measured business benefit.

## Start with these questions

1. Which shipment belongs in this report, and how will you count it only once?
2. What record shows that the software finished its bounded job?
3. Who can accept or reject that work, and where is their decision saved?
4. Which later action or delivery result needs a separate record?

## Completed hypothetical shipment decision

- Bounded job: prepare shipment review work for coordinators. Software can stage a non-binding case; it cannot intervene in a shipment.
- Accepted unit: a correctly routed case with current evidence that the coordinator accepts as usable, with their decision recorded. A valid decision that no intervention is needed can qualify. A completed review rejecting incorrect prepared work is outside this acceptance count.
- Rejection rule: incorrect route, stale or missing required evidence, or unusable prepared work. Return for correction or leave unresolved.
- Verifier: designated dispatch coordinator, with source records and route policy available; the producing component does not accept its own work.
- Distinct later events: intervention authorized and confirmed in the shipment system; authoritative delivery observation; attributable benefit against an agreed comparison.
- Implementation limit: the teaching program described in the note ends at `review_ready`. Coordinator decisions, shipment intervention, delivery observation, and the queries to count them are proposed later work.

## Hypothetical cohort at one reporting cutoff

All counts are invented teaching inputs, not measured performance. The cohort is the group of 100 unique eligible shipments selected for this report. The reporting cutoff is the date and time at which the counts are taken, including work still pending. Do not count repeated notifications, runs, or retries as new shipments.

| Event                     | Count and denominator                                                  | Evidence / remaining work                                                                                     |
| ------------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| Eligible                  | 100 unique shipments                                                   | Owner-approved eligibility rule and source cohort; real rule/query revisions still needed                     |
| Exposed                   | 80 / 100 = 80%                                                         | Shipments that reached the workflow; 20 eligible shipments did not reach it                                   |
| Completed routing         | 70 / 80 = 87.5%                                                        | 30 no-review routes plus 40 staged cases; completed routing is not independently verified routing correctness |
| Stopped or escalated      | 10 / 80 = 12.5%                                                        | Retain reason, owner, and fallback; do not drop these from the exposed denominator                            |
| Review cases staged       | 40                                                                     | Non-binding preparation result; no coordinator acceptance inferred                                            |
| Review decisions recorded | 32 / 40 = 80%                                                          | 28 accepted prepared cases; 4 rejected prepared cases                                                         |
| Accepted review work      | 28 / 40 = 70% of staged cases; 28 / 32 = 87.5% of cases with decisions | Show both denominator labels and the 8 pending cases                                                          |
| Confirmed interventions   | 12 / 28 accepted reviews                                               | Not every accepted review requires intervention; shipment-system evidence is separate proposed work           |
| Delivery observations     | 60 / 100 = 60% coverage                                                | 40 pending; observed count alone says nothing about on-time performance or causal benefit                     |

Arithmetic checks: 30 + 40 + 10 = 80; 28 + 4 + 8 = 40; 60 + 40 = 100. The eligible cohort remains 100 throughout. No delivery-success or benefit percentage can be calculated from these inputs.

## Blank event contract

Start with one shipment and fill in the event rows in order. What makes it eligible? Which record shows that the software received it? What did the software finish, and did a coordinator accept that work? Keep any later shipment action and delivery result separate. For each row, name the record and counting query, who can check it, and how long the report waits before showing the result as pending.

| Event                  | Definition and identity                          | Source and query revision                          | Verifier and rejection                                | Window and unknown status                     | Owner |
| ---------------------- | ------------------------------------------------ | -------------------------------------------------- | ----------------------------------------------------- | --------------------------------------------- | ----- |
| Eligible               | Approved segment; stable item key; exclusions    | Cohort source; eligibility and query version       | Owner checks population                               | Cohort start/end; missing source handling     |       |
| Exposed                | Item reaches the changed workflow once           | Admission/run event; query version                 | Reconcile unique item identities                      | Exposure window; unexposed reason             |       |
| Completed              | Exact bounded software result                    | Persisted result or source-system readback         | Rule checks state and required evidence               | Completion cutoff; stopped/escalated/pending  |       |
| Independently accepted | Exact reviewed unit; accept/reject/correct/defer | Review decision or source record; criteria version | Named reviewer or independent check can reject        | Review window; unresolved state               |       |
| Business effect        | Separate downstream result and attribution       | Authoritative outcome; comparison/query version    | Measurement owner confirms definition and limitations | Outcome lag; pending and missing observations |       |

Specify numerator and denominator for every percentage. If different routes have different accepted units, report them separately. A routing decision, reviewed case, and confirmed system update are not interchangeable cost denominators.

## Observation and corrections

- Which eligibility rule, shipment IDs, reporting period, and exclusions define this group?
- Which event definitions, queries, source snapshots, and system, model, and policy versions produced the counts?
- How long will the report wait for a review decision, and why?
- How long will it wait for a business effect, and why?
- Which cases are still pending, for how long, and for what reason?
- Which source failures or missing observations leave a result unknown?
- How are repeated events attached to the same business item rather than counted again?
- How will a late result correct the report while preserving the original report and its cutoff?
- What safety or cost condition stops new work? Who supports the cases already in progress?

Choose observation windows before examining results. Silence does not mean acceptance or failure. Preserve the attribution of a late event to its original item and version.

## Cost and benefit

- Which independently accepted result is the unit used for costing?
- What did all served cases cost, including rejected and pending work? Include allocated delivery/change, review, support, recovery, and operation costs.
- How many results were accepted by the observation cutoff?
- If that count is greater than zero, what is the cost per accepted result? If it is zero or unknown, report cost and count separately.
- What benefit is proposed, and which authoritative source could confirm it?
- Which baseline or comparison, population, and period apply? What other changes could explain the result?
- Which benefit or loss evidence is missing?
- Should the owner correct, constrain, continue, pause, or investigate? Who decides, and by when?

Take one permitted case through the event map. Ask the verifier to show why they could reject it and how the report preserves a pending result. Narrow the claim when the evidence stops.