How do team-owned automated acceptance checks differ from a business user acceptance sign-off?

### Two owners, two questions Inside the acceptance level there are two very different activities that share a name, and the interview question is really about telling them apart. **Team-owned automated acceptance checks.** Written by the delivery team, living in the same repository as the code, executed on every build. Each one corresponds to a stated criterion. Their question is narrow: *do the agreed criteria still hold?* Because they are cheap to repeat, they double as regression protection at the requirement level -- if someone later changes the archive path in a document e-signing flow, the check for "every signer receives a countersigned copy" fails on the build, not in a meeting three weeks later. **Business user acceptance sign-off.** Performed by the people accountable for the requirement -- the sponsor, the operating department, sometimes selected end users. Their question is broad: *is this fit for us to use?* It is a judgement, made once per release, against a specific build, and it can legitimately fail on something that no criterion mentioned: the wording is legally wrong for one jurisdiction, the flow needs six clicks where the old one needed two, the counter-signature ordering is unusable for their approval chain. ### The two ways this goes wrong The first failure is **the rubber stamp**. Business users are handed a script that walks the same 27 criteria the automated run already checked. They click through it, find nothing (of course -- a machine verified it an hour ago), sign, and everybody records that acceptance happened. The organisation now pays for the ritual and receives none of the judgement, and worse, the participants learn the exercise is pointless and delegate it downward until it is done by someone with no authority to reject anything. The second failure is **automation as sign-off**. The automated run is green, so the change ships. But every one of those checks was written from the same criteria, by the same team, with the same understanding. If the criterion itself was wrong -- if "notify the signer" was implemented and agreed as an in-product notice when the department needed a mailed copy for their records -- nothing in the pipeline can discover it. Automated checks are self-consistent by construction; they cannot audit their own premises. ### Dividing the work deliberately The useful split follows from the two questions: - **Automate everything enumerated.** Every criterion that can be stated as an observable outcome goes into the team-owned run and stays there forever, so it is checked on build 4471 and on every build after. - **Spend human sign-off on what was never written down.** Give the business owner the build, the list of what the automated run already proves, and time to try their real work: their documents, their approval chains, their awkward cases. Ask them explicitly for what is missing rather than for confirmation of what is present. - **Feed findings back into the criteria.** When a sign-off rejects something the automated checks pass, the outcome is a *criteria* change: amend or add the criterion, add the corresponding automated check, and note why it was missed. This is the loop that makes the level improve instead of repeating. ### The record matters as much as the activity A sign-off that does not name the build it applies to is worthless, because the build ships changed. The minimum record is: build identifier, the criteria set and its version, the automated run result, what the human reviewers exercised, who accepted, and when. That record is what lets you answer, months later, whether the behaviour now in production is the behaviour someone approved. ### A worked example of the gap In an e-signing rollout, all 27 criteria pass automatically. During sign-off the operations lead tries a real case: a round is abandoned midway with two of three signatures collected. The product voids the round and discards the partial signatures -- a partial-failure rollback the team chose sensibly and nobody had written down. For this department that is unacceptable: their counterparties will not re-sign, and they need the partial state preserved for 30 days. No automated check could have found this, because the behaviour matched every written criterion. That is precisely the value the human sign-off exists to add, and it only appears if the reviewer was asked to use the system rather than to re-walk the checklist. ### Saying it crisply in an interview "Automated acceptance checks tell me the agreed criteria still hold on this build; sign-off tells me the business is willing to take it live. I automate every criterion so the sign-off never spends its attention re-checking them, and I treat anything the sign-off rejects as a defect in the criteria, not just in the code."