External Review (sol)

This section is an independent critical design review of this site’s own chapters, run by an external frontier model — gpt-5.6-sol at xhigh reasoning (via codex exec on lane-182) — on 2026-07-18. It is not our voice. The layer reviews in Part III are ours; the six memos below are someone else’s adversarial read of the same material, reproduced verbatim.

What this is, and what it is not

Six memos, one per beat of the stack. Each was produced under a deliberately adversarial brief: the reviewer was told to be direct and critical, given no filesystem or repo access, and handed only the relevant chapters inlined verbatim into a single self-contained prompt (Part II architecture + Part III review + the matching Part V spec-candidate block). So sol is critiquing exactly what the site says — not the code behind it — which is the right test for a documentation program: if a claim cannot survive a careful reading of the prose, the prose is wrong, or the design is.

• These are critiques, not decisions. Nothing here supersedes a decision record. Where sol disagrees with one of our layer reviews, we have kept both voices rather than quietly adopting sol’s — the disagreement is the useful part.
• The positions are folded forward. Every place sol takes a substantive position, the design frontier now carries a short External review input line pointing back to the relevant memo, and the genuinely new gaps sol surfaced are first-class entries there (including a new Theme G — the local trust boundary).
• Each memo ends with a machine sentinel (SOLREV-…-DONE). That is the reviewer’s own completion marker, kept so the record shows each run finished rather than truncated.
• The header of each page is lightly normalized (title · date · reviewer · scope · method); everything below the header is sol’s text, unedited.

How to read it

Start with the memo for the layer you care about; each opens with a five-line orchestrator-facing summary, then the long-form argument, prior-art table, ranked proposals, and the questions sol says are missing from the review agenda. If you only read one thing, read the strongest criticism called out in each summary below.

Recurring cross-cutting asks

The same five demands surface in memo after memo, which is itself the signal worth heeding:

1. Publish a threat model + trusted computing base + authority matrix before ratifying d/103-B or d/104 — every security claim currently rests on an unnamed boundary.
2. Make the principal immutable. A mutable display label must never be the security principal; bind identity, grants, storage, and audit to a stable app_id (+ per-install instance_id), with labels display-only — and stabilize the canonical origin before users accumulate origin-scoped state.
3. Separate the four things “signed” is doing — publisher identity, catalog authorization, payload integrity, local consent — and move catalog trust toward TUF/Uptane (offline threshold roots, snapshot/timestamp, rollback+freeze protection, user-selectable roots).
4. Turn slogans into checkable invariants + conformance vectors. “Zero-trust”, “no cliffs”, “every rung undoable”, and the as-built spec candidates all need normative prose, canonical encodings, and positive/negative test vectors before anyone can implement them independently.
5. Name and defend the local trust boundary. The loopback plane and the engine connector are reachable by any local process; Host/Fetch-Metadata and a syntactic header are not authentication.

The six memos

Mission & decisions spine

Reviews the big picture, the mission/principles/litmus, and the decisions ledger. Strongest criticism: there is no explicit threat model or trusted computing base — every security claim (origin isolation, VM containment, launch resolution, delegation, audit) rests on an unnamed boundary, and both PROPOSED decisions each widen an authority boundary no invariant governs. The concrete consequence: d/104 is “not ratifiable as written” (a mutable display label must not become a security principal) and d/103-B should take the distinct container-origin route type, because overloading backend-proxy hides a shift from an /api request boundary to an active-content publication boundary. Also names the litmus tension head-on: the “user-owned trust chain” is operationally operator-owned today.

Transport & peer serving

Reviews transport/identity, peer serving, and their four spec candidates. Strongest criticism: the spec candidates are not yet sufficient for an independent interoperable implementation — the Peer Ticket carries no on-wire version/type discriminator, the JSON + base64url parsing profiles are unspecified, and the single-byte ACK conflates ~7 distinct failure classes. On the headline question it narrows our review: group membership is an authenticated ACL, not a capability system, so the first gated release should be membership AND a per-route, audience-bound grant (not membership replacing the ticket), shipped on a new ALPN xenon/serve/tcp/2 — never by mutating /1 in place. Ship group-doc v1, front it with a lineage-independent authorization interface, and require a signed one-way v1→v2 transition.

The serving plane & router

Reviews the loopback plane, the workerd router, and its three spec candidates. Strongest criticism: a cross-site safe request without Origin (an image, a navigation) can reach a backend prefix — including a whole-origin backend-proxy — because the cross-origin arm only runs when Origin is present and the Fetch-Metadata floor only refuses cross-site unsafe/WebSocket requests; and /xe/api/index//catalog answer before the hostname/Origin/Fetch-Metadata rungs, exposing app inventory to anything that reaches the loopback socket. Host and Fetch Metadata are routing/CSRF signals, not plane authentication. The fix is a normative Browser Request Admission clause plus an explicit PNA/LNA preflight policy; on scheme, choose plain HTTP for regular apps (reject the local CA) with a separate cryptographic plane-identity handshake for Prism.

App model & engines

Reviews the install spectrum, XAM v0.2, the compose safe-subset, the engine socket contract, and the update engine. Strongest criticism: the chapter’s “no loopback TCP” claim is false as stated — 127.0.0.1:5199 plus a syntactically-validated x-xe-app header does not authenticate the caller, so any local process can drive the connector and select an installed app; and on macOS the engine is a raw tcp://127.0.0.1:2375 Docker API, far more privileged than a backend port. The defensible invariant is narrower: no app-owned backend port is published on the host, and no app or router receives the engine credential. The through-line fix: treat Compose as an import language, not the deployment authority — compile a pinned dialect into a small allowlisted IR, execute only that, and inspect the created objects before start. Two sharp catches: a fixed non-latest tag is not a pin, and the sh+nc exec bridge is not a general unmodified-container contract (distroless images ship neither).

Shell & rendering (Prism / Xenon)

Reviews the shell architecture, the G1–G6 gap register, and the Prism↔app contract. Strongest criticism: a hash-linked journal is tamper-evident only relative to a trusted head — without signed or externally anchored checkpoints the whole chain can be truncated or replaced, so “exit without loss” is today an intention, not a guarantee; and shield-by-default is infeasible via injected JS (the Controlled Frame permissionrequest API can only allow/cancel — real shielding needs a Xenon browser-process permission delegate). On G6, sol lands on a hybrid: Prism owns policy/shielding/ persistence/journaling, Chrome/OS owns final device selection and enforcement, and the effective outcome is the intersection, never the union. The four-verb contract should split into a cooperative lifecycle RPC and a separately-audited automation gateway (drop raw tab.open{url} and key).

Devices & the agent layer

Reviews the device fabric, the resident-agent architecture, the grant/lease model, and the audit hash-chain. Strongest criticism: the security model is not yet coherent enough to implement — the problems are unresolved semantics, not missing code. onward:false contradicts minting a lease under a grant (a lease that transfers authority is the onward delegation the grant forbids); the shell is not a defensible security boundary; and the 64-bit-truncated hash chain is corruption detection, not adversarial tamper evidence. Fixes: model the lease as an audience-bound invocation, not a delegation, with a deterministic attenuation-subsumption algorithm and a published max stale-authority window; split the agent into five processes and exclude raw CDP / execute.script / persistent injection from v1; and converge on one full-hash, signed-checkpoint ledger with cross-device head gossip. Human approval is inspection, not an authority bound.