# Evidence, calculation rules and measurement definitions

## Business evidence

`brief.json` supplies six ordered stages, their owner labels, types, stage P50/P90 minutes and WIP 8. `intake.md` establishes the current-state correction cohort, once-daily picking, per-order batch size 1 after release, explicit wait stages, the services profile and snapshot-only WIP. All five intake decisions are answered by those documents: data type, current state, handoffs, batching and rework scope. No replies were invented.

The published `process.json` changes owner labels to functional roles and shortens the process title. Stage names, order, types, durations and WIP are preserved. Role labels are inferred from activities; they are not additional staffing facts. The selected cohort has correction on every route; no storewide correction probability can be inferred.

## Method sources read and used

The original **business-operations-skills**, version 2.8.0, routed this request to **process-mapper**, version 2.8.0, on explicit PROCESS selection plus bottleneck, waiting and handoff signals. Its process template supplied the input structure. The following supplied reference documents informed the interpretation:

| Reference | Applicable section | Use in this report |
|---|---|---|
| `lean_six_sigma_canon.md` | Value Stream Mapping | Separate processing, waiting and correction; preserve current-state evidence. |
| `lean_six_sigma_canon.md` | Theory of Constraints | Choose one first intervention and reassess after the constraint moves. |
| `lean_six_sigma_canon.md` | Kanban WIP Limits / Little's Law | Explain the need for average WIP and mean cycle time; reject the snapshot proxy as measured capacity. |
| `bpmn_essentials.md` | Swim lanes; Method and Style; When to use simpler notations | One internal process with role lanes, explicit cross-role sequence and a visible correction return. This is a readable process diagram, not executable BPMN XML. |
| `bottleneck_anti_patterns.md` | AP-1, AP-3, AP-5, AP-6, AP-7, AP-9 | Focus on the dominant delay, distinguish wait from work, require actual event data, test batching and monitor whole-process outcomes and tails. |

These references guide the analysis; their broad benchmark statements are not independent evidence about this merchant. No external business facts were added.

## Original tools and interpretation

The unmodified `process_documenter.py` validated and normalized the role-based input and generated the ASCII map. The unmodified `bottleneck_detector.py` then ran with profile `services`, followed by the unmodified `cycle_time_analyzer.py` with the same profile. The JSON tool outputs are retained unchanged. A reading note precedes the generated map because its total labels and owner-grouped arrows require interpretation.

| Script | SHA-256 of original script |
|---|---|
| `process_documenter.py` | `2cbf8c6cc7d11ac25d42dc5053770d1eefe4b339c516b9226e72999744ee144d` |
| `bottleneck_detector.py` | `c4e8046ec5f671775186f9070019f1eaafa2aa3e28f2f1eeecd08bccf4272512` |
| `cycle_time_analyzer.py` | `050841bb233e1c09ac4794457d60cf026d992ffa34f39cd61589c72c6246f446` |

Tool field meanings:

- `total_p50_minutes` and `total_p90_minutes` sum stage percentiles. Neither is an observed percentile of full orders. Dependence between stage times and individual order histories is unknown.
- All time shares use the 780-minute sum of medians as denominator. Rounded percentages can sum slightly above 100%; calculations retain greater precision.
- `throughput_per_hour` uses snapshot WIP divided by the sum of stage medians in hours. It is retained for reproducibility but is not a validated Little's-Law throughput estimate. Do not extrapolate it into per-day capacity.
- The services R1 threshold is 2.5 × mean value-add stage time: 2.5 × 10 = 25 minutes. Ratios 48 and 24 receive CRITICAL, ratio 3 receives MEDIUM. R2 uses a 50% wait-share threshold and receives HIGH here. R3 uses 15% rework share and does not trigger. Findings overlap and cannot be added together.
- The analyzer's implemented services verdict boundaries are HEALTHY at or above 20%, TYPICAL at or above 8%, and WASTE-HEAVY below 8%. Its general prose gives other generic boundaries; the report uses the actual selected profile. The result is below both sets of boundaries.
- Generic tool hypotheses about approval, self-service or staffing are not observations. Only the daily picking cadence is documented. Root-cause validation is part of the pilot.
- The 240-minute picking target and 540-minute total scenario are proposals, with all other stage medians held constant. They are not observations or forecast percentiles.

## Pilot log instructions

`pilot-event-log.csv` is a blank event ledger, not invented observation data. Add one row per event per order. Use a pseudonymous internal order reference; do not add customer names or contact information. `period` is `baseline` or `pilot`; `cohort` is `correction`, `no_correction`, or `pending` until outcome is known. Use consistent timezone-aware event times. Preserve open orders and initial inventory so overnight waits and censoring are visible.

| Event name | Meaning |
|---|---|
| `release_started` | Release activity begins; start of the modeled process. |
| `release_completed` | Eligible order enters the picking queue. |
| `picking_started` | Picking begins; ends the picking wait. |
| `packing_completed` | Packed order is ready for the dispatch queue. |
| `dispatch_handoff_started` | Dispatch begins handling the order; ends the first dispatch wait. |
| `correction_started` | Packing correction begins; number each attempt. |
| `correction_completed` | That correction attempt finishes. |
| `dispatch_started` | Final dispatch work begins. |
| `dispatched` | Shipment is dispatched; end of the modeled process. |

Repeat correction events with increasing `attempt_number` if needed. No-correction orders have no correction events. Record extra delay after handoff or between correction and dispatch as an additional named queue interval; do not silently allocate it to touch time. Stage touch-time calculations require active time or explicit interruption records if work pauses.

Use `labor_minutes` on completion events to record actual active staff effort for that stage, including interruptions separately; leave it blank on other events. Do not infer paid labor from elapsed queue time. Use `exception_reason` for missed pulls, extra queues, interruptions or correction causes. Record applicable dispatch cutoffs and a consistent order-complexity band so comparisons can be matched. Staffed hours and paid hours belong in the shift's operational record and the review, not inferred from the WIP snapshot.

Calculate each order's picking wait as `picking_started - release_completed`, first dispatch wait as `dispatch_handoff_started - packing_completed`, and elapsed cycle as `dispatched - release_started`. For correction labor, sum all actual correction attempts. If timestamps include pauses, use logged active minutes for labor.

For a set of complete order durations, report the ordinary median and nearest-rank P90 (`ceil(0.90 × n)` after sorting). Publish sample counts and missing-event counts. Show open/censored orders and their current ages separately; a complete-orders-only comparison can otherwise hide late shipments. Require at least 95% complete event coverage for eligible orders and comparable closure follow-up before adoption; coverage alone does not establish statistical confidence. Report correction and no-correction strata and the combined eligible population.

Observe throughput directly from completions per staffed hour. A future Little's-Law cross-check needs time-weighted average WIP, mean elapsed time and consistent boundary, clock and stable observation period, including opening and closing work. It must not mix staffed-hour throughput with elapsed-hour lead time without reconciliation.

`pilot-scorecard.csv` defines nine metrics, owners and decision rules. Its blank result column is for future observations. The pilot has not been launched.

## Verification

Run `python3 verify-calculations.py` from the folder containing these deliverables. It independently recomputes totals, shares, findings, scenario arithmetic and every numeric row in `calculations.csv`, verifies that the pilot log has no invented observations, and checks that the scorecard has nine unfilled result rows. Verification status is recorded in `verification.txt`.