A working guide from Beeston Labs. Version date: 8 November 2026.
Use this record before a first release or a material change. It brings together the evidence and operating conditions needed for the decision; it does not replace the underlying assessment.
Release record
System/use-case reference:
Proposed release or change:
Affected users, data and operating environments:
Business, technical and decision owners:
Planned release window and dependencies:
Review prompts
| Question | Evidence/answer | Open action and owner |
|---|---|---|
| Is the intended use still the use that was assessed? | ||
| Are the relevant legal, contractual and organisational requirements identified? | ||
| Does evaluation cover this configuration and operating scope? | ||
| Are known limitations visible to the people who need them? | ||
| Are data flows, permissions and retention settings understood? | ||
| Can the human reviewer perform the role expected of them? | ||
| Are monitoring and incident reporting assigned to named roles? | ||
| Can the system be restricted, disabled or rolled back? | ||
| What happens to actions or records already produced after a rollback? | ||
| Are supplier changes and unsupported versions tracked? | ||
| Are user instructions and support routes ready? | ||
| Is there a defined point for reviewing the initial release? |
Additional physical AI review
Confirm the intended operating environment, limits, relevant safety requirements and responsibilities. Link the evaluation to the actual sensors, host, accelerator and software configuration.
Identify the response to degraded inputs, loss of communications, late inference and system faults. Record how the relevant safeguards have been assessed and who has authority over the trial or release. Any unresolved safety issue needs a specific decision through the applicable safety process; this worksheet is not that sign-off.
Make the release decision explicit
Decision: release within the stated scope / limited trial / further work / do not release.
Permitted users, tasks and environments:
Conditions that must be in place before release:
Conditions to monitor during operation:
Remaining action, owner and deadline:
Decision owner, date and rationale:
Set change triggers
Review the impact of a new model or supplier, changed purpose, additional data access, new tools/actions, expanded user population, different territory, new hardware or a changed operating environment.
Not every update needs the full review repeated. The change owner should identify which assumptions and evidence are affected, then repeat the relevant assessment or tests. Record the reasoning even when the conclusion is that the change stays within existing limits.
Plan retirement
Decide how access will be removed, data handled, integrations disconnected and users informed. Retain the records the organisation needs to explain past decisions while applying its retention rules.
A system is not fully retired while an unmanaged scheduled task, connector or device continues to process information in the background.