# Independent review — Remozio plan, revision 20 (round 14)

Input reviewed: `reviews/round-14-plan.md` (revision 20, dated 2026-09-30) plus `reviews/round-13-disposition.md`. Plan-only review; no testing, browsing, or source inspection performed or claimed.

## What was assessed

Full plan, with priority on the post-revision-19 additions (the section 16 "Feasibility gate: restored trust state" and the restrictive rollback-evidence rules) and their cross-section interactions: revocation serialization (5/6), gateway control plane and tombstones (16), update/floor commit and rollback (17), negotiation and downgrade resistance (18), audit exclusions (12), routing/push coupling (14/15), command binding (8), biometric credential release (3/7), UI permit/scope-mutation atomicity (6/9).

## Assessment of the revision-20 additions

The restored-trust gate is a defined feasibility gate with required evidence (witness update/crash/backup/migration/reinstall semantics, offline continuity, rollback tests over LAN and relay with the gateway offline) and an explicit failure/consultation path. Per the review rules, that is planned work, not a defect. It is also internally consistent:

- **Restrictive-only direction.** Gateway evidence can suspend authority and mapping publication but cannot enroll or restore authority; a higher counter alone is inert without a Mac-signed receipt. Rollback of trust-changing state funnels to the existing independent administrator recovery, which does not require the old phone. Fail-safe.
- **No new denial-of-approval surface.** Revocation receipts are Mac-signed and originate locally ("Local revocation takes effect immediately"), so a replaying or hostile gateway cannot fabricate a revocation "missing locally" against a current trust history; replayed receipts the Mac already has are no-ops. Epoch binding on mappings and the surviving tombstone rule prevent an old-epoch revocation from being mistaken for current authority.
- **Offline/LAN UX preserved.** Continuity validation is local-at-startup; an unreachable gateway must not force recovery, and delivery-only counter drift reconciles automatically — safe because push tokens and mappings carry no action authority (sections 15/16).
- **Consistency with update rules.** Section 17's pre-commit rollback preserving live trust state, and the prohibition on backup restoration lowering floors/ledger/trust, align with the witness requirement; section 18's persisted authenticated policy revisions match the same anti-rollback posture.

No contradiction found between these additions and earlier invariants (consumption-before-dispatch, first-valid-decision ledger, key-purpose separation, biometric table in section 1, no lock-screen surface, pairing preservation preference).

## Boundaries checked without findings

- **Scope classification / key separation:** decision-key purposes (one-time UI, routing, update scheduling) remain disjoint from biometric-key purposes (commands, 1Password, credentials, enrollment, reusable rules incl. temporary/session); both verifiers enforce scope from retained semantics, not caller/phone labels (6, 9, 14, 17).
- **Replay/downgrade:** stale-revision heads require signed receipts; expired envelopes are re-issued from current state, never replayed; negotiation is transcript-bound with no retry to older formats after signature failure; floors persist independently of binaries (16, 17, 18).
- **Privileged update paths:** activation transaction, quiescence/drain, generation-bound key access, and the external-installation-boundary requirement are coherent; the acknowledged open items (placement enforcement, old-build key isolation, remote continuity) are explicit gates.
- **Command binding:** canonical capture, stdin-source disclosure, digest recomputation on the phone, requester-exited boundary semantics, and the sudoers-compatibility gate are consistent end to end.
- **UX invariants:** no added confirmations/biometrics, no shortened windows, no mandatory lock-screen or recurring online checks; allow-once remains confined to Little Snitch one-time effect with second-attempt validation.

## Tentative UX choices (flagged, not defects)

These are explicitly deferred or gate-pending product decisions, not planning defects: the automatic idle interval (14), audit retention duration (12), biometric-enrollment invalidation policy (5/7), StrongBox-vs-TEE and any recovery-UX change (4), the ~60 s 1Password estimate (13), and any future forced-floor policy (17). Each already has a consultation path.

## Remaining implementation verification limits

This review cannot verify, and the plan correctly does not claim: macOS 14+ API behavior for XPC peer requirements, service management, and brightness/activity signals; Secure Enclave/Keychain generation isolation and the trust-generation witness mechanism; descriptor-based execution semantics; 1Password/Little Snitch AX contracts and one-time effect validation; single-biometric credential release; background Access authentication; push behavior on real devices; and measured latency. All are scheduled feasibility/acceptance work with failure paths.

## Conclusion

**NO SUBSTANTIVE FINDINGS**

Revision 20's additions resolve the round-13 restored-state finding in a restrictive, offline-preserving, consultation-gated way, and no contradictions, downgrade/replay gaps, privileged-update escapes, or silent UX regressions were identified across the complete plan. Convergence here means planning-level coherence only; every platform assurance above remains to be proven by the scheduled gates before implementation claims are made.