XMM Proposal Agent · Parallel Conveyor · D049 / D050 / D051

中文

What it is now, what the measurements revealed, and what D051 will turn it into

One planner chooses K non-conflicting jobs, K independent processes execute them concurrently, and one reduce writer commits the ledger. D049/D050 preserved concurrency safety; D051 must turn that safety machinery from high-frequency review into a continuous output of submittable proposals.

Measured window: 2026-07-26 08:05–10:09 UTC 47 ideas · 12 roles · 4 engines K: 3 → 10 (D050 AIMD) D051 decision frozen: 2026-07-26

01 — TWO AXES

The conveyor schedules cells of (idea × role), not “stages”

Understanding the whole architecture requires one idea: a unit of work is neither “one idea” nor “one role,” but one shift — one role performs one bounded task on one idea and leaves a 3-line handoff at the end. No worker owns an idea end to end.

Global state is therefore a matrix: the 47 ideas are rows and the pipeline's 12 roles are columns. In each batch, the planner selects K mutually independent cells from that matrix and advances them concurrently.

One observed scheduled batch (2026-07-26 08:47 UTC)
idea M0R1R2 R3R4R5 R6R7
I021 M101··✓✓✓wk1··
I017 M83··✓wk2····
I024 M31··wk3·····
I039 NGC 5907··wk4·····
I018 M83 ULX✓wk5✓✓····
I005 NGC 4631··✓✓✓✓··
…41 others········

Historical shift completed The 5 concurrent cells in this batch Untouched

Figure 1 — The five cells actually scheduled in one real batch. Notice that they all occupy different rows: parallelism occurs between ideas, never within the same idea. That is not accidental: clause 1 of the planner's independence predicate enforces it.

The independence predicate — why it must be “different ideas”

The parallel-planning prompt requires every pair of shifts in a batch to satisfy all four conditions:

  1. Different ideas — at most one writer per idea file (the single-writer invariant).
  2. No D023 conflict — an R4 attack and R5 adjudication on the same idea cannot share a batch; adversarial work must remain separated across shifts.
  3. No data dependency — one shift may not read an artifact that another shift is writing.
  4. Exclude in-flight work — ideas still running in the previous batch cannot be touched; this is the premise of the prefetch pipeline.

Clause 1 is the source of every design consequence. It caps parallelism by “how many independently advanceable ideas are currently available,” not by “how much backend concurrency can be tolerated.”

02 — TIMING

Four beats in a batch, plus a staggered fifth

PLAN is serial, expensive, and LLM-driven; COMPOSE is deterministic and millisecond-scale; MAP is the only parallel part; REDUCE is the sole global writer. PREFETCH tries to hide planning of the next batch beneath MAP.

Four beats in one batch plus a staggered fifth PLAN is serial, takes 20 to 24 minutes, and lies on the critical path. COMPOSE is a deterministic millisecond-scale step. MAP runs K workers concurrently and ends at a full barrier, where fast workers idle while waiting for the slowest. REDUCE is the sole global writer. PREFETCH plans the next batch concurrently during MAP. 1 · PLAN 2 · COMPOSE 3 · MAP 4 · REDUCE planner · hermes / nim-large reads 47 idea ledgers + scheduling constraints measured 20–24 min · on the critical path compose deterministic milliseconds wk4 R2 I039 wk3 R2 I024 wk1 R5 I021 wk2 R3 I017 wk5 R1 I018 each worker = an independent CLI process, writing only its idea file + frag 5 · PREFETCH no output PREFETCH plans the next batch during MAP (excluding in-flight ideas) full barrier · fast workers idle for the slowest reduce sole global writer merges every frag planning: 44% of critical path slot utilization: 52% prefetch hit: 0 / 1 5 shifts committed / 124 min
Figure 2 — One batch, with horizontal extent proportional to measured duration. Three structural facts matter: PLAN lies on the critical path; MAP ends at a full barrier (the grey bars are idle slots); and the PREFETCH planner is still alive while REDUCE runs.

Who actually executes — it is not “one at a time”

The planner is always one hermes invocation (default nim-large) and does not inspect route. Workers are K genuinely concurrent, independent processes. Their engine is jointly determined by the packet's route and the quota gate; failures fall back down the chain:

