How to Write a Deliverables List a Non-Engineer Can Use

The first editing pass on any deliverables list is deleting activities. "Discovery workshop", "weekly demos", "model tuning", "stakeholder alignment" are things the vendor does. They cannot be accepted. They can be scheduled, monitored, and paid for by the hour, but they cannot be handed over and inspected.

Outputs are artifacts. An artifact is a thing with a location: a file, a repository, a deployed endpoint, a document. The test is dull but reliable: can the buyer open it, run it, or read it without the vendor in the room? If the answer is no, it is an activity in disguise.

Four output types cover most AI builds, and each has a natural test:

• A working prompt or prompt set. Test: run it against three sample inputs the buyer supplies and check the response against a specified schema.
• An eval set with a scoring script. Test: run the script and read the pass rate it prints.
• A runbook. Test: a non-engineer follows it end to end on a clean environment.
• A dataset. Test: row count, column list, label distribution and a sample of rows the buyer inspects against a written rubric.

Anything that does not fit one of these four needs its own test written from scratch. If you cannot invent a test in five minutes, that item probably belongs in a time and materials phase, because you cannot verify it either.

Three properties make a criterion usable by a non-engineer.

Observable. The buyer sees the result, not the reasoning. "The function returns HTTP 200 with the required fields" is observable. "The architecture is sound" is not.

Binary. Pass or fail, with a pre-agreed threshold where a number is involved. "Pass rate of at least 0.80 on the 50-example eval set" is binary once you run the script. "Quality is high" invites negotiation.

Pre-agreed. Written before work starts, agreed in writing, and unchanged during the build. Criteria invented at the end are a renegotiation, and the party who wrote them last usually wins.

Here is the pattern that holds up in practice. For each item, state three things: the artifact, the exact check the buyer performs, and the pass condition. A worked example:

Deliverable D2: Support triage prompt
Artifact: prompts/triage.md in the delivery repository
Check: Buyer pastes the file contents into the vendor's hosted test harness,
       submits the three sample messages in fixtures/triage_samples.json,
       and copies each response.
Pass condition: All three responses parse as JSON and contain exactly the
       keys category, priority, rationale. category is one of
       billing, technical, account. priority is an integer 1 to 3.
       rationale is a non-empty string under 200 characters.
Reject condition: Any response fails to parse, is missing a key,
       or returns a category outside the list.

Everything in that block is checkable by a competent operations person with no ML background. The vendor cannot argue that the buyer "does not understand" the result, because the result is a parse and a membership test.

Note the reject condition. Writing down what failure looks like is as important as writing the pass state. It removes the most common post-delivery dispute, which is not "this is broken" but "this is not what I meant".

For eval sets, resist the temptation to accept "an eval set" as the deliverable. The artifact is only half the item. The other half is the script that turns it into a number, because a dataset with no scorer is a folder the buyer cannot interpret. Specify the script's output format: a printed pass rate, the count of failures, and the list of failing example IDs.

A deliverables list becomes a contract mechanism when it has four parts: a numbered item list, the check for each item, the payment schedule mapped to items, and a rejection clause that names the failed check.

Write it as a table the buyer signs. Something like this, with the vendor's figure in the last column:

Three design rules make this schedule work.

Pay on acceptance, not on elapsed time. Milestone payments tied to predefined schedules help both parties manage cash flow, which is one of the stated advantages of a fixed price arrangement (SOLTECH). Tie each milestone to an item ID so there is no ambiguity about what triggers the invoice.

Fix only two of budget, scope and time. Agile work is time-boxed and flexible in scope by definition, so a fixed bid should lock budget and time and let scope flex around a ranked list. The workable pattern is to fix two variables and let the third absorb what you learn (Very Creatives). Reorder the deliverables list, with agreement, rather than reopening the price.

Give the buyer a cure period. Rejection should trigger a fix window, not immediate termination. Say: the buyer runs the check within five business days of notification, states which check failed and pastes the observed output, and the vendor has a defined period to resubmit. If the resubmission fails the same check twice, the buyer may accept a pro rata credit or terminate that line item. This keeps rejection factual and keeps the project moving.

