# Remozio plan review: revision 25

This is an independent review of the complete revision 25 plan. Earlier convergence is not assumed to carry over.

Most of the plan holds together, but two defects remain, both in the revision 25 journal-continuity additions. They conflict with the section 16 witness gate, and one can turn a routine power loss into a manual repair.

## Finding 1 (Medium): Two contradictory designs for ledger and journal rollback detection

**Sections:** §12 *Atomic journal writes*, §16 *Feasibility gate: restored trust state*

**The contradiction:**
- Revision 25 says the continuity checkpoint covers "consumed-action and outcome boundaries" and must be protected by "the combined continuity gate in section 16", because "ordinary separate files are not sufficient protection against whole-backup rollback."
- §16 now lists "the authoritative ledger/journal continuity checkpoint and recovery-required marker" in the combined trust generation.
- The same subsection of §12 still says epoch handling "does not rely on the trust witness detecting an audit-only rollback."
- Recovery-required state must also survive "whole-backup restoration". Restoring a backup taken before the marker was written removes the marker, so only the independent witness could detect that.

**Failure scenario:**
- Read literally, the witness must be committed on every request consumption and outcome, which means on every command approval.
- §16 already warns against assuming a general monotonic counter. A witness mechanism that is adequate for rare trust and floor changes may be unsuitable for per-action writes because of write endurance, latency, or availability.
- If so, the combined gate fails. The documented failure path then withholds all action authority, or forces consultation, for a property the plan does not need.
- Pending payloads are memory-only (§6). A root restart cancels unconsumed requests, and every request has a fresh 256-bit challenge. A ledger-only rollback therefore cannot revive an old approval. Its real consequences are audit loss and loss of outcome evidence.
- Replay-relevant control state (routing, scheduling, gateway, enrollment revisions) is already covered by the trust generation.

**Minimal correction:** State one model explicitly.
- Use per-action continuity with a local crash-consistent checkpoint.
- Bind the checkpoint to the witness only at trust, floor, or control changes and at epoch creation.
- If only the audit/ledger state was rolled back and trust state is intact, show a labelled history-loss discontinuity and mark affected outcomes Unknown. Do not require administrator recovery for this case.
- Alternatively, if per-action witness commits are intended, make their write rate and latency an explicit criterion of the §16 gate.

**UX impact:** None. This correction avoids a potential loss of remote functionality.

## Finding 2 (Medium): A routine crash during commit can force administrator repair

**Sections:** §12 *Atomic journal writes* (the "If that write fails, remain closed… A restart cannot clear the condition" paragraphs)

**The problem:** The text does not separate two cases:
- **Protocol-resolvable interruption:** power loss between the journal transaction and the checkpoint update, before dispatch.
- **Genuine continuity failure:** a detected mismatch or a failed recovery-marker write.

"Startup must also detect the incomplete checkpoint transaction" appears next to "remain closed" and "a restart cannot clear the condition." This reads as though any interrupted commit closes admission until the independent administrator recovery runs.

**Failure scenario:**
- The Mac loses power, or the kernel panics, during an approval commit while the user is remote.
- On reboot, command approvals stay closed until a manual admin repair. This conflicts with §12 *Sync and offline cache* ("A normal restart alone is not evidence of rollback") and with the remote-UX goals.

**Minimal correction:**
- Require the commit protocol to classify interrupted states deterministically.
- A pre-dispatch interruption should roll back or forward automatically and record Unknown only where dispatch may have occurred.
- Only a real mismatch, or an unresolvable state, should set a persistent recovery-required state.
- Add "power loss mid-commit recovers automatically" to the §12 acceptance cases.

**UX impact:** This improves UX. No consultation is needed.

## Other areas assessed; no further substantive defects

- **Rejection-telemetry bounds (Opus 2 disposition):** reserved lifecycle budget, aggregate counters for unauthenticated traffic, and rate limits for revoked keys. This is adequate.
- **Scope classification and keys:** decision-key versus biometric-key purposes, including routing and update-scheduling controls. The Little Snitch allow-once exception is not widened to commands or 1Password.
- **Revocation and restore:** tombstones and rollback via the §16 witness.
- **Compatibility:** mixed-version request selection, with no downgrade on signature failure.
- **Updates:** update quiescence and automatic resubmission only on an authenticated no-admission response.
- **UI actions:** permit semantics for UI races.
- **Remote fallback:** the local-command routing gate.

The command binding (captured argv and stdin disclosure) and the credential-release and one-biometric gates remain correctly placed as feasibility gates with consultation paths.

**Pending user decisions, not defects:**
- the migration ceremony
- sudoers policy selection
- the idle interval
- the retention period

## Implementation limits

This review is textual only. Every feasibility gate still requires real evidence, including:
- Secure Enclave custody
- the monotonic witness
- protected placement and anti-rollback
- one-biometric credential release
- Accessibility fixtures for 1Password and Little Snitch
- Android push and Doze behaviour

**SUBSTANTIVE FINDINGS REMAIN**