Worker engine resolution and fallback chain A hermes route resolves to a one-element chain with no fallback. Claude and codex routes resolve to a four-level chain ordered by quota ratio. R2 is routed by the driver rather than the planner. A non-empty frag is completion; an empty frag below 300 seconds falls back to the next engine, while an empty frag at or above 300 seconds abandons the entire chain and records a noop. packet .route ROUTE = HERMES hermes one-element chain · a failure is final; no second chance ROUTE = CLAUDE / CODEX claude codex agy hermes-terra quota ratio decides first R2 — ROUTED BY DRIVER, NOT PLANNER claude if ratio<1.0 codex if ratio<1.5 hermes quota ratio = weekly consumption relative to even cadence; burn fast → fall back to hermes sooner frag non-empty? proof-of-work yes → done clear engine cooldown no · <300s → fallback mark 4h cooldown no · ≥300s → noop abandon the full chain
Figure 3 — Engine resolution and fallback. Note that a route = hermes shift receives a one-element chain: there is no fallback at all. In the observed batch, four of the five workers used hermes.

03 — RELATION TO THE PIPELINE

A role is a strictly serial chain; a batch cuts across it

This is where all the tension lies: proposal delivery depends on the latency of one idea traversing the whole chain, while a batch parallelizes different positions in different ideas.

The pipeline role chain and its relation to parallelism Upstream R0 and M0 feed R1 and R2. For the same idea, R2 through R3, R4, and R5 is an incompressible serial chain with at most two R4-to-R5 repair rounds; only R5 can write the Gate ledger. R5 exits to kill, park, needs-data back to M0, or promotion through R6 to R7 to R8. Four kinds of global work are serial-only and collapse the whole batch to K equals 1 when present. UPSTREAM · CONTINUOUS DIVERGE R0 coverage matrix M0 candidate packet R1 sourced facts R2 generate idea CONVERGE · STRICTLY SERIAL PER IDEA R3 freeze design R4 kill-shot R5 four-gate ruling ≤2 repair rounds only Gate ledger writer QUANTIFY → EMIT · AO EVENT-DRIVEN R6 feasibility R7 draft R8 TAC simulation kill · graveyard park needs-data returns to M0 to fetch data SERIAL-ONLY — WHEN PRESENT, THE FULL BATCH COLLAPSES TO K = 1 R5 pairwise Elo tournament · portfolio rescoring · D048 downgrade elimination D043 gate-drift fix (one prose false positive can pre-empt the whole parallel pool)
Figure 4 — R2→R3→R4→R5 is an incompressible serial chain for the same idea, plus at most two R4→R5 repair rounds; only R5 can write the Gate ledger. The parallel predicate prevents one idea from advancing two steps in a batch, so this chain's length is wholly unaffected by K.

Where the current 47 ideas are distributed

seed38
killed5
parked2
developing1
proposal-ready0
Figure 5 — Lifecycle histogram of the idea ledger, measured on 2026-07-26. proposal-ready = 0 is an explicit zero, not missing data. It agrees with the planner's self-reported role histogram: R3 = 6, R5 = 5, R4 = 1, while R2 / R0 / R1 / R6-lite / L are all 0 (starved).

This is the architectural core of the problem

Raising parallelism to 10 advances work horizontally: more seeds receive an R3 freeze. But a proposal needs vertical progress: one particular idea reaching R6 → R7. The length of that vertical critical path (R2→R3→R4→R5→repair→R6→R7, one shift per step) is wholly unaffected by K because clauses 1 and 2 of the independence predicate forbid an idea from advancing twice in the same batch.

04 — MEASUREMENTS

What did 124 minutes buy?

