Back to corpus
architecturetechnical paper candidatescore 44

Layer 4 — Evo3 Architectural Exploration of the SOOP-2 Convergence Problem

> **Status:** Scrutiny layer 4 of 4. Peer architectures vs ELP-1, not critique of ELP-1. > **Date:** 2026-05-13 > **Inputs:** ELP-1 v1 draft (05-everlasting-loop-protocol.md), 10 SOOP-2 criteria, current scoreboard (14/295 typed, 3/10 criteria met). > **Output role:** Compete with ELP-1 as a peer design. Verdict at the end.

Full HTML reader

Read the full artifact

Open in new tab

Extracted abstract or opening context

> **Status:** Scrutiny layer 4 of 4. Peer architectures vs ELP-1, not critique of ELP-1. > **Date:** 2026-05-13 > **Inputs:** ELP-1 v1 draft (05-everlasting-loop-protocol.md), 10 SOOP-2 criteria, current scoreboard (14/295 typed, 3/10 criteria met). > **Output role:** Compete with ELP-1 as a peer design. Verdict at the end. The honest bottleneck of SOOP-2 right now is not compute, not orchestration, not multi-machine resilience. It is **the body of work itself**: 281 more SKILL.md files need typed frontmatter (Track B), one router needs a labeled benchmark plus a `type_compatibility_weight` knob (Track C), one Tier 2 endpoint needs a flip from MiniMax to Mac4:8100 with fallback (Track D), four feedback components need wiring at `[home-path]` (Track E), and two more skills need silent_capable=true (Track G). Total estimated effort from EXECUTION-PLAN.md is 13.5 days, mostly mechanical edits that any Claude or Codex pane can do. The reason ELP-1 even exists is to defend against the four caveats in §0 of that doc: opaque ScheduleWakeup queue, Claude Code closure killing wake, single-driver pattern, no external stall escalation. Each caveat is real. None of them is currently causing a stall — the loop is advancing, just slowly and only when Mohamed's main session is alive. The cost of waiting (3 single-Claude sessions over 2 weeks) is comparable to the cost of building ELP-1 (1-2 sessions, per the doc's claim; realistically 2-4 once Supabase migrations, launchd plists on two machines, worker registration, and verifier scripts are all shipped and debugged). Mesh primitives genuinely shipped today: `aura-gateway` (mac1:8095) with cross-machine `/inject`, `codex-gateway` (mac4:8096), Syncthing across mesh, Supabase with several active projects, `pulse` skill (Pulse-eligible tracks live in EXECUTION-PLAN), `ops:autopilot` (referenced in the SOOP-2 dispatch table), `meshd` running but with Codex slot "unborn" per mac4-codex-control-audit-2026-05-06.md, telegram + sms bridges (per ELP-1 §8.2 calling them "already shipped per memory"), Grafana on cloud-vm. Hypothetical or not-fully-wired: cortex:rules quarantine integration, the SOOP-2 verifier suite (the 10 per-criterion checks don't exist as code yet), worker heartbeat tables in Supabase, the supervisor.py and worker.py themselves. The genuine question Evo3 must answer: **does the work scale better if you build a multi-driver platform first, or if you just keep typing skills with a slightly hardened single-driver?** ELP-1 assumes platform-first. The 6 paths below test that assumption.

Promotion decision

What has to happen next

Promote into a technical note or architecture paper with implementation anchors.

Why this is not always a full paper yet

Corpus pages are public-safe readers for discovered workspace artifacts. They are not automatically final papers. A corpus item becomes a polished paper only after the editable source, evidence checkpoints, references, figures, render path, and release status are attached through the paper schema.