Fix the workflow boundary

Budgeting becomes vague when the item being costed is simply "the AI". Name the trigger that starts the work and the observable state that ends it. Include every handoff needed to reach that state.

For a document review workflow, the trigger might be an authorised user submitting a supported file. Completion might mean the extracted fields have been checked, accepted into the system of record and made available to the next process. Model inference is only one step between those points.

Draw the operating path in plain language:

1. A request arrives and identity and permission are checked.
2. Source material is accepted, scanned and normalised.
3. Relevant context is retrieved.
4. The model proposes an output or action.
5. Deterministic validation runs.
6. A person reviews cases that require judgement.
7. Accepted results update the intended system.
8. The user receives a status and correction route.
9. Logs, evidence and temporary data follow retention rules.

Add branches for the failures you already know must be handled: unsupported input, missing context, provider timeout, malformed output, rejected recommendation, duplicate request and an external system that is unavailable after approval.

The boundary should include upstream source maintenance if output quality depends on it. A retrieval workflow backed by policies and procedures consumes editorial work whenever those documents change. Record that work even when another team pays for it, otherwise the workflow estimate will be incomplete.

Define the unit of work. It may be a case, document, conversation, decision or completed action. Choose a unit that can be counted at the trigger and completion points. If a single case can create several model calls, retries and review tasks, do not use "API call" as the business unit.