Wall clock124 min08:05 → 10:09 UTC
Committed shifts52 of 3 planned batches
Planning on critical path44%20 + 22 + 12 min
Slot utilization52%10105s / (5 × 3863s)
Prefetch hits0 / 139 min burned in background
Worker time burned64 minResearch completed, not persisted
Measured Gantt chart for one run Batch-one planning took 20 minutes and produced no file. Batch-two planning took 22 minutes, followed by five concurrent workers; three finished within 12 minutes yet idled about 53 minutes at the barrier for the slowest. The concurrent prefetch plan took 39 minutes and produced no output. Batch three planned for 12 minutes and then scheduled only one worker. 08:00 08:15 08:30 08:45 09:00 09:15 09:30 09:45 10:00 10:15 BATCH 1 PLAN — prose only; no file written BATCH 2 PLAN 22 min wk4 R2 I039 wk3 R2 I024 wk1 R5 I021 wk2 R3 I017 wk5 R1 I018 noop · tool budget exhausted prefetch no output · tool budget exhausted full barrier BATCH 3 PLAN 12 min → only 1 worker scheduled (serial-only gate-drift fix)
Figure 6 — The measured Gantt chart. The three red segments have the same root cause: the model completed the work but did not persist it (prose planning / exhausted tool-call budget). The grey bars are idle slots: three short workers finished within 12 minutes, then waited about 53 minutes.
AS EXPECTED

The single-writer invariant, idea-level mutex locks, frag proof-of-work, summary sidecars, and engine-chain fallback all worked as designed. Five workers wrote their respective idea files concurrently without conflict; reduce merged correctly; the calibration log recorded all five entries, including the noop.

Repeated ideas are not a bug: scheduling the same idea again represents its R2→R3→R4→R5 role progression.

NOT AS EXPECTED

No mechanism caught the failure mode. “Said it but did not write a file” occurred three times. The driver can see only whether a file exists, so it logged a strike once, a noop once, and silently lost 39 minutes once. Fixed: a write-first protocol plus raising the harness tool-call ceiling from 250 to 500.

NOT AS EXPECTED

AIMD measures a signal that is always zero. The shared backend saw 255 requests, 0 HTTP 429s, and 0 failures in 30 minutes. The decrease branch of adaptive parallelism is therefore structurally never triggered, and K only rises 3→4→…→the ceiling of 12. The real constraints are barrier-tail latency and the supply of independent shifts — neither is in that signal.

DESIGN TRADE-OFF

A lint false positive can pre-empt the whole parallel pool. The gate-drift check matched “is not resolved here” in an idea's prose as the status word RESOLVED. Because the repair is serial-only, K = 6 collapsed to one scheduled job, spending a 12-minute PLAN plus 322 seconds of work to change a negated sentence.

05 — D051 INSTITUTIONAL REDESIGN

Turn the conveyor from “maximum review” into collaboration among Evidence, Production, and Adversarial departments

What Figures 1–6 measure is not that a model is insufficiently capable. It is that the scheduler is in fact deciding the organisational structure: cheap, always-eligible review shifts structurally overproduce under stage-FIFO, while the evidence and production work that move an idea to R6 and R7 are starved. D051 is an owner-endorsed institutional revision. It retains D049/D050's concurrency-safety invariants but changes slot budgets, adjudication conditions, and product ownership.

R4 + R5 (cumulative)195review role shifts
Evidence roles (cumulative)136M0 / R0 / R1 / R3; mostly freezing rather than extracting
Full R6 / R7 / R80 / 0 / 0the production chain never actually started
R5 on 2026-07-26178 were NO_NEW_SHOT
D043 drift fixes4bookkeeping-of-bookkeeping on the same day
proposal-ready0an explicit zero, not missing data

Statistical basis: the cumulative role histogram above comes from orchestrate/state/calibration.log, excluding 71 legacy-format rows whose role column actually records route. Full R6 / R7 / R8 are 0 / 0 / 0, while all-time R6-lite is 14. All numbers are historical diagnostics from 2026-07-26, not a live dashboard for the current cycle.

D051 diagnosis

We built a review bureaucracy while trying to solve research problems. The problem is neither an insufficient K nor a need for a smarter end-to-end agent. Stage-FIFO, the anti-polish quota, and review's low cost and constant eligibility together make review the default output, while evidence contact and production receive no protected budget.

Institution, not agent: three indispensable conditions

01

Error decorrelation

Different routes and architectures attack the same claim. D023 heterogeneity and the capability floor remain: this is not multi-agent voting, but making errors uncorrelated.

02

Verifiable anchors

Disagreements can be resolved only by inspectable external anchors: independent recomputation, archive refetch, rerun/hash check, or a feasibility/power number — never by “agreement.”

03

Monotonic memory

