What an Acceptance Record Has to Prove

A buyer should be able to reopen a delivery record six months later and understand exactly what was accepted. The people who attended the final meeting may have moved on. The software may have changed. The folder should still explain what the buyer agreed was working, what supported that decision, and what remained unresolved. That is a useful standard for an acceptance record, and a surprisingly demanding one.

The difficulty begins with how delivery folders get assembled. They follow the supplier's activity: a report was written, a package was built, a test was run, a screenshot was taken. Each item answers a reasonable question about the work. The buyer needs those items connected to a different question: what can we now rely on? A hundred files can leave that question unanswered. One well-supported record can make the answer plain.

Start with the requirement someone can check. “The portal is complete” leaves too much room for interpretation. “An authorized user can submit a request, leave the session and return to find the saved request” gives the reviewer something to observe. The record should identify the agreed requirement before presenting the evidence. Otherwise the person doing the checking has to infer the promise from whatever happens to be in the folder, and the test quietly becomes easier than the purchase.

Consider a fictional training portal. Its delivery package includes an application file, a screenshot of a completed request and a report saying the checks passed. A useful acceptance record would connect those items to the version tested, the environment, the user's role, the steps taken and the result after the request was reopened. If the requirement also says one department must not see another's records, that needs its own relevant check. A successful submission does not answer the access question.

Give each piece of evidence a precise job. A screenshot can show what appeared on a screen at a particular moment. A saved result can support a claim about persistence. A file digest can help detect whether a file has changed. That last purpose is how NIST describes the hashes in its Secure Hash Standard. Comparing a file against a trusted recorded digest helps establish that the reviewer has the expected bytes. It does not establish that those bytes contain working software or an accurate report.

This is why an inventory, however carefully checked, has a limited role. A manifest can list the expected files and their digests. Checking it can reveal a missing file or a mismatch. The result is valuable: the delivery package is accounted for. The claim that a user can complete the required task still needs an observation of that task. The record gets stronger when each check states its actual reach.

Keep the identities connected. Software has several identities during delivery: the source revision, the built package, the release put into an environment and the version actually observed there. Recording the relationship prevents a passing result from drifting onto a different release. The SLSA provenance specification addresses one part of this problem by describing information about where, when and how software artifacts were produced. A buyer also needs the link from the delivered artifact to the environment and behavior being accepted. Provenance and operational evidence answer different questions along the same path.

Put the limits beside the conclusion. If the training portal was checked with synthetic records in a test environment, say so where the result is stated. If notification delivery was outside the check, keep that exclusion visible. If a required scenario failed, retain the result and its effect on the decision. A qualification buried in an appendix will disappear from the next status report. A qualification attached to the acceptance statement has a better chance of surviving it.

The record should also distinguish the person who performed the check from the person authorized to accept the work. Those may be different people. A test result contributes evidence; the acceptance decision applies the agreed criteria and records the disposition of any exceptions. Keeping both names and dates makes it possible to follow the decision without asking the supplier to reconstruct the meeting from memory.

This does not require an enormous document. A short record can carry the requirement, the exact delivery, the observation, the evidence location, the limits and the decision. The supporting material can sit behind it with appropriate access. Its value comes from the connections. When something changes, those connections let the next reviewer identify which conclusions need to be checked again.

For an institutional buyer, that is useful long after the project closes. For a supplier, it makes the boundary of the delivered work defensible. Both should be able to read the same record and say: this is what we accepted, this is why, and this is what the acceptance did not cover.