# Workflow step map

Use one row per consequential decision in one bounded workflow. Work through it with the person who owns the outcome and the people who can check the results. Completing this worksheet does not authorize data access, an action, or a production release.

## Scope

- Workflow and version:
- Date and decision owner:
- Operator and outcome recipient:
- Eligible cases and exclusions:
- Result this slice must produce:
- Independent verifier and acceptance rule:
- Current process or smaller alternative:
- Maximum cost, delay, review load, and tolerable harm:

An independent verifier can reject the producing component’s result. An accepted review case, a later system update, and a business benefit are separate events; choose the one this slice will measure.

## Decision rows

Copy the blank row for each step. If you are unsure what a row should contain, read the completed shipment row below first. Link evidence, source revisions, and tests in your working record. Do not copy confidential information into a public example.

The verifier is the check that can reject a wrong result. The permission ceiling states what the step may read or change and whose approval it needs. The fallback says what happens when the step cannot finish safely, and who takes over.

For the output, name the expected fields and their types, such as a shipment identifier and a review decision, rather than leaving its form to the model.

| Step and input                            | Decision and output       | Candidate mechanism and rationale                         | Verifier                             | Permission ceiling                             | Fallback                           |
| ----------------------------------------- | ------------------------- | --------------------------------------------------------- | ------------------------------------ | ---------------------------------------------- | ---------------------------------- |
| Step: / source and revision: / freshness: | Question: / typed output: | Selected: / simpler alternative: / evidence still needed: | Check or reviewer: / rejection rule: | Actor: / permitted read or effect: / approval: | Trigger: / safe response: / owner: |

Compare relevant alternatives: code or rules, a query, optimization, statistics or classical ML, retrieval, a foundation-model call, a bounded agent workflow, and human review. Do not introduce all of them. Also consider deleting unnecessary work or repairing an upstream input without removing required controls.

## Hypothetical shipment row

| Field      | Hypothetical entry                                                                                                           |
| ---------- | ---------------------------------------------------------------------------------------------------------------------------- |
| Input      | A current shipment record the requester may read for this customer, and a risk score using that same version of the evidence |
| Decision   | Does this shipment require a non-binding coordinator review case?                                                            |
| Mechanism  | Code applies approved score and value thresholds; no explanation may override them                                           |
| Verifier   | Local tests check the routing rule's limits; cases from the intended queue and coordinator review are still needed           |
| Permission | Read one authorized shipment and stage a review case; no shipment intervention                                               |
| Fallback   | Deny unauthorized reads; escalate stale or invalid evidence; use a fixed summary if optional explanation fails               |
| Limit      | Supplied fixture scores establish no predictive accuracy, calibration, or improved delivery outcome                          |

## One comparison to run next

- Decision and candidates:
- Permitted cases, their source references, and which stay out of development:
- Baseline and unchanged surrounding components:
- Frozen thresholds and error definitions:
- Results for difficult shipments and missing-evidence cases; missed risks, unnecessary reviews, and cases the system declines to decide:
- Reviewer time, latency, and full cost per accepted outcome:
- Required data access and provider policy, if applicable:
- Test owner, independent approver, and review date:

Keep some cases out of development and tuning: these are the held-out cases. Set the routing thresholds and define mistakes before looking at their results. Count missed risky shipments separately from unnecessary reviews, and record when the system declines to decide.

## Decision record

- Keep, replace, remove, defer, or investigate:
- Evidence and limitations:
- Unresolved authority or verification gaps:
- Next accountable action and owner:
- Failure, rollback, and replacement triggers:

Keep the earlier record when sources, thresholds, models, or permissions change. Recheck the downstream decision as well as the component score.