A release with a way back.

What would make the next change understandable, observable and reversible?

1. Define the intended change, its boundary and the evidence that will show whether it behaves as expected.
2. Establish a baseline, verify the candidate and describe the conditions for continuing or stopping.
3. Plan recovery before release, including the limits of rollback and the checks needed after returning to the previous state.

1. Teaching example: a release adds a required field to stored records.
2. Before release: check whether the old application can still read records written by the new version. A successful deployment alone does not answer that question.
3. Safer sequence: add the field as optional, deploy code that can handle either shape, fill existing records, then consider making the field required.
4. Recovery limit: returning to the old application may not undo a data change. Describe how affected records would be found and repaired, and who makes the decision to stop.

A reviewable sequence with explicit preparation, verification, release, observation and recovery steps.