# Remozio plan review: revision 20

This is a plan-only review. I did not run tools, test anything, or inspect source. I reviewed the complete revision 20 text, focusing on the new §16 restored-trust gate and how it interacts with §17 and §18. I agree with the round 13 disposition of Opus 1, with the limitation described below.

## Finding 1: Medium. Rollback detection covers enrollment only, but floor and policy rollback relies on it too

**References:**
- §16, "Feasibility gate: restored trust state"
- §17, "Activate and commit security floors" and "Failure and recovery"
- §18, "Compatible additions and breaking changes"

**Defect:** Revision 20 correctly notes that ordinary files, signed snapshots and root-only permissions do not detect backup rollback. However, the proposed witness is bound only to "the Mac/account and enrollment generation."

Other sections make the same no-rollback promise for state the witness does not cover:
- §17 says "restoring a backup cannot lower these protections" for committed security floors and policy generations.
- §17 also says the trusted installation boundary checks candidates "against committed floors and installed generations."
- §18 says "Persist authenticated policy revisions and minimum security generations … Reject replayed older policy."

These are all persisted local state, so they have exactly the detection problem the new gate describes. Nothing in the plan says how they are protected.

**Failure scenario:**
1. A release raises the security floor to exclude an adapter build with a known flaw, such as one that lets a same-user process drive it.
2. The administrator later restores a pre-update backup of the protected store, for example during migration or disaster recovery. This is the same non-malicious restore the gate already models.
3. Enrollment continuity may still pass. Either no enrollment changed, or the witness was checked and accepted.
4. The committed floor has now silently reverted. The old signed adapter again passes the per-request generation check, and the installation boundary accepts the older generation.
5. A malicious unprivileged caller, which is in scope, can then use the reinstated vulnerable component.
6. The routing revision and the gateway lifecycle epoch/revision counters can also regress the same way. §16 depends on those counters for its "stale epoch/revision" reasoning.

**Minimal correction:** Extend the same gate's witness to one combined trust generation covering:
- enrollment records,
- committed security floors and authenticated policy revisions,
- the installed-generation record used by the activation boundary.

Apply the same failure behavior already defined: withhold affected authority and use the existing independent administrator recovery. Add acceptance tests that restore a pre-floor backup and then try to launch an old signed adapter or root authority.

This adds no confirmation, biometric, online check or manual step to normal operation, so it does not worsen UX. The only UX impact is the gate's existing post-restore recovery path, which already requires consultation if it proves too costly.

## Assessed without further findings

- **Gateway evidence:** it can only restrict authority, a higher counter alone is insufficient, and revocation tombstones and new-epoch re-enrollment are handled.
- **Offline operation:** normal offline and LAN use is preserved without a gateway startup check.
- **Scope classification:** decision-key and biometric-key separation and the Little Snitch once/reusable rules are unchanged and consistent.
- **Relay:** it cannot mint decisions.
- **Updates:** drain and quiescence rules, the restart matrix, and admission-race resubmission are consistent.
- **Mixed versions:** request-contract selection has no downgrade path.
- **Tentative UX choices:** none are silently selected. The idle interval and retention duration remain declared as deferred preferences.

## Limits of this review

Platform feasibility is unproven. That includes witness mechanisms, pre-login key custody, single-biometric credential release, AX atomicity, descriptor execution, and protected update placement. These gates are correctly scheduled, but they remain implementation evidence rather than verified claims.

**SUBSTANTIVE FINDINGS REMAIN**