#### Day 36 — Separate identity readiness, artifact integrity and the business target **Learning task.** Select a recovery candidate using the current approved service state rather than the most reassuring artifact label. Recovery involves several independent predicates: the copy has expected bytes; its contents represent the desired transaction history; the application can use it; identity dependencies function through permitted paths; and the owner accepts the tested outcome. None of these predicates implies all the others. A successful backup digest comparison can coexist with a harmful whole restore. First advance the case in order. **C25**, released 10:11, records a distinct 10:08 identity/service-owner approval to remove the unapproved recovery method, make a scoped credential change and revoke `s-77`. The authorized identity operator reports completion at 10:10; a fresh IdP status query at 10:11 finds **s-77 inactive**. Separate operation report from status observation. The specific method/session work does not establish that every other session, recovery option or copied credential is absent. Nor does it establish that the legitimate scheduled job can use its updated authentication path. That service dependency needs its own check; undoing the credential change to make a failed restart work would require a new decision. Next inspect **C26** at 10:12: the documented 08:30 snapshot matches the supplied digest baseline, and an isolated read shows S40/S41/S42 all `open`. The scoped current values are S40/S41 `reserved`, S42 `unavailable`; the owner target retains the valid reservations and sets S42 `open`. The later legitimate S40/S41 work changes the restore decision. The digest cannot decide which transactions should survive. A comparison also needs the named baseline and source context: an equal hash does not independently authenticate the source, prove capture completeness or turn a stale business state into current intent. **Worked comparison.** Whole snapshot restore would correct the supplied S42 value while undoing two approved reservations. Do-nothing retains S40/S41 but leaves the current S42 problem. Targeted reconciliation is therefore the preferred **candidate in this scoped comparison**: change S42 toward owner-approved intent, preserve correct slots and test the application transaction. It still needs a fresh version precondition, evidence preservation, isolated route/audit checks, production authority and rollback. Do not generalize this into “small writes are always safe.” A real enrollment transaction may update capacity, reservations, retry state, audit and notifications together; a raw single-field edit could violate those invariants even while the three visible values look right. **Contrast.** “The hash matches, so restore everything and mark access clean” combines a byte comparison with two unsupported conclusions. C26's intact copy is the wrong whole-business target, and C25's one-session result does not close identity discovery. The correct ledger lists copy validity, candidate value differences, business authority, service/authentication checks and unresolved source coverage separately. The snapshot remains useful as a preserved reference; rejecting wholesale use does not mean rejecting backups. **Offline practice and result.** Run §8.3 unchanged. Its first line names `S40:open->reserved, S41:open->reserved`; its second names `S42:unavailable->open`. These are differences from the supplied target, not a list of authorized commands or all database discrepancies. On paper, add permission, service cost, rollback dependency and unknowns for each candidate. Explain why snapshot age is not automatically lost-transaction duration when later valid changes are preserved by reconciliation. **Limits and decision.** At 10:12 there is no C27 test result, production approval or completed restart. Submit [EX036](#exercise-ex036) and compare the [worked answer](#answer-ex036). Carry a conditional candidate and explicit acceptance criteria to the next lesson; do not carry a restoration receipt that does not exist. [Previous: Week 7, Day 35](#week-07-day-05) · [Week 8 index](#week-08-index) · [Course index](../SUBJECTS.md) · [Next: Day 37](#week-08-day-02). ### Exercise for this lesson **EX036 — Candidate comparison.** Objective: distinguish specific identity readiness, artifact integrity and business correctness. Inputs: C13/C25/C26 through 10:12 and Day 36. Compare whole snapshot, do-nothing and targeted reconciliation across S40/S41/S42, service/authentication dependencies, authority, version and rollback. Record C25 approval/report/status separately and its discovery limit. Explain why matching bytes and snapshot age do not prove correct business target or actual data loss; no later test or production receipt is available. Rubric: 0 = full restore justified by hash alone, invented identity closure or operation; 1 = correct three candidates but incomplete source/authority/service limits; 2 = scoped target/loss ledger and conditional reconciliation with independent identity checks. [Worked answer](#answer-ex036). ## Worked answers **EX036 — Model candidate comparison.** Whole 08:30 snapshot: integrity is checked, S42 becomes `open`, but S40/S41 would also become `open`, overwriting later approved reservations; service owner must reject that candidate as currently specified, even if a recovery operator could technically apply it. Do nothing: S40/S41 remain correct, but S42 stays `unavailable`, so the user-facing problem persists. Targeted reconciliation: proposed S42 `open` with S40/S41 preserved as `reserved`; requires service-owner target approval, an isolated two-route/audit test, recorded current version, production change approval and rollback. Its key remaining uncertainty is whether the audited application behaves identically in production. This does not mean backups are useless: the C26 copy helps establish prior values and a recovery fallback, but is not the whole-business target. **Additional professional worked reasoning:** Compare all three slots with the approved target, not only S42. A whole 08:30 snapshot reopens S40/S41 and would regress accepted reservations; do-nothing preserves them but leaves S42 unavailable. A targeted S42 correction is merely the preferred **candidate**, requiring owner-approved atomic version precondition, staged service/audit tests and rollback. Source correctness and timestamp age do not by themselves establish no lost data. **Week 8 Day 36 — worked identity/candidate boundary.** C25 records 10:08 owner approval, 10:10 identity operation report and 10:11 s-77 inactive status, not universal identity closure or a completed new-credential batch test. C26 supplies an intact 08:30 snapshot with all slots open, current S40/S41 reserved and S42 unavailable, and the owner target retaining the reservations while opening S42. Whole restore regresses accepted work, do-nothing retains the current S42 defect, and targeted reconciliation remains a candidate subject to version, authorized transaction path, audit/service gate and rollback. No digest value, data-loss duration or later test is invented. Scope the source and business authority separately from byte consistency.