next chapter

diagrams/plantuml/rollback-policy.puml

@@ -0,0 +1,52 @@
+@startuml
+title Ordinary rollback policy after a failed system update
+skinparam shadowing false
+skinparam monochrome true
+start
+:Save failed release, reason, retry block,
+recovery intent and finite budget;
+:Exclude competing installation;
+if (Rollback window open and
+target eligible?) then (yes)
+  if (Recovery boot budget remains?) then (yes)
+    if (Current data usable by A?) then (yes)
+    else (no)
+      if (Valid compatible backup and
+restore explicitly authorized?) then (yes)
+        :Restore through the defined recovery procedure;
+        :Retain any data-loss result;
+      else (no)
+        :Save failure; enter separate recovery policy;
+        stop
+      endif
+    endif
+    :Boot control saves consumed attempt
+and selects A before handoff;
+    if (A reaches checks and passes
+within the deadline?) then (yes)
+      :Save recovery success and pending report;
+      :Retain failed-release block;
+      stop
+    else (no)
+      :Explicit check failure goes to separate recovery;
+      :Failure to reach checks uses reset path
+and remaining saved budget;
+      :Budget exhaustion goes to separate recovery;
+      stop
+    endif
+  else (no)
+    :Save exhausted budget; enter separate recovery;
+    stop
+  endif
+else (no)
+  :Save ineligible target; enter separate recovery;
+  stop
+endif
+legend bottom
+  Target eligibility includes artifacts, shared components, configuration,
+  recovery-state compatibility, and permission under security policy.
+  Early boot recovery relies on the contract established before trial.
+  A backup restore before A boots requires a capable recovery environment.
+  This diagram describes policy, not storage atomicity or a rescue implementation.
+endlegend
+@enduml

diagrams/plantuml/rollback-recovery-sequence.puml

@@ -0,0 +1,46 @@
+@startuml
+title Recovery coordination and restart after boot handoff
+skinparam shadowing false
+skinparam monochrome true
+participant "Recovery supervisor" as Supervisor
+database "Recovery journal" as Journal
+participant "Data recovery procedure" as Data
+participant "Boot control" as Boot
+participant "Retained system A" as A
+
+Supervisor -> Journal : Save failed release, reason, block,\nrecovery intent and reporting obligation
+Supervisor -> Supervisor : Exclude installs; establish target eligibility
+opt Approved compatible backup needed
+  Supervisor -> Data : Restore under its interruption contract
+  Data --> Supervisor : Compatible data; loss accounting
+  Supervisor -> Journal : Save completed restore and data-loss result
+end
+Supervisor -> Boot : Request recovery boot of A
+Boot -> Boot : Save selection and consumed recovery attempt
+Boot --> Supervisor : Saved state / request result
+... reset can occur before supervisor saves progress ...
+Boot -> A : Handoff under saved boot state
+A -> Supervisor : Start local recovery coordinator
+Supervisor -> Boot : Read authoritative selection and budget
+Boot --> Supervisor : A selected; attempt already consumed
+Supervisor -> Journal : Reconcile progress; do not replenish budget
+Supervisor -> A : Check required local functions with deadline
+alt Checks pass
+  A --> Supervisor : Healthy
+  Supervisor -> Journal : Save recovery success, running release,\ndata loss and pending report; retain block
+else Checks fail
+  A --> Supervisor : Failed
+  Supervisor -> Journal : Save recovery failure
+  Supervisor -> Supervisor : Enter separate recovery policy
+end
+note over Boot,A
+  If A cannot reach checks, the reset path and saved budget
+  bound further boots. Exhaustion enters separate recovery.
+end note
+note over Supervisor,Data
+  Supervisor available here is an assumption. If restoration must
+  precede A's startup, a capable recovery environment must perform it.
+  Each component needs its own durable write and restart contract.
+  The sequence is not one transaction. Reporting may remain offline.
+end note
+@enduml

diagrams/plantuml/rollback-window.puml

