# First-workflow decision brief

Companion to Caisi’s “Is this workflow worth automating?” by David Ahmann.
Use this for one bounded investigation. It grants no data access, action
authority, pilot approval, or production release permission.

## 1. Name the work

- Who does it, in which existing system, and what triggers it?
- Who owns the result and can approve a change?
- Which cases qualify? Which stay with the current process?
- What must remain human or policy-controlled?

## 2. Record the current process

- Cases inspected, permitted evidence location, source revision, and date:
- Hands-on work, waiting, correction, and hidden handoffs:
- Upstream and downstream constraints:
- Which cases describe the current process, and when did they arrive?
- What time, errors, and costs will you compare the proposed change against?
- For each figure, is it measured, estimated, or still unknown? Where can someone check it?
- Missing access, disagreements, and the next question to resolve:

A first look at 10–15 cases can expose questions. It does not establish a
population-wide defect rate or prove data readiness. Minimize retained data;
keep sensitive material in the owner-approved evidence store.

## 3. Define a result that can be accepted

- What completed work would count as correct?
- Who can reject it independently, or which authoritative source can confirm or contradict it?
- What check determines acceptance, and which saved record proves completion?
- What failure or loss is too large to tolerate? What safe fallback remains, and when must the work stop?

## 4. Compare options and costs

- Could the current process, an upstream repair, an existing product, or a bounded build meet the need?
- In the declared period, how many cases qualify, how many will likely reach the service, and how many will be accepted?
- What benefit is expected per accepted case, and how will someone check it?
- Currency, measurement period, and low / expected / high scenarios:
- One-time delivery, integration, assurance, training, and change cost:
- Fixed service, maintenance, support, and incident/recovery allocation:
- Variable model, tool, compute, retry, storage, and other runtime cost:
- New human review, correction, exception, and recovery effort:
- Residual loss and harm (mark unknown rather than defaulting to zero):
- What is the full cost per independently accepted result? If that count is zero or unknown, report cost and count separately.

Keep costs mutually exclusive. Include the cost of unsuccessful cases. Check
whether time released is net of all new human work.

## 5. Identify how the benefit will be used

- Net capacity hours expected and intended/observed use:
- Actual reduced expenditure, with its owner and evidence:
- Avoided cost or additional accepted work, with demand and comparison evidence:
- Overlap exclusions so the same benefit is counted once:

Hours multiplied by salary are a planning value, not proof of cash savings.
Keep forecast, pilot evidence, and realized operating benefit separate.

## 6. Make the next decision

- Investigate / narrow / defer / do not build / propose a bounded test:
- Most consequential uncertain assumption:
- Test, permitted access, comparison method, and evidence cutoff:
- Decision owner, independent reviewer, and decision date:
- Receiving service owner and support capacity if a build proceeds:

A favorable forecast cannot override missing ownership, lawful access,
verification, safety, adoption, or operating capacity. Revisit the decision
when its evidence or assumptions change.