Start with the change, not the button.
An approval screen should let the reviewer answer: which installation changes, what is running now, what will run next, which data may be affected and when execution is permitted? If those facts are still moving, the plan is not ready for approval.
Use stable identifiers for the destination and release content. Display human-readable names too, but do not make a display name the security boundary. A server named “production” can be rebuilt; an image tag can point at different content later.
A minimum review record.
- Destination: customer, application, installation and enrolled engine identity.
- Change: starting state, target release and exact plan identifier.
- Impact: expected interruption, storage effects and migration behavior.
- Recovery: required snapshot, who holds its key and which recovery procedure applies.
- Authority: approver identity, approval time and the permitted execution window.
Keep the review concise enough to use. Link to detailed release notes and recovery instructions rather than hiding critical facts in a long legal-style confirmation.
Bind permission to the reviewed plan.
If the image content, destination or requested operation changes after approval, create a new plan and ask for a new decision. Do not reuse an old approval because the marketing version number stayed the same.
A window also has meaning. Execution outside it should require valid authority, not a casual retry. Define how an operation that has already started is recorded when a connection fails or the window expires; do not confuse a UI timeout with proof that the host stopped.
Preparation is not consent.
A customer might download a release to inspect it, stage a large image before a maintenance window or install management software days before the first update. None of those actions should silently approve the application change.
In Shipstead, release acceptance and customer approval are distinct stages. The vendor then signs the approved execution. This creates more deliberate steps than a one-click deploy, but it makes the authority being granted inspectable.
Make “not yet” a normal outcome.
Customers need to delay a change when a host is unhealthy, a backup cannot be inspected or a migration is unclear. A workflow should preserve the reason and the current application state. Do not manufacture urgency merely because a new release exists.
When testing onboarding, ask a person unfamiliar with the system to identify what they are approving and what would invalidate that approval. If they cannot explain it from the screen and written instructions, improve the information before shortening the flow.
Keep the receipt with the operation.
Store the reviewed plan, signed intent, approval and execution result together. For an interrupted operation, reconcile that record with host evidence. A fresh approval for a second operation is not a substitute for determining what the first operation actually did.
Read Shipstead’s authority boundaries for the implementation model and release status for the independent checks that remain.