An AI workflow scope should describe the job, its inputs and permitted actions, how a person will review decisions, what counts as acceptance and who will operate the system.
Use this checklist for a build discussion. Its fields and examples are proposed working material, not existing Invisible capabilities. If the workflow is unclear, start with what to define before building custom AI.
Complete the scope before selecting components
Write a short statement first: “When [event] occurs, [user] needs [output] to make [decision], using [authoritative records]. The proposed system may [allowed actions] and must hand [exceptions] to [owner].”
Fill in the fields below. Name unresolved items and assign them to discovery or a later release.
| Scope field | What to record |
|---|---|
| Business owner and users | Who accepts the work, who uses it and who is affected by its actions |
| Trigger and boundary | The event that starts a run and the point where responsibility ends |
| Records | Sources, record owners, required fields and which source resolves conflicts |
| Output | The screen, draft, record or notification the user should receive |
| Allowed actions | Reads and writes, permitted destinations and explicit exclusions |
| Human decisions | What requires review, who can decide and what they must see |
| Exceptions | Missing input, conflicting evidence, unavailable systems and escalation owner |
| Acceptance evidence | Test cases, expected outcomes, evaluation method and release decision maker |
| Operating terms | Monitoring, support, maintenance, change review and recurring cost assumptions |
| Exit and handoff | Source/configuration access, data handling, documentation and transition responsibilities |
Separate the initial release from later possibilities. Name who can approve a scope change and how its acceptance checks would change.
Specify access and approval as observable behavior
For each source, identify the data and account needed. For each destination, specify what may change. Have the record owner confirm access; keep credentials out of the scope document.
Define retention and deletion for inputs, generated outputs, logs and backups. Record who decides those rules and which system implements them. A statement that data is “secure” does not answer how long a copied attachment remains or who can inspect a failed run.
For a reviewed action, specify the target record, proposed change and evidence shown to the reviewer. Decide what happens after rejection, timeout or a change to the underlying record. If the proposal changes after review, define whether another decision is required before execution.
Agree the acceptance scenarios before the demonstration
The table below uses a hypothetical project-change workflow. A proposed system would turn a request into a draft change for an operator to review. These expected outcomes are example requirements to adapt, not results from an implemented system.
| Scenario | Expected behavior to agree | Evidence to inspect |
|---|---|---|
| Complete, ordinary request | Produce a draft linked to the correct project, with the requested change distinguishable from the existing record | Input, referenced record and draft |
| Required project identifier missing | Ask for clarification or route to the named exception owner; do not guess a destination | Exception state and destination record |
| Same request arrives again | Detect or reconcile the repeated request without applying the change twice | Run identifiers and final destination state |
| Reviewer rejects the proposal | Leave the destination unchanged and retain the decision according to the agreed policy | Review record and destination state |
| Destination changes during review | Identify the conflict and follow the agreed re-review rule | Before/after versions and action history |
| Connection fails after an attempted write | Show that the result is uncertain until reconciled; do not silently assume success or repeat the write | Destination check and recovery record |
| Access is denied | Stop the affected action and surface the failure to the owner without expanding permissions automatically | Denial and escalation evidence |
Inspect the destination state as well as the workflow's status message. “Completed” on a screen does not establish what changed elsewhere.
Evaluate judgment separately from execution
A correct update and a correct interpretation are different questions. Have someone who knows the work review expected interpretations. Reserve evaluation examples that were not used to tune prompts or rules, including uncommon but consequential cases.
Agree which mistakes are tolerable, which require human review and which prevent release. Record correction effort and unresolved cases alongside successful outputs. NIST's AI RMF recommends testing before deployment, monitoring during operation and evaluating performance in conditions resembling the intended setting. Those principles support evaluation beyond a prepared demonstration. NIST AI RMF Core, Measure
Make operation and handoff part of acceptance
Name an operational owner and a technical maintainer. Ask them to demonstrate how they would inspect a failed run, pause new work, reconcile an uncertain action and resume safely. Identify which changes require re-running acceptance tests, including changes to prompts, models, mappings and permissions.
The handoff should include the deployed version, configuration instructions, dependencies, access arrangements, limitations and recovery procedure. Record who pays recurring costs and who responds when a third-party service changes.
Start with a limited release and retain a workable fallback. Expansion should follow the agreed evidence and an explicit owner decision. If the proposed implementation cannot satisfy a requirement, revisit the comparison of no-code, custom and hybrid approaches before weakening the requirement without discussion.
Invisible Product Inc. can review a workflow brief and discuss the scope of a proposed custom engineering engagement. Discuss a workflow.
Sources and authorship
Prepared by Invisible Product Inc. The checklist and project-change scenario are original guidance and hypothetical examples. Reference checked September 27, 2026: NIST AI Risk Management Framework Core. The worksheet is not a NIST certification or an assertion that a system meets the framework.