The Definition of Done: A Beginner’s Guide to Giving AI a Finish Line

“Prepare the customer update” sounds like a task. It is actually an open-ended instruction. Should the AI write an email, assemble account data, explain a delay, recommend next steps, or send the message? How accurate, complete, and polished must the output be? Who decides whether it is ready?

An AI can infer some of this, but inference is not the same as agreement. Without a finish line, it may produce something plausible while leaving the operational work incomplete. The remedy is a definition of done: an explicit description of the result, the checks it must pass, and what should happen next.

This is not a demand for elaborate prompting. A useful definition of done can fit in a few lines. Its purpose is to convert a broad request into a testable completion state.

The Core Vocabulary

Several terms are easy to collapse into “instructions,” but they perform different jobs.

A deliverable alone is insufficient. “Create a report” identifies an object, but not whether the report is correct. Acceptance criteria alone are also insufficient if the AI does not know where to place the result or whether it may take an external action. Done is the combined state.

A Mental Model: Production, Inspection, and Transfer

Think of an AI task as three connected stages.

1. Production: The AI creates or changes something.
2. Inspection: It checks the result against explicit criteria.
3. Transfer: It stores, routes, presents, or executes the approved result.

Most beginner prompts describe only production: summarize this document, analyze these accounts, draft this plan. Operational failures often occur in inspection or transfer. The summary omits a required decision. The account analysis uses stale data. The plan is produced in chat when the team expected a project brief.

The transfer stage deserves particular care because “finished” and “acted upon” are not synonyms. An AI may be done when it creates a draft. Sending that draft is a separate action with a different risk profile. Keeping those states distinct makes automation easier to govern.

A strong definition of done identifies the artifact, proves its fitness, and names its destination.

How to Write a Useful Definition of Done

Start with five fields. Use plain language rather than formal specifications.

• Output: Name the artifact or system change.
• Required content: List what cannot be omitted.
• Source of truth: Identify where critical facts must come from.
• Quality checks: State the tests the result must pass.
• Next state: Define whether the AI should save, route, request approval, execute, or stop.

Consider a vague request: “Review the late invoices and follow up.” A workable definition might read:

Create one draft email for each invoice more than 14 days overdue. Confirm the balance, due date, customer contact, and any recorded dispute against the billing system. Use the standard collections template, but omit any threat of service suspension. Save each draft to the customer record and assign it to the collections owner. Do not send. If an invoice is disputed or its contact is missing, place it in the exception list with the reason.

This short specification removes several hidden decisions. It defines the population, required facts, approved language, prohibited language, destination, approval boundary, and exception path. The AI can now distinguish completed work from merely generated text.

Make Acceptance Criteria Observable

Weak criteria depend on taste: “make it professional,” “cover the important points,” or “produce a high-quality analysis.” These phrases may guide style, but they are difficult to verify consistently.

Prefer observable conditions. Replace “make the update comprehensive” with “include current status, owner, next milestone, blocking issue, and requested decision.” Replace “use accurate customer data” with “take plan, renewal date, and account owner from the current CRM record.” Replace “keep it concise” with “use a subject line, a short opening, no more than three action bullets, and a direct closing request.”

Not every criterion must be numeric. It must, however, support a defensible pass-or-fail judgment. “Do not state that legal has approved the language unless the approval record is attached” is observable even without a number.

Separate mandatory checks from preferences

If every preference becomes mandatory, the AI may stall over minor imperfections. Label criteria according to consequence:

• Required: Failure makes the result invalid or unsafe.
• Preferred: Improve when practical, but do not block completion.
• Prohibited: Presence makes the result unacceptable.

For an executive briefing, factual attribution may be required, consistent heading style preferred, and unsupported financial claims prohibited. This hierarchy tells the AI where to spend effort and when to stop polishing.

Use Evidence, Not Self-Assessment

Asking an AI whether its own answer is correct produces a judgment, not proof. Strong workflows connect important criteria to evidence.

Suppose an AI prepares a hiring interview brief. A weak check is “confirm that the brief reflects the candidate.” A stronger check is: every claimed role, employer, and date must be traceable to the submitted résumé; every interview question must map to a stated requirement in the job description; any inconsistency must be listed rather than silently resolved.

This creates an evidence path. The AI does not merely report confidence. It can show why the work qualifies as done.

Evidence requirements should follow risk. A casual internal brainstorm may need no citation trail. A payment change, contractual notice, or customer commitment should be checked against an authoritative record. The goal is not maximum verification everywhere. It is proportional verification where errors matter.

Design the Failure Path Before Automation

A task is not well specified if it describes only the happy path. The AI also needs to know what to do when completion is impossible.

Common failure conditions include missing records, conflicting sources, unavailable tools, failed validations, and requests outside permitted authority. Define a response that preserves useful progress without disguising the gap.

For example, an AI compiling a weekly operations brief might be told:

• Use the current project system for milestone status.
• If the project system and team update conflict, show both and flag the conflict.
• If a required project has no current update, mark it “status unavailable”; do not infer progress.
• Complete the rest of the brief and route missing items to their owners.

This prevents one missing input from blocking the entire task while preserving the distinction between known and unknown. It also creates a recoverable queue instead of a polished document containing invented continuity.

A Worked Example: From Request to Finish Line

Imagine an operator asks: “Prepare me for tomorrow’s supplier review.” The request contains no clear artifact, scope, or endpoint.

A practical definition of done could be:

Produce a one-page supplier review brief using the current contract, the last two review notes, open quality issues, and outstanding invoices. Include contract renewal date, unresolved commitments with owners, delivery concerns, billing discrepancies, and three decisions needed from us. Link each issue to its source record. Put uncertain or conflicting facts in a separate section. Save the brief in the meeting folder and notify me that it is ready. Do not contact the supplier.

The production stage creates the brief. Inspection confirms that each required category appears and that issues link to records. Transfer saves the brief and notifies the operator. The stopping rule prevents supplier contact. The uncertainty section gives conflicting facts a legitimate destination rather than encouraging the AI to choose whichever version sounds credible.

If this task recurs, turn the definition into a reusable template. Keep stable requirements fixed, such as required sections and approved sources. Supply variable inputs at runtime, such as supplier name and meeting date. This is how a good prompt becomes an operating procedure.

What to Ignore for Now

Beginners often overengineer task definitions before testing whether the basic finish line works. Defer these concerns:

• Scoring systems: Weighted quality scores are useful only after simple criteria prove inadequate.
• Complex agent architectures: Multiple agents do not repair an undefined outcome. They distribute the ambiguity.
• Exhaustive edge cases: Start with common failures and add cases observed in real work.
• Perfect prompt wording: Stable fields and clear checks matter more than elegant prose.
• Full autonomy: First establish reliable draft, review, and handoff states. Broaden action rights later.

Your first objective is not to encode every possible judgment. It is to make ordinary completion visible and unsafe completion difficult.

Your First Implementation

Choose one recurring task whose output is frequently revised, questioned, or left hanging. Write its definition of done using the five fields: output, required content, source of truth, quality checks, and next state. Add one failure path for the most likely missing or conflicting input.

Run the task several times and inspect the revisions humans make. If reviewers repeatedly add the same missing item, promote it to a required criterion. If the AI spends time on something nobody uses, remove it or mark it preferred. If reviewers cannot verify a claim, strengthen the evidence requirement.

The result should become shorter and clearer as you learn. A mature definition of done does not describe every step the AI must take. It defines the state that matters, the proof that state has been reached, and the boundary beyond which the AI must not proceed.

This post was drafted with AI assistance and reviewed against our editorial policy before publication. Corrections are made at the source, on the page, with the date shown.