Every correct increment must enter a ledger and cannot be lost. Gate ledger, graveyard, TRUST_TABLE, SHIFTS, and frag+reduce remain institutional memory, not chat history.

Severity clause: unanchored review cannot move a gate

D051 adopts a Mayo-style severity clause: an R4/R5 event may move a gate only when it supplies a replayable, checkable anchor. Unanchored reviewer prose may remain as a note, but its information content is zero and it cannot justify FATAL, REFRAME, CORRECTION, or a lifecycle change.

PERMITTED ANCHORSindependent recomputation · archive-footprint refetch · rerun / SHA-256 · feasibility / power number
GATE MOVEMENT FORBIDDENwording judgment without an external check · agreement among same-source reviewers · harness failure mistaken for a capacity signal

Measured examples: I026's FATAL came from an XSA-footprint recomputation; I035's REFRAME from rank arithmetic and a HEAVY hash mismatch; I005's PARK from power 0.060/0.073 ≪ 0.8. In contrast, unanchored prose produced 8 of the 17 NO_NEW_SHOT outcomes that day.

Production inversion: budget slots by department, not by stage-FIFO's natural allocation

EVIDENCE

Creates bits

M0 / R0 / R1 / R3-data / HEAVY pilots receive a protected majority of slots. HEAVY becomes an owner-set, weekly pre-authorized budget, with champions first.

PRODUCTION

The only department that owns a product

Full R6 + R7 living drafts. Each champion keeps one living draft in shared/drafts/; an empty feasibility table is an honest TODO. R8 attacks the draft, not the idea prose.

ADVERSARIAL

Stops false bits

R4 / R5 / R8 / L spend evidence only to stop false evidence. Two consecutive rounds with no FATAL+REFRAME and no new evidence file trigger a yield circuit-breaker: review of that idea pauses until new evidence arrives.

Champion system: give the product an owner at ledger level

D049 / D050 CURRENT STATE

  • stage-FIFO chooses what is currently doable
  • review is cheapest and always schedulable
  • new seeds continually enter the pipeline
  • every idea moves one horizontal step forward
  • R6 / R7 have no protected slots

Breadth grows while the product chain stops at seed. Eleven same-day R2 seeds received 17 R5 adjudications.

Implementation roadmap: 0a / 0b / 5 are live; the remainder is pending

No.ChangeStatusPurpose
0awrite-first protocol; hermes agent.max_turns 250→500LIVEBlock “work completed but not persisted”
0bwrite-set gate + parallel reduce frags + orphan lock guardLIVEMechanically enforce one file / one writer
1R4/R5 severity clause; gate-drift negation-aware matchingDECIDEDOnly anchored review may move a gate
2plan_constraints.py yield circuit-breakerDECIDEDZero-yield review can no longer loop indefinitely
3champions.py + milestone contracts + serves:DECIDEDConcentrate most budget on the product critical path
4deterministic typed inventory; separate FAST/HEAVY lane views; LLM writes task onlyDECIDEDRemove the second planning brain and the 20–24 min PLAN critical path
5rolling.sh completion-driven reduce_one() + queue refillLIVEBatch full barrier eliminated; planner remains an LLM
6champion full-R6 + shared/drafts/ living draftsDECIDEDStart the real proposal-production chain
7north-star / velocity / yield / utilization metricsDECIDEDMetrics serve scheduling only, under a Goodhart guard
8weekly HEAVY budget (N×3h/week); global fixed H=1OWNER INPUTN controls weekly work only; HEAVY is never parallel and is independent of FAST K
Figure 7 — D051's sequenced implementation contract. 0a, 0b, and 5 are deployed; 1–4 and 6–7 are decided but not implemented, and 8 still requires an owner-supplied weekly HEAVY budget. Item 5's LIVE status comes from the 2026-07-27 verification of rolling.sh, running processes, and wk1–wk88 logs; it does not mean that the deterministic scheduler (item 4) has been implemented.

Goodhart guard and the sole north star

proposal-ready count is the sole north star: feasibility closed ∧ no open FATAL ∧ draft sections complete. Velocity is decisive-evidence delta per champion-week; review efficiency is (FATAL+REFRAME)/R4-shift. These metrics may influence scheduling, but they cannot replace scientific judgment or become a declaration of proposal success.