Keep contractual consequences separate

This is a review draft and a synthetic buyer worksheet—not legal acceptance language. No buyer packet, customer data, completed acceptance exercise, or legal review underlies it. Every example is a representative prompt, not an observed result.

The executed agreement controls acceptance criteria, authorized decision makers, notice and cure procedures, deadlines, and payment obligations. Do not infer a right to withhold payment from this worksheet. Ask qualified counsel about contractual or legal consequences.

Bind the packet to the exact delivery

Start with an identity row:

Field What to record
Scope The agreed capability or deliverable under review
Artifact Repository revision, package digest, or deployment receipt
Environment The test or production-like environment used
Reviewer The person authorized to evaluate the result
Date When the procedure ran

“The latest version” is not an artifact identity. A packet that cannot bind its test result to the delivered revision has an operational evidence gap. The agreement—not this worksheet—controls its contractual effect.

Prove normal and negative workflows

For every material capability, record the input, action, expected result, observed result, evidence link, and state. Include at least one failure or denied path where the feature has meaningful consequences.

Examples of useful evidence include a repeatable test record, a redacted export, a screen recording tied to the revision, an audit entry, or an operator walkthrough. A screenshot can support a claim; it rarely proves the complete workflow by itself.

The packet should distinguish:

  • tested: the named procedure ran against the exact artifact;
  • supplied: a file or account was delivered but not independently tested;
  • untested: the row is in scope without a procedure;
  • disputed: buyer and supplier disagree about scope or result; and
  • not-applicable: the buyer recorded why the row does not apply.

Treat data and access as deliverables

Source code is only one handoff. Ask which records, schemas, exports, attachments, configuration values, third-party accounts, domains, and recovery contacts transfer. Record what was validated and what remains an assumption.

For access, do not publish or paste secrets into the packet. Record the account owner, role, transfer method, recovery contact, and confirmation that the buyer can perform the required operation. NIST's SSDF provides a vocabulary for secure development and provenance practices; it does not certify a supplier's handoff.

Make recovery an evidence row

If the software changes durable data, ask what backup, restore, rollback, or manual recovery procedure was actually demonstrated. Name the data-loss boundary and the person who would run the procedure. “Backups exist” is a supplied fact until a restore result is attached.

The same logic applies to monitoring, support, training, and retirement. A buyer needs to know what happens after the delivery team leaves, not merely that the application opened during the demo.

Record open defects before the decision

An open-defect table should include the defect or risk, affected workflow, severity as the buyer defines it, workaround, owner, next date, and decision state. Do not invent a universal severity scale or call a defect harmless because the demo path succeeded.

Copy the acceptance packet

Packet identity

Field Buyer record
Agreement or scope reference Replace with the controlling reference
Deliverable under review Replace with the exact capability or artifact
Immutable artifact identity Revision, digest, package, or deployment receipt
Environment Where the procedure ran
Authorized reviewer One named person under the agreement
Review date Date and time of the procedure

Add workflow rows

Copy one row for each normal, denied, invalid, duplicate, and failed path that matters to the buyer.

Criterion ID Procedure and input Expected result Observed result Evidence location Reviewer Evidence state
Replace with agreed criterion Replace with reproducible steps Replace with measurable result Leave blank until run Redacted link or record Named reviewer untested

Add handoff and recovery rows

Item Required evidence Observed result Owner Evidence state
Data export and schema Redacted export plus validation record Leave blank until checked Named buyer owner untested
Account and access transfer Role, transfer method, recovery contact, buyer check Leave blank until checked Named account owner untested
Backup, restore, or rollback Procedure, data-loss boundary, and demonstrated result Leave blank until run Named recovery owner untested
Build and source handoff Revision, licenses, build steps, and third-party inventory Leave blank until checked Named supplier and buyer owners untested
Monitoring and support Signals, escalation route, operating owner, and retirement path Leave blank until checked Named operator untested

Add defect and decision rows

Defect or risk Affected workflow Buyer-defined severity Workaround Owner Next date Decision state
Replace with observed issue Replace with criterion ID Use the buyer's recorded scale Record or none Named person Date open

Final operational decision

Field Buyer record
Decision accepted, conditional, rejected, or more evidence needed
Evidence rows relied on Criterion and handoff IDs
Open conditions Defects, missing evidence, or none
Authorized decision maker One named buyer reviewer
Decision date Date and time

The evidence states are tested, supplied, untested, disputed, and not-applicable. A final decision is separate from those evidence states.

Copy this packet before comparing the final milestone. Then compare its recurring obligations with maintenance retainer scope, normalize the proposal with the quote worksheet, and keep the source-code exit plan separate from acceptance.

The strongest conclusion this packet can support is not “the software is good.” It is: “the buyer can identify the exact delivery, see what was tested, see what remains open, and decide what evidence is still needed.”