# Prepare a rollback after irreversible data change

Illustrative planning brief; no automatic product import.

Illustrative planning case: A release rewrites stored identifiers so the prior binary can no longer interpret new records.

## Decision

Expose the data rollback limit before approving deployment.

## Owned work

- Identify irreversible writes
  - Owner role: Release investigator
  - Acceptance evidence: The migration changes identifier representation in 800 records.
- Evaluate recovery options
  - Owner role: Migration engineer
  - Acceptance evidence: Restore forward repair and compatibility adapter are compared.
- Review release boundary
  - Owner role: Release reviewer
  - Acceptance evidence: The plan names the point after which binary rollback is unsafe.

## Workflow

1. Identify the first write that changes identifier representation and the readers affected by mixed records.
2. Rehearse restore or forward repair on a fixture and record duration, losses and compatibility assumptions.
3. Have the release reviewer accept the recovery boundary before deployment; hold when the proposed recovery route remains untested.

## Judgment

Hold release if no reviewed recovery route exists.


## Filled illustrative release coordination record

In the synthetic plan, the old binary is safe until the first rewritten identifier is committed. After that, recovery requires a verified restore or forward repair. The release note states this boundary and postpones deployment because restore duration is untested. A familiar rollback command does not establish rollback safety after data meaning changes.
Decision: Expose the data rollback limit before approving deployment.
Review boundary: Hold release if no reviewed recovery route exists.
This example uses synthetic conditions. Replace its observations with project evidence and record any changed assumptions before adopting the plan.


## Working artifact

- Old reader mismatch / Prior binary rejects rewritten ID / Prevent binary-only rollback after rewrite
- Untested restore / Recovery duration lacks trial evidence / Rehearse before release decision
- Partial rewrite / Mixed identifiers remain possible / Define forward repair for both forms


## Workflow questions

### Is retaining the old artifact sufficient?

No. Its readers must understand the data state that will exist when rollback is attempted.

### What makes an irreversible boundary reviewable?

A concrete triggering write, affected population and tested recovery options with their unresolved limits.

## Product connection

Use the manual work brief to discuss task ownership, review evidence and next actions in TeamBoost. Release execution remains a separate project workflow; the download performs no deployment or import.

Confirm account availability before adopting this manual outline.


## Choose recovery at the actual data boundary

This synthetic release distinguishes binary recovery from data recovery.

### Before identifier rewrite

Next action: Use the reviewed compatible binary recovery procedure.

Evidence to revisit: Confirm no incompatible records were written.

### After identifier rewrite

Next action: Use the verified restore or forward-repair route.

Evidence to revisit: The old reader cannot safely consume the new representation.

### Recovery not rehearsed

Next action: Hold deployment and gather recovery evidence.

Evidence to revisit: Duration, loss boundary and mixed-record behavior remain unresolved.