# Done-Test

**Template, version 2.** The done-test is the contract: an objective, demonstrable definition of "done" that both sides sign before a fixed price exists. It is what the money-back guarantee pays out against, so it is written to be binary.

Keep this core short. Rows specific to what you are building come from the [check libraries](https://mangrove.co.uk/done-test#libraries): web application, front-end and design, AI agents, bots, standalone applications, data and integration. Take the rows that apply, delete the rest.

## The rules (read before writing)

1. **Every check must be demonstrable, and the evidence named.** Acceptable evidence is a live demo, a CI run, a recorded drill, a metrics or billing dashboard, or a third-party report. If nobody can say how a check would be shown, it cannot be in the done-test.
2. **Binary, not adjectival.** "Fast", "easy", and "intuitive" are banned; write the number instead ("search returns in under 500ms at 10,000 records").
3. **Client-dependent checks name their input and date.** A check waiting on something from your side is blocked, not failed; blocked items are completed late, waived in writing, or severed at acceptance.
4. **Material run costs get an economics check.** If a feature costs money per use, the acceptable unit cost at production volume is a pass/fail row.
5. **Changes go through a written change request**, producing a revised price and done-test. Verbal additions are not scope.
6. **Ambiguity is a defect in the test, not a matter for negotiation later.** If a check could be argued either way on the day, it was not objective enough to sign. Rewrite it before signing, not after.
7. **Both sides sign**, and every revision is logged at the end of this document.

## What happens when a check misses

Agreed before signing, so nobody is negotiating it at the demo.

| Situation | What happens |
|---|---|
| A check fails at the demo | Fixed at our cost until it passes. Cure comes first; the refund is for the case where it cannot be cured. |
| A check is blocked on a client input named in the table | The clock pauses. At acceptance it completes late, is waived in writing, or is severed from the assessment. |
| Delivery cannot reach the signed done-test | That stage's fee is refunded in full, and that stage's work, code and IP revert. Prior accepted stages are untouched. |
| Something is wanted that is not in the table | Written change request, revised price, revised done-test. |

## Conditions of the demo

Fill this in. Half of all acceptance arguments are about the conditions rather than the checks.

| | |
|---|---|
| Environment the demo runs in | |
| Data used (and how representative of production) | |
| Acceptance window after the demo | |
| Who attends and who signs | |

## Functional checks

| ID | Check (demonstrable statement) | Evidence | Depends on (input + date) | Pass |
|---|---|---|---|---|
| F1 | A user can [action] and sees [result] | Live on staging | none | |
| F2 | | | | |

## Quality gates

| ID | Check | Evidence | Pass |
|---|---|---|---|
| Q1 | Automated tests exist for the functional checks above and run in CI on every commit | CI run shown live | |
| Q2 | Security scanning (SAST + dependency scan) runs in CI with no unresolved critical findings | CI output shown | |
| Q3 | Documentation covers setup, deployment, and operations | Repo walkthrough | |

## Non-functional checks

Delete any line that does not apply to this build, and put a number in every line that does. These are the four hardening layers a production-grade delivery is scoped against; the ones you keep are the ones you are buying.

| ID | Check | Evidence | Pass |
|---|---|---|---|
| N1 | [Operation] completes in under [N] at [volume], measured at p95 rather than mean | Timed live | |
| N2 | System sustains [N] concurrent users with error rate under [X]% | Load-test output | |
| N3 | Availability target of [N]% over the warranty period, measured by [monitor] | Monitoring dashboard | |
| N4 | A failure is visible without a customer reporting it: [named alert] fires within [N] minutes and reaches [named recipient] | Alert triggered live | |
| N5 | A backup taken today restores to a working system within [N], losing at most [N] of data | Recorded restore drill | |
| N6 | Meets WCAG 2.2 AA on the primary journey, with zero critical axe findings and the journey completable by keyboard alone | Audit output + live keyboard walkthrough | |
| N7 | [Feature] unit cost at [volume] is at or under [£X per unit] | Billing or metrics shown | |

## Compliance checks (where applicable)

| ID | Check | Evidence | Pass |
|---|---|---|---|
| C1 | Personal data flows match the data map; retention and deletion work as documented | Live walkthrough | |
| C2 | Every third party that receives personal data is named, with its purpose and legal basis recorded | Sub-processor list | |

## Handover checks

H2 is the one that decides whether you own the system or merely possess it. Do not delete it.

| ID | Check | Evidence | Pass |
|---|---|---|---|
| H1 | Client holds source, documentation, and deploy access | Access verified live | |
| H2 | A named engineer on the client side, who did not build it, clones the repo, runs the test suite, makes a trivial change and deploys it to staging, unaided, working only from the written documentation | Performed live by that engineer | |
| H3 | Every credential, key and account used in the build is held by the client and rotated at handover | Access verified live | |

## Sign-off

| | Client | Mangrove |
|---|---|---|
| Name | | |
| Date | | |
| Version of this done-test | | |

## Revision log

Every change to a signed done-test is recorded here, with the change request that caused it.

| Version | Date | What changed | Change request ref |
|---|---|---|---|
| 1 | | Original signed version | n/a |