@@ -0,0 +1,43 @@
+@startuml
+title Example rollback window across a release lifecycle
+skinparam shadowing false
+skinparam monochrome true
+participant "Release lifecycle" as Release
+participant "Rollback policy" as Policy
+participant "Shared data" as Data
+participant "Slot A" as A
+
+Release -> Policy : Admit B's trial; retain eligible A
+Policy -> A : Preserve A and matching artifacts
+Policy -> Data : Require A/B-compatible reads and writes
+note over Policy,A
+  Rollback window open during trial.
+end note
+Release -> Release : B passes local checks
+Release -> Policy : Confirm B
+note over Policy,Data
+  Confirmation accepts B. It does not itself prove that later
+  data changes remain compatible or define a retention period.
+end note
+opt Product promises rollback after confirmation
+  Policy -> A : Continue retaining eligible A
+  Policy -> Data : Continue preserving A compatibility
+end
+Release -> Policy : End promised rollback period
+Policy -> Policy : Durably close A's rollback window
+note over Policy,A
+  If closure is interrupted, never infer an open window
+  after its prerequisites have been removed.
+end note
+opt Incompatible migration required
+  Release -> Data : Migrate under a separate recovery procedure
+end
+opt A becomes the target of a later update
+  Release -> A : Reuse under the next update's admission policy
+end
+note over Policy,A
+  A is no longer promised as an ordinary recovery choice.
+  Separate recovery and security policy still apply.
+  Closure, migration, and slot reuse are distinct events.
+end note
+@enduml

diagrams/readme.md

@@ -1,14 +1,17 @@
 # OTA diagrams
 
-PlantUML sources accompany chapters 03–06. The diagrams describe the example A/B design, not a required platform or partition table.
+PlantUML sources accompany chapters 03–07. The diagrams describe the example A/B design, not a required platform or partition table.
 
 | View | Source | Preview |
 |---|---|---|
 | Roles and the server/device boundary | [PlantUML](plantuml/ota-architecture.puml) | [PNG](rendered/ota-architecture.png) |
 | Trial boot, confirmation and recovery | [PlantUML](plantuml/ab-trial-boot.puml) | [PNG](rendered/ab-trial-boot.png) |
 | Storage areas and access responsibilities | [PlantUML](plantuml/ab-storage-layout.puml) | [PNG](rendered/ab-storage-layout.png) |
-| Preparation and activation sequence | [PlantUML](plantuml/ab-installation-sequence.puml) | Source only |
-| Installation states and restart decisions | [PlantUML](plantuml/ab-installation-recovery.puml) | Source only |
+| Preparation and activation sequence | [PlantUML](plantuml/ab-installation-sequence.puml) | [PNG](rendered/ab-installation-sequence.png) |
+| Installation states and restart decisions | [PlantUML](plantuml/ab-installation-recovery.puml) | [PNG](rendered/ab-installation-recovery.png) |
+| Rollback eligibility and recovery decisions | [PlantUML](plantuml/rollback-policy.puml) | [PNG](rendered/rollback-policy.png) |
+| Recovery coordination and restart | [PlantUML](plantuml/rollback-recovery-sequence.puml) | [PNG](rendered/rollback-recovery-sequence.png) |
+| Rollback window and release lifecycle | [PlantUML](plantuml/rollback-window.puml) | [PNG](rendered/rollback-window.png) |
 
 From the repository root, regenerate previews with a local PlantUML installation and Graphviz:
 
@@ -16,4 +19,4 @@ From the repository root, regenerate previews with a local PlantUML installation
 JAVA_TOOL_OPTIONS=-Djava.awt.headless=true plantuml -tpng -o ../rendered diagrams/plantuml/*.puml
 ```
 
-Chapters 03–05 include existing previews. The chapter 06 diagrams are provided as sources only; generate previews locally when needed. No external rendering service is needed. These diagrams do not establish power-loss safety. The [A/B simulation](../examples/simulations/ab-trial-boot/readme.md) covers trial boot. The [interrupted installation model](../examples/simulations/interrupted-installation/readme.md) covers preparation, old progress, and supplied boot-record write outcomes.
+Chapters 03–07 include PNG previews alongside their editable PlantUML sources. No external rendering service is needed. These diagrams do not establish power-loss safety. The [A/B simulation](../examples/simulations/ab-trial-boot/readme.md) covers trial boot. The [interrupted installation model](../examples/simulations/interrupted-installation/readme.md) covers preparation, old progress, and supplied boot-record write outcomes. The [rollback policy simulation](../examples/simulations/rollback-policy/readme.md) covers recovery eligibility, data loss, bounded attempts, and failed-release blocks.