Acceptance for a regulated release: how do you satisfy a business sponsor's sign-off and an external regulator's evidence needs at once?

### The real question This is a design question about **who the evidence is for**, and it has no single right answer -- which is why it is asked of leads. Three audiences want something from the acceptance level: - The **delivery team** wants fast, repeatable confirmation that agreed criteria still hold, on every build. - The **business sponsor** wants a judgement that the release is fit to take live, made once, on a named build. - The **regulator** wants to see that a stated requirement was translated into criteria, that those criteria were exercised against the version that actually went live, and that the record still exists years later. They are not in conflict about *what* is true; they differ in the form of proof and how long it must survive. ### The failure mode to design against The common outcome is **three parallel acceptance efforts**: the team's automated run, a business walk-through, and a separately authored validation pack written for the external audience. They start from the same requirement and drift, because they are maintained by different people on different rhythms. Six months later the three describe subtly different systems, and the discrepancy is itself the audit finding -- worse than having had one thinner effort. So the design goal is: **one criteria set, one execution, several views of the evidence.** ### What that looks like concretely **Give every criterion an identity and a version.** Criteria carry stable identifiers and are versioned with the requirement. Traceability then falls out: requirement to criterion to executed check to result to release. Without identifiers, traceability becomes a person maintaining a spreadsheet, which is where regulated programmes sink time. **Make the evidence a by-product of the run, not a document written afterwards.** The automated acceptance run should emit, for each criterion: identifier, build identifier, observed result, timestamp, and the environment descriptor. A record generated by the run cannot drift from the run. A pack typed up afterwards always can, and everyone knows it. **Decide explicitly what must be human-witnessed.** Some things genuinely need a person: a judgement about wording that carries legal weight, a check that a document a counterparty receives is the document they were meant to receive, an interpretation of an ambiguous obligation. Name those, keep them few, and let everything enumerable be machine-evidenced. Do not let the human list grow by default, because attention spent re-walking automated criteria is attention not spent on judgement. **Establish what form of evidence the regime accepts, early.** Whether automated records satisfy a given regulator, and under what controls, varies by regime and by inspector, and this is genuinely contested ground -- some regulated sectors have long accepted automated evidence with change control over the checks themselves; others still expect witnessed execution. Find out before you build the pipeline around an assumption in either direction. The expensive mistake is discovering in an audit that your evidence is not the kind they wanted, and the equally expensive one is defaulting to manual ceremony that was never actually required. **Plan the re-run scope.** In a regulated setting, the instinct is to re-execute everything for every change, and for a release of any size that is unaffordable. The defensible position is a stated, written rule: which criteria are re-executed for which class of change, based on impact analysis, with the rule itself reviewed. That is arguable in front of an inspector; "we ran what we had time for" is not. **Plan retention.** Evidence must outlive the pipeline that produced it. If the records live only in a build system with 90-day retention, the obligation is unmet the moment it matters. Decide retention duration, storage and immutability up front, and keep the build artefacts referenced by the evidence for as long. ### The sponsor's half None of this substitutes for judgement. Give the sponsor the build, a plain statement of what the automated run already proves, and real work to try -- and ask for what is *missing*. In a document e-signing rollout, that is how you learn that a partial-failure rollback which voids a round after 2 of 3 signatures is unacceptable to the department, because their counterparties will not re-sign: a behaviour that met every written criterion and every regulatory obligation and was still wrong. The sign-off names the build, and if the build changes, the signature does not travel with it. ### Tradeoffs to state out loud Heavier evidence slows release cadence, and slower cadence means larger, riskier releases -- so evidence weight is not free safety, it is a trade. Freezing a criteria set to keep the paperwork stable is how criteria stop describing the system. And a signature obtained under time pressure at the end of a release is worth very little regardless of how much documentation surrounds it. A strong answer names these tensions rather than presenting the design as cost-free.