One more structural point. Fixed bid pricing carries a risk premium, and vendors add buffer to cover unknowns (Atomic Object). The tighter and more checkable your acceptance list, the smaller that buffer needs to be, because the vendor is no longer pricing the risk of an unbounded argument at the end. A precise list is not just protection. It is a discount you can negotiate.

An acceptance criterion that requires the buyer to trust the vendor's report is not acceptance. The test must be executable by the buyer, in the buyer's environment, with the buyer's credentials where possible.

Three practical levels of testability, in ascending order of strength:

1. Inspection. The buyer opens the artifact and checks it against a written rubric. Fine for datasets and documentation. Cheap, but relies on the rubric being specific.
2. Execution. The buyer runs a script or a command and reads the output. Strong for eval sets and scoring scripts, and it transfers control of the number to the buyer.
3. Reperformance. The buyer follows a written procedure unaided and records the result. This is the right level for runbooks, and it is the only honest test of whether documentation is usable.

Write the check as a numbered procedure, not a sentence. "Log in to the test harness, open fixtures/triage_samples.json, submit each message in order, paste each response into responses.json" is runnable. "Verify the prompt works" is not.

Two details that prevent most acceptance disputes:

Name the fixtures. The buyer supplies the sample inputs at contract signing, and they are fixed. If the vendor writes the test inputs after seeing the system, the test is worthless.

Freeze the environment. State which environment, which credentials, and which version of any configuration the check runs against. A check that passes in the vendor's environment and fails in the buyer's is a real failure, and the contract should say so before it happens.

Where the artifact is a runbook, the acceptance test is the dry run. Give the buyer a checklist derived from the runbook, and require them to complete it unaided. If they get stuck, the runbook failed, regardless of how good the system is. This is the same principle behind writing acceptance criteria as positive, testable statements about outcomes rather than implementation instructions: the criteria describe what must be true, not how the team gets there (Testomat).

"And any other work reasonably required." This clause is the opposite of an acceptance list. It reintroduces unbounded scope into a fixed price, which either forces the vendor to pad the bid heavily or guarantees a change-order fight. Delete it and enumerate.

Acceptance by committee. If five people must agree, the criterion is a judgment call with extra steps. Name one approver per item, in writing, and name a backup.

Demo as evidence. A demo shows the system behaving under the vendor's chosen inputs. It does not show behavior on the buyer's fixtures. Demo attendance is a governance activity, not an acceptance check.

Mixing business outcomes into item acceptance. A deliverable list should test the artifact, not whether the business metric moved. Handling time, conversion or cost per ticket depend on workflow adoption and a measurement window, and they belong in a separate benefits section with a baseline and a target, not in the acceptance gate. Conflating the two is how projects get called a failure after the software works.

Skipping the baseline. If the statement of work names last quarter's average handling time as the reference number, the project is already ahead of the median on the one dimension that decides continued funding (Heinrich Co). This does not replace item acceptance. It sits alongside it.

Classification confusion on the vendor side. If the buyer is engaging an individual rather than a firm, worker classification is a separate legal question from acceptance, and the label in the agreement does not settle it. The IRS looks at behavioral control, financial control and the nature of the relationship, not the contract title (IRS). The Department of Labor makes the same point: a signed independent contractor agreement, a 1099, or an EIN does not by itself make someone a contractor (DOL). Acceptance criteria govern delivery. They do not govern classification, and treating them as a substitute creates risk in a different domain.

No handover test. The last item is always knowledge transfer, and it is always the one with no test. Make it executable: the buyer clones the repository and runs the scoring script on their own machine. If it does not run, the item is not accepted.

Use this against a draft statement of work. Every "no" is a place where the final payment becomes a negotiation.

If you are buying rather than selling, the same list works as a negotiation script. Hand it to the vendor before the bid and ask them to fill in the checks. A vendor who cannot write a test for an item has told you something useful about how well they have scoped it, and you have found that out before signing rather than at the final milestone.

If you would rather have the build and the acceptance list produced together, a free 30-minute AI discovery call is a reasonable place to start: bring the artifact you need and the checks you want to run, and work backwards to a list both sides can sign.