next chapter

adr/ADR-020-define-rollback-eligibility-and-retention.md

@@ -0,0 +1,56 @@
+# ADR-020: Define Rollback Eligibility and Retention
+
+## Context
+
+An A/B device retains A while trying B. Keeping A's bytes does not guarantee that A can still run: shared data, configuration, boot components, or security policy may have changed. Confirmation and later slot reuse also affect what the product can promise.
+
+The reference design needs local recovery without downloading the old release. Boot control and Linux must understand the retained recovery state.
+
+## Decision
+
+Define an explicit rollback window and the conditions that make its target eligible. Retain the target release, matching boot artifacts, required dependencies, verification information, and a supported data path for that window. Record release identities and the window state outside replaceable software.
+
+Admit a trial only when its permitted operations preserve the early-boot recovery path. The eligibility contract covers artifact validity, shared components, configuration, data, recovery-state formats, and the platform's security policy. Reassess these conditions before a supervisor initiates recovery where possible. Early boot recovery must rely on a contract established before trial, not on checks that require the failed Linux system.
+
+Confirmation alone neither guarantees nor closes a post-confirmation rollback window. The product must state whether such a window exists. Save its closure before an incompatible change or slot reuse removes the promised recovery path. An interrupted closure may conservatively leave rollback unavailable; it must not leave a promise to use a removed target.
+
+If eligibility cannot be established, stop ordinary rollback and use the separate recovery policy. Check essential functions after starting the retained release before reporting success.
+
+## Alternatives Considered
+
+### Treat Any Retained Slot as Recoverable
+
+Simple, but ignores shared data and changes outside the slot. The slot may boot while the application remains unusable.
+
+### Keep Every Previous Release Indefinitely
+
+This needs more storage and still does not preserve compatibility or permission to run old software.
+
+### Download Recovery Software When Needed
+
+This can supplement local recovery, but cannot satisfy this design's offline requirement.
+
+## Consequences
+
+### Positive
+
+- The recovery promise has an explicit lifetime and prerequisites.
+- Cleanup and migrations cannot silently invalidate a retained target.
+- Confirmation, data compatibility, and slot retention can be reviewed separately.
+
+### Negative
+
+- Retained artifacts and compatible data consume resources.
+- Releases must maintain compatible recovery-state formats during the window.
+- Closing the window may require an alternative recovery path.
+
+## Applicability and Limits
+
+Use when a product promises a return to retained software. This decision defines policy, not an artifact verifier or a durable journal implementation. Hardware failure and damaged shared boot components need separate recovery support. Security policy can prohibit an otherwise operational old release.
+
+## Related Documents
+
+- [Chapter 07: Rollback and Recovery](../docs/07-rollback-and-recovery.md)
+- [ADR-014: Trial Boot and Confirmation](ADR-014-trial-boot-and-confirmation.md)
+- [ADR-017: Keep Recovery State Outside Replaceable Software](ADR-017-keep-recovery-state-outside-replaceable-software.md)
+- [ADR-021: Preserve Data Compatibility During Trial](ADR-021-preserve-data-compatibility-during-trial.md)