# Remozio plan review: revision 22 (full plan)

This review covers the plan text only. No testing, browsing, or source inspection was done.

## Finding 1: Medium. A restored audit journal can reuse sequence numbers inside an unchanged epoch

**Where:**
- §12 "Sync and offline cache"
- §12 "Atomic journal writes"
- §16 "Feasibility gate: restored trust state"

**Scenario:**
1. A Mac is restored from a Time Machine backup taken after its last trust change. No enrollment, revocation, floor, or policy change happened between the backup and the restore.
2. The §16 witness commits only to authority-relevant state, so it matches. Continuity is established, and no "restoration recovery" runs.
3. §12 creates a fresh journal epoch only through that recovery path. The restored journal therefore keeps the same epoch and rewinds its sequence counter.
4. The Mac writes new events under sequence numbers that phones have already cached with different event IDs.

**What goes wrong:**
- Phones either detect "changed records" and stall, or deduplicate inconsistently.
- The phone's cursor is ahead of the Mac's head.
- Signed batches with the same epoch and sequence range conflict.

The plan already lists these tests ("cursor ahead of a restored journal", "repeated sequence numbers"). It defines no detection mechanism for this case, because the only epoch trigger depends on a trust discontinuity.

**Minimal correction:**
- Make journal continuity its own trigger for a new epoch, independent of trust-state recovery.
- Require that no sequence number is ever reissued within an epoch.
- Start a new epoch, with reason "journal rollback detected", when either of these occurs:
  - an authenticated phone cursor or batch receipt exceeds or conflicts with the local head, or
  - the journal head is not covered by a protected commitment. This could reuse the §16 witness at coarse intervals, or record a per-boot epoch.
- Phones keep their conflicting old records under the existing "History discontinuity" label.

This grants no authority and adds no user step. It also does not affect replay safety: pending payloads stay memory-only, and the control replay state is already under the witness.

**UX impact:** None.

## Tentative UX choice, not a design defect

The migration ceremony for new hardware is in §3 "Key custody and pre-login transport" (see also the round-15 disposition).
- The plan correctly treats it as a user-choice gate with a design, disclosure, and consent path before implementation.
- A user question is outstanding and unanswered.
- Per §11, REVIEW-LOG.md should list it as a pending decision.
- Any option involving phone biometrics or a one-time ceremony during migration is a UX cost that needs explicit user approval.

The idle threshold and retention duration remain explicitly deferred preferences. They are not findings.

## Assessed without further findings

**Revision 22 key custody:**
- Device-bound, non-exportable authority and certifier keys.
- No file fallback for those keys.
- A clone test is included.

**Epoch-bound cursors after a restoration triggered by a trust discontinuity.**

**Consistency of earlier invariants:**
- Scope and biometric table.
- Decision-key purpose separation for routing and scheduling.
- Relay and gateway non-authority.
- Revocation serialization and tombstones.
- Candidate-token proof.
- Update quiescence and floor commit.
- Mixed-version contract selection without re-encoding.
- Restart matrix.

**Remote UX preservation:** No new confirmations, and approval windows are not shortened.

**Scheduled feasibility gates, not treated as defects:**
- Secure Enclave pre-login availability.
- Rollback witness.
- Single-biometric credential release.
- sudoers compatibility.
- Atomic execution.
- AX fixtures.
- Local command approval surface.

**Implementation verification limits:** These are platform facts the plan depends on and must still be proven.
- Non-exportability survives a real backup or migration.
- A monotonic witness exists that is compatible with offline operation.
- Old signed builds can be isolated from current receiving keys.
- Protected placement holds under Sparkle and SMAppService.
- Little Snitch and 1Password expose true once-only semantics.

**SUBSTANTIVE FINDINGS REMAIN**