# Round 14 review — gateway/management boundary (revision 20, sections 1–2 with labelled context)

## Verification performed

**Sections 1–2 (product contract, threat model):** Biometric table matches the binding UX (one biometric for command/1Password/rule-setting decisions; allow-once/deny-once/cancel without; session and timed rules treated as reusable). Threat boundary, signature semantics, and documented limitations (UI automation, Accessibility/automation bypass, no transitive-command guarantee) are internally consistent with sections 5 and 17 context.

**Section 16 — gateway ownership and control plane:** The provisioning credential is owner-scoped with no provider or Cloudflare rights; bootstrap requires operator-controlled owner authorization, so phones, transport credentials, and self-asserted Mac keys cannot bootstrap trust. Candidate-token binding closes token-string redirection: root-signed candidate with nonce and expiry, gateway-only challenge, phone proof over its authenticated channel (nonce is root-signed in step 1, so the root can verify the step-3 response), single-use activation, prior mapping preserved on failure, revocation invalidating pending candidates. Counter reconciliation validates retained Mac-signed receipts against local trust history before advancing, restricts gateway evidence to revocation (never enrollment), and tombstones prevent re-adding a revoked phone via ordinary mapping updates. Lifecycle operations (enrollment, token refresh, revocation, repair, uninstall) require no post-setup operator work; bootstrap-time operator authorization is setup, not a recurring step.

**Cloud management authority:** Credential table matches the prose; controller has no listener, outbound-only typed operations, caller and administrator authentication per operation, and the recurring-authorization case is retained as a feasibility blocker with consultation rather than inserted into the approval path.

**Feasibility gate (restored trust state) vs. round-13 disposition:** All accepted requirements are present — non-migrating installation key plus independently protected witness, explicit statement that a key alone cannot detect same-Mac rollback, no Secure Enclave monotonic-counter assumption, defined crash/backup/migration/reinstall behavior, startup continuity validation, offline/LAN operation without a gateway check, gateway unreachability not itself triggering recovery, restrictive application of verified revocations, suspension on unknown signed trust changes, higher gateway numbers alone insufficient, delivery-only drift auto-reconciling, explicit failure with consultation before any UX change, and the required rollback/migration tests including gateway-unreachable LAN and relay paths. No binding UX constraint is weakened: no extra biometric, online check, physical access, or forced re-pairing is approved, and the Mac remains usable via manual approval in suspended-authority cases.

**Transport acceptance cases:** Cover the new mechanisms (token-possession challenges, stale revisions, tombstones, counter restoration, candidate races) without introducing mandatory interactive steps on the approval path.

No internal contradictions, authority confusions, replay windows, or UX regressions found in the scoped text.

NO SUBSTANTIVE FINDINGS