An AI workflow can produce fluent text and still leave the business task unfinished. A draft may omit a required source, reach the wrong review queue, or appear complete even though a prohibited decision was made. A definition of done converts “the AI ran” into observable conditions a business owner and reviewer can verify.

This guide helps United States small businesses write a definition of done for one bounded AI workflow. It does not guarantee business outcomes or replace acceptance testing with real cases. Local AI Developer scopes systems around documented workflows and human controls; compare the system package levels and review the Los Angeles County workflow service page for team-handoff projects.

Describe the business handoff

Start with the event that begins the work, the output produced, the person who reviews it, and the destination where that person receives it. “Summarize emails” is incomplete. “Prepare a source-linked intake brief from messages in the approved queue and place it in the operations review folder” is testable.

Name the next human decision. The workflow might help a reviewer decide whether information is complete, which team owns an exception, or whether a draft is ready to send. It should not silently make that decision unless the business has explicitly scoped and approved it.

State the frequency or timing expectation in business terms. Avoid promising instant or continuous operation when a scheduled review is sufficient.

List required output fields

Define the smallest output structure the next person needs. Include identifiers, source references, status, missing-information notes, proposed next step, and reviewer field where appropriate.

For each field, identify its source and whether absence causes a hold. A blank field should not be disguised with invented content. Use an explicit “not found,” “not provided,” or hold reason when the source does not support an answer.

Separate facts from generated suggestions. Label a draft response or proposed category so a reviewer does not mistake it for a source-system value.

Define source evidence

Done should mean the important claims can be traced to approved sources. Specify whether the output needs a stable record ID, document name and version, message link, retrieval time, or quoted excerpt.

Name the authoritative source owner and freshness rule. If two sources conflict, the workflow should surface the conflict and stop at the defined hold state rather than selecting the more convenient value.

Do not require copying entire source files when a reference is enough. The evidence should support review while respecting the workflow's approved data boundary.

Keep approval separate from preparation

Define what the workflow may prepare and what requires a person. External messages, prices, delivery commitments, customer-record changes, publishing, payments, and deletion usually need explicit authority defined by the business.

Use distinct states such as draft ready, approved, sent, and closed. A draft is not approved merely because it contains no visible error. An approved item is not sent merely because the workflow can access a communication tool.

Record approver identity, time, and the exact item or version approved. Material edits after approval should return the item to review.

Define acceptable holds

A workflow can be correctly done for the moment by placing an item on hold. List conditions such as missing required data, stale source, source conflict, unknown requester, unsupported file, unavailable reviewer, or action outside scope.

For each hold, require a reason, owner, next action, and enough source context for resolution. Avoid generic failure labels that force the operator to repeat the investigation.

State what the workflow must not do while held. It should not send a partial draft, infer a commitment, retry a business decision, or quietly mark the item complete.

Account for duplicates and retries

Choose a stable item identifier and define how the workflow recognizes that input was already processed. A timestamp alone may not distinguish a retry from a new case.

If a connection fails after creating an output, the workflow should check destination state before trying again. Define whether an existing draft is updated, preserved, or routed for reconciliation.

Done includes one expected output, not merely one successful execution log. Test interruption at several steps to verify that recovery does not create duplicate messages or records.

Define delivery evidence

Specify the approved destination and evidence that the item arrived there. A successful model response does not prove that a file was written, a queue entry was created, or a reviewer could access it.

Delivery evidence might include a destination record ID, file path, queue state, or successful read-back. Select evidence the operator can inspect without exposing credentials or unnecessary data.

If delivery fails, keep the prepared output in an approved recoverable state and assign the next action. Do not label it complete.

Include a manual fallback

Write what the team does when the workflow is unavailable. Name the operator, approved sources, manual template, destination, and threshold for switching methods.

The fallback must retain important controls. It should not bypass approval, use personal accounts, or discard source references simply because automation is unavailable.

Done for the fallback should produce the same essential business handoff, even if it takes longer or uses fewer conveniences.

Add quality checks that matter

Choose checks tied to use: all required fields present, identifiers formatted correctly, source links resolvable by the reviewer, dates labeled with timezone, calculations independently verified, and prohibited claims absent.

Avoid relying only on word count, tone, or grammatical fluency. Those properties may matter, but they do not establish source accuracy or operating authority.

Define who performs each check. Some can be deterministic; factual usefulness and business approval still require an accountable reviewer.

Build acceptance cases from the definition

Create cases for an ordinary item, missing required field, conflicting sources, stale source, duplicate input, unavailable reviewer, and interrupted delivery. Add a case for the highest-risk prohibited action.

Write expected state, output fields, source evidence, destination behavior, hold reason, and external actions before running the cases. Record observed evidence and failures.

Have a reviewer other than the builder execute the set. A workflow is not ready because the builder can explain how to work around an undocumented behavior.

Observe real operation without expanding scope

For early live cases, confirm the exact approved version ran and the definition was met. Track exceptions separately from successful handoffs. An exception can reveal a missing rule without authorizing the workflow to invent one.

Review whether the output actually helps the named recipient make the next decision. If staff recreate the work elsewhere, determine whether the definition omitted a field, source, or destination requirement.

Do not treat early success as permission to add more tools, data, or autonomous actions. Each expansion needs its own scope and tests.

Maintain the definition as a business record

Assign an owner, version, approval date, and review trigger. Update it when sources, permissions, output fields, destinations, reviewers, or approval boundaries change.

Keep the previous approved version recoverable and identify the active version clearly. Connect change records and test evidence to the version they evaluate.

When the workflow is retired, preserve the readable operating knowledge the business still needs and remove obsolete access through the approved offboarding process.

Use a one-page definition of done

Capture:

Use the completed definition when you start a scoped workflow inquiry. It gives the builder and the business the same observable finish line without confusing a generated answer with a completed, reviewed handoff.