Rollback

Rollback returns a deployed system or selected component to a previously retained version as part of recovery. It is useful only if the chosen version can still operate correctly with current data, interfaces, and access requirements.

An older model is not a complete recovery plan

Suppose an assistant's new release produces invalid order-service requests. Restoring an old prompt may help, but only if that prompt matches the current tool contract. Restoring an obsolete policy index could introduce a different error. Identify the faulty change and select a compatible recovery target.

Retain the required artifacts and configuration, test the switching procedure, and verify the version actually handling requests after the change. Repointing an alias is insufficient if running processes keep their previously loaded model.

Past actions remain past actions

Rollback does not unsend a message or reverse an already accepted order. Investigate those outcomes separately and apply authorized corrective or compensating actions when appropriate.

If a database change cannot be reversed safely, a forward fix or temporary suspension may be preferable. Recovery success means the service again meets the relevant requirements, not merely that a deployment command reported success.

Reference: Google SRE: Canarying Releases.