Three architectures, four stages

One agent, a decentralised swarm of three with no shared state, and a centralised swarm of three under an orchestrator, each given the same total budget and byte-identical inputs, measured at four stages of the DELPHI stack: writing a nanopublication, formalising a claim in Lean 4, specifying a design the studio accepts, and reporting what validate_generation actually said. Graded by the repository's own checks, not by a checker written for the experiment.

Each stage, all three arms, cost beside quality

One figure per stage. Hue is fixed per arm across all four figures, so an arm can be tracked from stage to stage. Each quality bar carries its min–max spread as a whisker and its three per-task scores as dots, because with n = 3 the spread carries more information than the mean. Click any bar to open the runs behind it.

Every run, traceable to its log

Thirty-six cells: three arms × four stages × three tasks. Each row opens the prompt as it was sent, the model's raw output, the tokens, the wall time, the stop reason, and the grader's verdict with its per-check reasoning. Harness failures, budget cap stops and architecture failures are three different columns.

What the merge rule threw away

The decentralised arm merges by a fixed, oracle-free medoid vote: keep the candidate most agreed with by the other two. That rule never consults a grader, so it can discard a better answer. How often it did is a property of the merge rule, not of the architecture, and is reported as such.

Post hoc: the centralised arm's budget, split unevenly

What this cannot support

Pre-registration: swarm/benchmark/ARMS.md, written before the first call. Numbers on this page are read from data.json, which is built from the run files by swarm/benchmark/publish.mjs and holds nothing that is not in them. Deviations and post-hoc corrections: swarm/benchmark/RESULTS.md.