# Attribution comparison record

Use this when a service's acceptance, cost, speed, or business result appears to improve. Keep the cases behind the overall number and name which change the comparison can test.

The counts below are supplied hypothetical inputs, not observed results or a controlled experiment. Calculating both periods with the same mix of cases can reveal a misleading overall rate; it does not prove what caused a real change.

## Completed case-mix exercise

Hypothetical job: prepare facts and source references for independent review. Acceptance requires the same source and completeness checks in each period. Easy/difficult labels are assigned before knowing the outcome.

Both main-example periods contain 100 eligible cases. All were processed and independently checked by the reporting deadline. Repeated attempts and corrections do not add cases.

| Group            | Baseline / candidate                                                                    |
| ---------------- | --------------------------------------------------------------------------------------- |
| Easy             | Eligible 20 / 80; accepted 18 / 72; known not accepted 2 / 8; acceptance 90% / 90%.     |
| Difficult        | Eligible 80 / 20; accepted 40 / 10; known not accepted 40 / 10; acceptance 50% / 50%.   |
| Total            | Eligible 100 / 100; accepted 58 / 82; known not accepted 42 / 18; acceptance 58% / 82%. |
| Missing outcomes | Zero / zero in this main example.                                                       |

Aggregate change: 82% − 58% = **24 percentage points**. Neither segment improved. The candidate period contains more easy cases.

Apply a declared common mix of 50% easy and 50% difficult:

- Baseline: 0.5 × 90% + 0.5 × 50% = **70%**.
- Candidate: 0.5 × 90% + 0.5 × 50% = **70%**.

These standardized rates are calculated values, not another observed population or a forecast. The two-category mix explains the constructed aggregate difference. In real work, omitted or poorly defined categories and uncertainty can invalidate the comparison. Keep actual mix and counts visible.

**Supported disposition:** neither easy nor difficult cases improved, so the headline supplies no evidence of a better model or workflow. Do not expand from it alone. Service cost, harmful errors, customer outcomes, and what caused any real change remain unmeasured.

## Separate missing-outcome stress case

This adds cases to the candidate period. Keep it separate from the main example, where every case has a known result.

- Eligible: 110 cases.
- Known accepted: 82.
- Known not accepted: 18.
- Outcome unknown: 10.
- Known-outcome rate: 82/100 = 82%; excludes the ten unresolved cases.
- Confirmed acceptances as a share of all eligible cases: 82/110 ≈ 74.5%; not the final rate.
- Final acceptance bounds: 82/110 ≈ 74.5% if all unknown cases fail; 92/110 ≈ 83.6% if all succeed.

Those bounds assume this fixed group and an eventual accepted-or-not-accepted result. They cannot establish when cases finish or whether the unresolved cases are harder. Keep their IDs, reasons for remaining unresolved, reporting deadline, and later results so you can follow the same cases at the next review.

## Blank comparison record

### Start with these questions

1. Which improvement are you claiming, and what decision would it support?
2. Did the same types of cases improve, or did easier work make up more of the total?
3. Which results are still missing at the reporting deadline?
4. What else changed that could explain the difference?

### Establish the comparison

- Which one component or whole-process change are you testing?
- Which cases qualify, which are excluded, and which case IDs and source version define each group?
- What event counts as accepted, and which acceptance rule stays unchanged?
- Who checks acceptance separately from the producing system? Who may approve the expected test answers?
- Which source, period, environment, and permitted work describe the old process?
- Which describe the proposed process, and exactly what changed?
- How do cases enter each comparison group, why is that comparison credible, and who approves the arrangement?
- What counts as one independent case? Which related tickets or repeated attempts must stay attached to the same incident?
- What are the observation period and reporting deadline? How will you estimate uncertainty and retain delayed or missing outcomes?

| Segment defined before outcomes | Baseline raw counts and rate / candidate raw counts and rate |
| ------------------------------- | ------------------------------------------------------------ |
|                                 |                                                              |
|                                 |                                                              |
| Total                           |                                                              |

- What is the actual mix of cases? If you calculate a common mix, why does it fit this decision?
- Which outcomes remain unresolved, why, and for which retained case IDs? How would plausible or extreme outcomes change the result?
- Did demand, eligibility, sources, policy, staffing, review, tools, model, price, or measurement change?
- What stayed the same? Which other changes prevent crediting the result to the intended change?
- What happened to safety, customer or operator results, delay, review, correction, support, recovery, and full cost?
- Which cases stayed out of development, and were repeated runs needed? Which groups face especially harmful errors, and what would stop the comparison?
- Which facts were observed, which were forecast, which rates were calculated, and which results remain unmeasured?
- Which other explanations remain open, and what can this comparison not establish?
- What claim does the evidence support? Who decides, which actions remain unapproved, and what evidence is needed next?

Keep rejected, excluded, and unresolved work visible. A narrower eligible population may improve a rate while leaving the organization with the same difficult work elsewhere.