# Round 19 review — GLM (identity/history focus)

Input: revision 25 excerpts, sections 1, 2, 3, 12, plus labelled cross-section context (16, 5, 17, release manifest). Prior disposition: round 18 (both Opus findings accepted).

## Verification of prior disposition

**Opus 1 (recovery-required state):** fully incorporated. Protected continuity checkpoint and recovery-required marker outside the replaceable journal (§12); covered by the combined §16 gate ("Also cover the authoritative ledger/journal continuity checkpoint and recovery-required marker from section 12"); startup validates checkpoint, writer ownership, recovery marker, and ledger continuity before reopening admission or allocating an epoch; failed persistence of recovery state keeps the system closed and survives restart; crash-consistent commit protocol before dispatch with power-loss testing as an explicit feasibility deliverable.

**Opus 2 (rejection floods):** fully incorporated. Bounded aggregate counters for unauthenticated traffic; individual rejection records gated on verifiable current/retained enrollment signatures; authenticated rejection telemetry rate-limited with dropped-event counts; lifecycle budget reserved at admission; floods cannot force early pruning; storage failure rejects admission before dispatch; sustained forged/revoked-key flood tests specified.

## Changed management boundary (§16 context)

Checked independently: provisioning requires both the root-only scoped credential and gateway-side owner authorization; control objects are typed, epoch/revision-bound, idempotent on retry; submission credential is wake-only. Token binding verifies possession without biometric or admin steps, keeps the prior mapping on failed/expired proof, invalidates candidates on revocation, and cannot be hijacked by token recycling (proof flows through the enrollment-authenticated Mac channel). Counter reconciliation requires the retained Mac-signed receipt with exact trust changes — a bare higher number is rejected; gateway evidence can only restrict authority, never enroll; verified revocations apply locally before phone operations; re-enrollment after a tombstone requires a fresh admin-authorized epoch. Local revocation is immediate regardless of gateway reachability; queued pushes grant nothing because the phone rechecks Mac authority. Rollback of enrollment, floors, controls, and the §12 checkpoint is covered by the combined trust-generation witness gate, with an explicit failure/consultation path and no approved UX change (no online check, recurring authorization, physical access, or forced re-pairing).

## Binding UX constraints

Biometrics table in §1 matches the confirmed contract exactly (no biometric for dismiss/cancel/deny-once/allow-once; biometric for every rule-setting decision and all command/1Password/credential approvals — one prompt per decision). Token rotation needs no new administrator prompt; offline Mac defers rather than blocks; enrollment and recovery are remote-capable; migration ceremony remains a pending user-choice gate, correctly not claimed as resolved.

## Consistency checks performed

- §12 epoch model: fresh random epoch per service start plus the prohibition on resuming a persisted older epoch prevents sequence reuse after audit-only rollback without relying on the trust witness; cross-epoch cursors, batch binding, discontinuity labeling, and read-only reconciliation of phone evidence are mutually consistent.
- §3 privilege boundaries: root-owned placement, per-XPC live code-identity validation, caller UID capture, pre-login transport key fallback correctly scoped away from authority/credential keys, one-time dispatch permits, and E2-end payload encryption over the relay are internally consistent with §2's trust assignments.
- §1 "one explicit decision authorizes one captured action" is reconciled by the reusable-rule carve-out with mandatory biometrics; no contradiction.

No correction in the reviewed text worsens UX; none is proposed.

NO SUBSTANTIVE FINDINGS