Paper deep dive
Maestro Order: A Model-Agnostic Orchestration Harness
Hidayet Aksu
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 93%
Last extracted: 7/9/2026, 7:26:19 AM
Summary
Maestro Order is a model-agnostic orchestration harness that transforms unreliable language models into reliable problem-solving systems by composing four structural primitives (decompose, ensemble, verify, recurse) and a budget-aware controller. It treats models as black-box solvers, layers a verifier ensemble with online discrimination measurement, and allocates compute to maximize marginal reliability per unit cost. The paper details the architecture, state schema, controller algorithm, and evaluation methodology, demonstrating through Monte Carlo simulation that verification amplifies reliability geometrically while voting is limited by error correlation. It also catalogs failure modes like verifier gaming and correlated errors, providing engineering guidance for robust checkers and diversified solvers.
Entities (10)
Relation Signals (10)
Maestro Order â implements â Four Structural Primitives
confidence 97% · composing them according to four structural primitives (decompose, ensemble, verify, and recurse)
Maestro Order â employs â Budget-Aware Controller
confidence 96% · and a budget-aware controller that decides where to spend compute.
Budget-Aware Controller â allocates â compute to Verifier Ensemble & Voting
confidence 94% · allocates verification and voting to the stages with the highest marginal reliability per unit cost.
Verifier Ensemble â measures â Discrimination
confidence 93% · layers a verifier ensemble whose discrimination is measured online
Budget-Aware Controller â uses â calibrated log-odds
confidence 93% · I1: Confidence is calibrated log-odds. Every commitment carries a confidence that is, after calibration, the true log-odds of correctness.
Blackboard â stores â state and execution traces
confidence 92% · The blackboard holds shared state and traces
Tool Sandbox â provides â robust verifiers
confidence 91% · the tool sandbox supplies robust verifiers (execution, tests, search)
Monte Carlo Simulation â validates â Reliability Amplification Laws
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:A single forward pass of a capable model is a fast, fluent, and unreliable problem-solver: it is right often enough to be useful and wrong often enough to be dangerous; in language models, such confident errors are known as hallucinations. We present Maestro Order, a model-agnostic orchestration harness that turns unreliable solvers into reliable problem-solving systems by composing them according to four structural primitives (decompose, ensemble, verify, and recurse) and a budget-aware controller that decides where to spend compute. The harness treats any model as a black-box base solver behind a uniform interface, layers a verifier ensemble whose discrimination is measured online, and allocates verification and voting to the stages with the highest marginal reliability per unit cost. We give the architecture, the message and state schema, the controller algorithm, and the engineering that makes it deterministic, observable, and fault-tolerant. We then specify an evaluation methodology (reliability at fixed cost, coverage, calibration, and ablations) and report results from a faithful Monte Carlo simulation of the harness over a parameterized solver/verifier model. The simulation reproduces the predicted laws quantitatively: verification amplifies reliability geometrically (e.g. $0.55\to0.98$ with two gates, $\to0.999$ with four), voting helps only above chance and is limited by shared errors, and a budget-aware controller reaches a target reliability at a small fraction of the cost of voting alone by selecting the cheapest mechanism for each regime. We close with failure modes (verifier gaming, correlated errors, and decomposition error compounding) and concrete guidance: build robust checkers, diversify solvers, and let the controller put compute where the information is.
Tags
Links
- Source: https://arxiv.org/abs/2606.23983v1
- Canonical: https://arxiv.org/abs/2606.23983v1
Trouble viewing inline? Open PDF directly â
Full Text
55,850 characters extracted from source content.
Expand or collapse full text
Maestro Order: A Model-Agnostic Orchestration Harness On Organizing Intelligence for Reliable Problem Solving Hidayet Aksu hidayetaksu@gmail.com Abstract. A single forward pass of a capable model is a fast, fluent, and unreliable problem-solver: it is right often enough to be useful and wrong often enough to be dangerous; in language models, such confident errors are known as hallucinations. We present Maestro Order, a model-agnostic orchestration harness that turns unreliable solvers into reliable problem-solving systems by composing them according to four structural primitives (decompose, ensemble, verify, and recurse) and a budget-aware controller that decides where to spend compute. The harness treats any model as a black-box base solver behind a uniform interface, layers a verifier ensemble whose discrimination is measured online, and allocates verification and voting to the stages with the highest marginal reliability per unit cost. We give the architecture, the message and state schema, the controller algorithm, and the engineering that makes it deterministic, observable, and fault-tolerant. We then specify an evaluation methodology (reliability at fixed cost, coverage, calibration, and ablations) and report results from a faithful Monte Carlo simulation of the harness over a parameterized solver/verifier model. The simulation reproduces the predicted laws quantitatively: verification amplifies reliability geometrically (e.g. 0.55â0.980.55â 0.98 with two gates, â0.999â 0.999 with four), voting helps only above chance and is limited by shared errors, and a budget-aware controller reaches a target reliability at a small fraction of the cost of voting alone by selecting the cheapest mechanism for each regime. We close with failure modes (verifier gaming, correlated errors, and decomposition error compounding) and concrete guidance: build robust checkers, diversify solvers, and let the controller put compute where the information is. Maestro Order is the framework layer of a two-part program (Theory: Odds Law â Framework: Maestro Order), built on the laws of the companion Odds Law report. LLM orchestration, agents, verification, self-consistency, test-time compute, reliability, ensembles, scaffolding, evaluation, hallucination mitigation, long-horizon agents â copyright: none11footnotetext: Code and reproduction scripts: https://github.com/hidayetaksu/maestro-order 1. Introduction Modern models answer hard questions in one shot with impressive fluency and uneven reliability. For deployment, where a wrong answer has a cost, the relevant question is not âhow good is the model on average?â but âhow do we build a system whose answers we can trust at a known cost?â The same question recurs across substrates: a research group made of fallible people, a compiler made trustworthy by its test suite, a distributed job made correct by re-execution. The answer, in every case, is organization: many unreliable attempts, arranged so their errors are caught and outvoted. Two failure patterns make this urgent for language models: hallucination, the confident generation of incorrect or unsupported content, and the compounding of small per-step error rates that makes long-running, multi-step jobs fail almost surely without correction. This paper is the applied counterpart to a companion theory report, Odds Law (companion, ), which shows that a small algebra of four combinators (sequential decomposition, parallel ensembling, verification gating, and recursion) generates the organizations that solve problems reliably, and that reliability flows through them by explicit laws (most importantly, a verification gate multiplies the odds of correctness by the verifierâs likelihood ratio). Here we turn those laws into a running system: a harness that wraps any model as a base solver and composes solvers and verifiers under a controller that spends compute where it buys the most reliability. Why a harness, not a better model. Three properties make orchestration attractive and complementary to improving the base model. (i) Generateâverify asymmetry: for many tasks, checking a candidate (run the tests, recompute the sum, search for a counterexample) is far cheaper and more reliable than producing it; this is exactly the regime where verification gating pays off. (i) Test-time compute is elastic: a harness can trade more calls for more reliability on the instances that need it, and abstain or escalate on the rest. (i) Model-agnosticism: the same scaffolding improves whatever model sits behind the interface, and survives model upgrades. Contributions. âą A model-agnostic harness architecture (§4â§6) that instantiates the four combinators as composable components (planner, solver pool, verifier ensemble, aggregator, controller, blackboard, and tool sandbox) behind a uniform solver interface. âą A budget-aware controller (§7) that allocates voting and verification by greedy marginal log-odds per unit cost, the operational form of the theoryâs water-filling optimum (spend where the return is highest until all options return the same), with online estimation of verifier discrimination Î . âą An engineering account (§11) of determinism, idempotency, concurrency, cost accounting, and tracing required to make reliability measurable and reproducible. âą An evaluation methodology and simulation study (§12â§13) that reproduces the predicted reliability laws and quantifies the cost of voting vs. verification, the diversity floor, and the value of abstention. âą A catalog of failure modes and mitigations (§15): verifier gaming (Goodhart), correlated solver errors, and decomposition error compounding. âą An open-source release of the harness code, simulation, and reproduction scripts at https://github.com/hidayetaksu/maestro-order. 2. Background and Related Work Eliciting and aggregating reasoning. Chain-of-thought prompting elicits intermediate steps (wei2022cot, ); self-consistency samples many chains and takes the majority answer, the voting combinator in practice (wang2023selfconsistency, ). Tree-of-thoughts searches over partial solutions with look-ahead (yao2023tot, ), a decomposition-plus-search organization. Acting, checking, and refining. ReAct interleaves reasoning with tool actions (yao2023react, ); Reflexion (shinn2023reflexion, ) and Self-Refine (madaan2023selfrefine, ) iterate generateâcritiqueârevise loops; multi-agent debate has models cross-examine each other (du2023debate, ). These are instances of verification and refinement with the model (or a tool) as verifier. Verifiers and process supervision. Training explicit verifiers improves math word-problem reliability (cobbe2021verifiers, ); process-level reward models that check each step outperform outcome-only checks (lightman2023verify, ); âLLM-as-judgeâ uses a model to score candidates (zheng2023judge, ). Our harness treats any such checker as a gate and measures its discrimination Î online. Tools, retrieval, and code execution. Grounding answers in retrieval (lewis2020rag, ), tool use (schick2023toolformer, ), and program execution / unit tests (chen2021codex, ) supplies robust verifiers whose false-acceptance is bounded independently of how the candidate was produced, which is precisely the property the theory shows is needed under optimization pressure. Retrieval grounding is also a primary defense against hallucination (ji2023hallucination, ). Reliable systems from unreliable parts. The organizing idea predates models: von Neumannâs reliable automata from unreliable components (vonneumann1956, ), Condorcetâs jury theorem (condorcet1785, ), and divide-and-conquer in distributed systems (dean2004, ). Our harness is a contemporary, model-agnostic realization, and our companion paper (companion, ) supplies the reliability calculus it optimizes. How this work differs. Most of the techniques above are studied and deployed in isolation: self-consistency or a verifier or refinement, each used as a separate technique. Our contribution is to treat them as instances of one algebra and to put a controller in charge of choosing among them per instance under an explicit budget, guided by the reliability laws. Two consequences distinguish the approach. First, the harness measures verifier discrimination Î online and credits each mechanism only with the amplification its measured quality supports, rather than fixing a pipeline in advance. Second, by reporting reliability at a measured cost and selecting the cheapest configuration that meets a target, it makes the costâreliability trade-off an explicit, tunable quantity instead of an implicit side effect of a prompt template. The aim is not a new trick but a principled way to compose the existing ones. 3. From Algebra to Architecture The harness is a direct compilation of the four combinators into runtime components. Table 1 gives the correspondence; the rest of the paper elaborates each row and the controller that composes them. Table 1. The four combinators and their harness realization. The reliability law column summarizes the companion theory (companion, ). Combinator Harness component Reliability law Sequential Planner / decomposer errors compound (âÏiÎ _i) Parallel Voter / aggregator amplify if p>12p> 12 Verify Verifier ensemble + gate odds ĂÎĂ\, per gate Recurse Recursive dispatch union bound over nodes Three design principles follow from the laws. First, check more than you decompose: since sequential decomposition can only lose reliability, every decomposition boundary should be paired with a verifier that restores it. Second, prefer verification to voting when a discriminating checker exists: a single gate with Î=6 =6 outperforms dozens of votes for a near-threshold solver. Third, spend at the margin: allocate the next unit of compute to whichever stage currently offers the largest reliability gain per call. The controller (§7) implements all three. 4. Harness Architecture Controller(budget, policy)Planner /DecomposerSolver pool(roles, temps)VerifierensembleAggregator /GateBlackboard(state, traces)Tool sandbox(exec, search)refine/escalateproblem xxanswer / â„ Figure 1. Harness architecture. The controller allocates a compute budget across decomposition, voting, and verification; the blackboard holds shared state and traces; the tool sandbox supplies robust verifiers (execution, tests, search). Arrows show data and control flow; the refine/escalate edge closes the verify loop. Figure 1 shows the components. Everything is built on one abstraction. The solver interface. A base solver exposes solve(task, ctx) -> answer, score, trace, cost. Any model, tool, or sub-harness implements it, so components compose uniformly and the controller can treat a whole subtree as a single solver. score is a self-reported confidence (used only as a weak prior); trace feeds the blackboard; cost is the realized call/token count. The blackboard record. All components read and write a single structured record, which is also the unit of tracing and replay: Solve task: id, type, input, deps[] budget: max_calls, target_rel, lambda cands: [answer, score, trace, cost] verdicts:[verifier_id, accept, score, est_beta, est_alpha] state: logodds, calls, coverage result: answer | ABSTAIN, confidence Figure 2. Blackboard record (simplified). The controller reads state.logodds and per-mechanism marginal estimates to decide the next action; verdicts carry the online ÎČ^,α ÎČ, α used to compute Î . Planner / decomposer. Given a task, the planner optionally emits a typed plan: a DAG of subtasks with dependencies and a recombination step. Decomposition is applied only when the plannerâs confidence in a clean split is high, since unguarded decomposition compounds error (Table 1); each subtask boundary is annotated with the verifier to apply on recombination. Solver pool. A configurable set of solver roles (for example, different prompts, temperatures, tools, or distinct models) provides the diversity that voting needs. The pool composition is the main control on error correlation Îł (§13); pools of near-identical solvers vote poorly. Verifier ensemble. One or more verifiers, each a checker returning accept/reject with a score: deterministic tools (unit tests, type-checkers, math re-evaluation, retrieval corroboration) and model-based critics. Each verifierâs completeness ÎČ and false-acceptance α are estimated online (§7); the gate uses the calibrated log-likelihood ratio as its acceptance score. Aggregator / gate. Combines candidates: plurality or score-weighted voting, verified selection (return the highest-scoring accepted candidate), or all-accept gating for amplification. Emits an answer or â„ (abstain) with a calibrated confidence. Blackboard and tool sandbox. A shared store holds intermediate results, verifier verdicts, and a full execution trace for observability and replay. The tool sandbox executes untrusted code and runs searches in isolation, supplying the robust verifiers the theory privileges. 5. Design Rationale and System Invariants A reliability harness is only trustworthy if its guarantees hold regardless of what the wrapped model does. We therefore design around a small set of invariants that the components must preserve and that the companion theory (companion, ) shows are sufficient for the reliability laws to apply. I1: Confidence is calibrated log-odds. Every commitment carries a confidence that is, after calibration, the true log-odds of correctness. This single invariant makes the rest composable: gates add to it (the odds law), abstention thresholds it (Chowâs rule), and the controller maximizes it per unit cost. Components that cannot expose a calibrated score are wrapped by a calibration map fit on held-out data; uncalibrated raw scores are never used for decisions, only as weak priors. I2: Fail closed. Any ambiguity, such as a tool error, a timeout, a malformed candidate, or a verifier crash, is treated as a rejection, never as a silent accept. This keeps the false-acceptance rate α bounded by the verifierâs genuine error rather than by infrastructure flakiness, which is what makes the discrimination Î=ÎČ/α =ÎČ/α meaningful and stable. A harness that failed open would see its Î collapse under load exactly when reliability matters most. I3: Monotone confidence. Adding work never decreases the systemâs information about an instance: a new vote or gate can only sharpen the posterior, and the controller never discards evidence. This guarantees that spending more budget weakly improves reliability (the refinement order of the theory), so the costâreliability curve is monotone and the controllerâs greedy ascent is well-defined. I4: Budget conservation and accountability. Every call is attributed to a stage and counted against the budget before it is made; the controller cannot overspend, and every reported reliability number has an associated, measured cost. Reliability claims without cost are meaningless, so the two are always reported together. I5: Determinism up to declared randomness. Given fixed seeds and backend versions, a solve is replayable bit-for-bit from its trace. Randomness enters only where declared (sampling temperatures, vote seeds), so experiments are reproducible and regressions are diagnosable. These five invariants are the contract every component signs; the mechanisms below are implementations that honor it. 6. Reliability Mechanisms The harness exposes the combinators as mechanisms the controller can deploy per instance. Self-consistency voting. Sample n diverse candidates and return the plurality answer; reliability rises with n when per-sample correctness exceeds 12 12 and errors are diverse (§13). Cheap, model-only, but bounded by the correlation floor. Verified selection and gating. Run candidates through the verifier ensemble; either select the best accepted candidate or, for amplification, require all k gates to accept, regenerating otherwise (Algorithm 1). Each accepted gate multiplies the odds of correctness by its Î . Iterative refinement. On rejection, return the verifierâs critique to the solver and resample, a generateâcritiqueârevise loop. Refinement raises the per-attempt success probability p, which compounds with gating. Debate and cross-examination. Independent solvers critique each otherâs candidates; disagreement is a cheap signal that routes an instance toward more verification or abstention. Abstention and escalation. When the accumulated log-odds score falls below a calibrated threshold, the harness abstains or escalates to a stronger (costlier) sub-organization: selective answering on the riskâcoverage frontier (§13). Algorithm 1: VerifyGate: amplify a candidate by all-accept gating 1:input: generator g, verifiers v1..vkv_1..v_k, budget T 2:for t=1t=1 to T do 3: aâg.solveâ(x)aâ g. solve(x) âł sample a candidate 4: if âi:vi.accept(x,a)â i:\ v_i. accept(x,a) then 5: return a with odds âiÎi _i _i applied 6: end if 7:end for 8:return â„ âł abstain after T rejections 7. The Budget-Aware Controller The controller decides, per instance, how to spend a compute budget Îș across the mechanisms. By the companion theory the reliability-maximizing allocation equalizes the marginal log-odds gain per unit cost across stages; the controller approximates this by greedy selection (Algorithm 2). Algorithm 2: Controller: greedy marginal allocation 1:input: task x, budget Îș, mechanism set âłM 2:ÏâÏâ single base solve; estimate log-odds â 3:while costâ(Ï)<Îș cost(Ï)<Îș and not converged do 4: for mââłm do âł vote+n+n, add gate, refine, decompose 5: r^mâÎââ^â(m)/Îâcostâ(m) r_mâ (m)/ cost(m) âł est. marginal log-odds per call 6: end for 7: mââargâmaxmâĄr^m â *arg\,max_m r_m 8: if r^mââ€Î» r_m â€Î» then break âł saturated 9: end if 10: Ïâapplyâ(mâ,Ï)Ïâ apply(m ,Ï); update â 11:end while 12:return aggregate(Ï) or â„ if â<Ï <Ï Online estimation of verifier discrimination. The controller maintains running estimates of each verifierâs ÎČ and α from instances where ground truth is later revealed (tool oracles, held-out checks, or human spot-checks), yielding Î^=ÎČ^/α = ÎČ/ α and hence Îââ^=logâĄÎ = for the gate mechanism. Verifiers whose estimated Î drifts toward 11 are demoted, an explicit guard against the gaming failure mode (§15). Votingâs marginal gain is estimated from the current vote margin via a Chernoff exponent. Calibration. Raw model and judge scores are poorly calibrated, so the controller fits a monotone calibration map (e.g. isotonic/Platt) from scores to empirical correctness, and uses calibrated log-odds both as the gate score and as the abstention threshold (Chowâs rule: commit only when the calibrated posterior clears a cost-based threshold). Calibration quality is reported as expected calibration error (ECE) in §13. 8. Engineering Robust Verifiers Because verification is the high-leverage mechanism (§13) and because gameable verifiers are the dominant failure mode (§15), the verifier ensemble deserves the most engineering attention. The goal is high discrimination Î=ÎČ/α =ÎČ/α that is robust: it must hold even when candidates are produced by a process optimizing for acceptance. Prefer ground-truth checks. The most robust verifiers reduce to executing a specification rather than judging plausibility. For code, run the candidate against unit tests, property-based tests, type-checkers, and sanitizers in the sandbox; for mathematics, re-evaluate numerically, check units and boundary cases, or machine-check a proof; for factual claims, corroborate against retrieved sources and require citation support. The defining property is that their false-acceptance rate is bounded by the specification, not by how the candidate was generated, so α does not rise under optimization pressure and Î stays high. Make model-based judges as robust as possible. When only a model can check (open-ended reasoning, style, subtle correctness), several techniques raise and stabilize Î : ask the judge to find a counterexample or a concrete flaw rather than to rate quality (refutation is harder to game than approval); require the judge to show its check (a verification chain-of-thought) and verify that; use a judge that is independent of the generator (a different model, prompt, or seed) to keep verifier and generator errors conditionally independent; and combine several judges so that a single exploitable blind spot does not dominate. Each independent, informative judge contributes additively to the log-odds (the odds law), so a panel of diverse weak judges can rival a single strong one, subject to the same correlation floor that limits voting. Measure Î , do not assume it. The controller treats every verifierâs (ÎČ,α)(ÎČ,α) as quantities to be estimated, not declared. Wherever ground truth eventually becomes available (a tool oracle, a downstream outcome, a held-out labeled stream, or human spot-checks), the harness updates running estimates ÎČ^,α ÎČ, α and hence Î . A verifier is only credited with the amplification its measured discrimination supports; nominal accuracy on a benign distribution is never trusted on its own. Detect and resist drift. Under sustained optimization, a verifierâs effective α tends to rise as generators discover what it wrongly accepts: Goodhartâs law in action. The harness watches Î over time and, when it drifts toward 11, reduces that verifierâs weight, rotates in fresh or held-out checkers, and raises the abstention threshold for affected instances. Disagreement among diverse verifiers is itself a cheap early-warning signal: a sudden rise in unanimous acceptance with falling downstream correctness is the signature of a gamed gate. Tune the operating point. A verifier exposes a threshold trading completeness ÎČ against false-acceptance α (its ROC curve). For amplification the harness prefers a high-ÎČ/low-α operating point even at the cost of more regenerations, because Î , not throughput, governs the reachable reliability; for inexpensive screening it may accept lower ÎČ. The controller selects the operating point per instance from the marginal-rate calculus. 9. Decomposition and Planning in Practice Decomposition is the riskiest combinator: by the serial law it can only lose reliability unless each boundary is restored by verification. The planner is therefore conservative by design. Decompose only when the split is clean and checkable. The planner proposes a decomposition only when it is confident the subproblems are (i) genuinely independent or cleanly ordered, and (i) each individually verifiable. A split into subproblems that cannot be checked inherits the worst of both worlds (more stages that can fail, and no way to catch the failures), and the planner declines it in favor of a monolithic solve plus verification. This is the operational reading of the recursion master theorem: depth is affordable precisely when every level is gated. Typed plans and verified recombination. A plan is a typed DAG: each node declares its input and output types, its dependencies, and the verifier to apply to its result and to the recombination. Type compatibility is checked statically before any model call, catching a class of decomposition errors for free. The recombination step is itself a gated solver, so a correct assembly of correct parts is verified rather than assumed. Interleaving planning and acting. For tasks where the right decomposition is not knowable up front, the harness interleaves planning with acting: solve a subproblem, observe the result and its verdict on the blackboard, and let the planner revise the remaining plan. This keeps decomposition adaptive while preserving the invariant that every committed intermediate has passed a gate, so errors do not silently propagate down the tree. Budgeting across the tree. The controller allocates the global budget across plan nodes by the same marginal-rate rule, spending more verification on nodes whose errors are most likely to corrupt the final answer (those with high fan-out or on the critical path) and less on cheap and easily checked leaves. The result is the verifier-saturated, marginal-rate-equalizing organization the theory predicts, realized at the granularity of a plan. 10. Anatomy of a Solve To make the controller concrete, Table 2 shows the controllerâs expected progress with a weak base solver (p0=0.55p_0=0.55) and a robust verifier (Î=6 =6, so each accepted gate adds logâĄ6=1.79 6=1.79 to the log-odds). The controller starts with one base solve, then repeatedly adds the highest-rate mechanism (here, another verification gate), updating the running log-odds and cost, until the calibrated log-odds clears the target threshold or the marginal rate drops below λ. The reliabilities and call counts are the measured simulation values of §13; the log-odds column is their logit. Table 2. A controller trace (simulation). Each gate multiplies the odds by Î=6 =6 (+1.79+1.79 log-odds); reliability saturates while cost grows linearly. The controller stops at the first row that meets the target, or when the next gateâs marginal rate falls below λ. Step Action Îââ â Pâ(corr)P(corr) calls 0 base solve â 0.20 0.550 1.0 1 + verify gate 1.79 1.99 0.880 3.8 2 + verify gate 1.79 3.78 0.978 7.4 3 + verify gate 1.79 5.58 0.996 11.7 4 + verify gate 1.79 7.37 0.999 17.3 stop: the next gate would offer Îââ/Îâcallsâ0.25<λ / â 0.25<λ The trace exhibits the law operationally: the benefit per gate is constant in log-odds (+1.79+1.79) but the cost per gate grows (each gate lowers acceptance probability, so more regenerations are needed), which is why the marginal rate falls and the controller eventually stops. A target of 0.970.97 is met at step 2 (7.4 calls) and 0.9990.999 at step 4 (17.3 calls). Voting alone from this near-threshold base would need several hundred calls for the same targets (Fig. 4(b)). 11. Implementation Concerns Reliability claims are only as trustworthy as the plumbing beneath them. Determinism and reproducibility. Each solve records model id, decoding parameters, seed, prompt hash, and tool versions; runs are replayable from the trace. Stochastic steps (sampling, voting) fix seeds per attempt so an experiment is bit-reproducible given the same backends. Idempotency and caching. Solver and verifier calls are keyed by (input, config) and cached, so retries and refinement loops do not double-bill and so ablations reuse work. Concurrency. Independent candidates and verifiers run in parallel; the controller bounds fan-out by the remaining budget and merges results on the blackboard. Failure handling. Tool/model errors are treated as rejections (fail closed), never as silent acceptances; timeouts count toward cost and trigger escalation or abstention rather than a guess. Cost accounting and observability. Every callâs token and latency cost is attributed to a stage, so the reliabilityâcost curves of §13 are measured, not estimated, and per-stage marginal rates are visible to the controller and to operators. Scheduling and backpressure. The controller issues independent candidate and verifier calls concurrently up to a fan-out bounded by the remaining budget and backend rate limits; results stream onto the blackboard and the controller re-plans as each arrives. Under load it applies backpressure by lowering fan-out and raising the marginal-rate threshold λ, gracefully degrading from a high-reliability profile to a cheaper one rather than violating latency budgets. Sandboxing and security. Tool verifiers (code execution, shell, search) run in an isolated sandbox with no access to secrets or the host, because robust verification often means executing untrusted candidate code. Sandbox failures are rejections (invariant I2), and resource limits (CPU, memory, wall-clock) are enforced per call so a pathological candidate cannot exhaust the budget. Regression testing the harness itself. Because solves are replayable, a fixed suite of recorded instances doubles as a regression test: a change to a prompt, verifier, or controller policy is evaluated by re-running the suite and comparing reliability-at-cost and calibration, catching silent degradations before they reach production. 12. Evaluation Methodology We evaluate the harness along four axes. Metrics. (i) Reliability at fixed cost: correctness rate on committed answers at a capped expected number of base calls. (i) Coverage and the riskâcoverage curve (and its area, AURC) for selective answering. (i) Calibration (ECE) of the harness confidence. (iv) Cost (expected base calls) and latency. Ablations. We vary the vote count n, the number of gates k, decomposition depth, verifier quality Î , and solver diversity (correlation Îł), isolating each combinatorâs contribution. Statistical methodology. Each reported point is an average over many i.i.d. trials with fixed seeds; we report it with a binomial confidence interval and treat differences smaller than the interval as noise. Because the harness is deterministic up to declared randomness (invariant I5), any reported number is reproducible from the recorded seeds and backend versions, and ablations reuse cached calls so that only the varied factor changes. Protocol for real models. The harness is designed to be evaluated on standard suites (grade-school and competition math, code synthesis with execution-based verifiers, and open-domain QA with retrieval corroboration) using standard metrics: pass@k accuracy, execution pass rate, and exact match, with the deterministic-replay machinery of §11. Simulation study (this paper). To exercise the controller and validate that the implementation obeys the predicted laws without conflating harness behavior with any particular modelâs idiosyncrasies, we report a faithful Monte Carlo simulation of the harness over a parameterized solver/verifier model: a generator emits a correct candidate with probability p; each verifier accepts a correct candidate with probability ÎČ and a wrong one with probability α (Î=ÎČ/α =ÎČ/α); correlated solver pools are produced by a Gaussian-copula latent factor with pairwise correlation Îł. We emphasize that the numbers below are simulation outputs, not measurements of a deployed model; they test the harness logic and the theory, and set expectations for the real-model protocol above. Each point uses between 2Ă1042Ă 10^4 and 4Ă1044Ă 10^4 trials; repeated runs differ by Monte Carlo noise of roughly ±0.004± 0.004 in reliability and ±0.1± 0.1 in expected calls, which explains small discrepancies between tables. Every number, figure, and table in this paper can be regenerated exactly with the released code (§18). 13. Results Verification amplifies as the odds law predicts. Figure 4(a) overlays simulated gate reliability on the theoretical prediction rk=o0âÎk/(1+o0âÎk)r_k=o_0 ^k/(1+o_0 ^k) for a strong (Î=8 =8) and a weak (Î=2 =2) verifier, starting from p0=0.55p_0=0.55. The simulation tracks theory to within Monte Carlo noise: three strong gates take the base from 0.550.55 to 0.9980.998, and because 83=298^3=2^9 the weak verifier needs exactly three times as many gates for the same odds gain. Across all gate counts and both verifiers the simulated reliabilities agree with the closed-form odds law to within ±0.004± 0.004 (the binomial standard error at our trial counts), and the controller trace of Table 2 reproduces the same values, evidence that the implementation faithfully realizes the algebra rather than merely being inspired by it. This agreement is the point of the simulation: it validates the harness logic and isolates it from any particular modelâs quirks before a real-model evaluation introduces them. Verification dominates voting on the cost frontier. Figure 4(b) plots reliability against expected base calls. A verifier with Î=6 =6 reaches 0.980.98 within eight calls and 0.9970.997 within twelve; majority voting on a p=0.62p=0.62 solver needs about 9090 calls to pass 0.990.99, and a near-threshold solver barely improves at all. This is the practical form of the Îâ(logâĄ1ÎŽ) ( 1ÎŽ) scaling, with very different constants. Figure 3. Controller trajectories (simulation): reliability versus cumulative base calls for three strategies on a weak base (p0=0.55p_0=0.55). Verification and the hybrid strategy reach high reliability at an order of magnitude lower cost than voting; the controller follows whichever trajectory has the steepest current slope. The controller follows the steepest trajectory. Figure 3 plots reliability against cumulative cost for verify-only, vote-only, and a hybrid that votes over three candidates before gating. Verify-only reaches 0.9990.999 at about 1717 calls and the hybrid at about 2323; vote-only is still below 0.980.98 at 6060 calls. The controllerâs greedy policy (Algorithm 2) is a walk up whichever trajectory is locally steepest, and the figure shows why it would choose gates from the start here: from p0=0.55p_0=0.55, the first gate offers about 0.640.64 log-odds per call, while extra votes offer about 0.050.05 (a 33-vote lifts 0.550.55 only to 0.5750.575). Voting becomes the better first move only when the vote margin is large or the verifier is weak; the controller detects which regime it is in from the measured marginal rates instead of committing to a fixed pipeline. Diversity sets a hard ceiling on voting. Figure 4(c) shows majority reliability versus committee size for error correlations Îłâ0,0.05,0.2Îłâ\0,0.05,0.2\ under the Gaussian-copula model. Independent solvers approach 11; at Îł=0.05Îł=0.05 reliability plateaus near 0.850.85 and at Îł=0.2Îł=0.2 near 0.710.71, no matter how many correlated members are added. The plateaus match the shared-cause floor of the companion theory (companion, ): with p=0.6p=0.6, the predicted asymptotic limits (the probability that the shared factor keeps the committee above chance) are 0.870.87 for Îł=0.05Îł=0.05 (the n=255n=255 committee is still approaching it) and 0.710.71 for Îł=0.2Îł=0.2. Diversifying the solver pool (varied prompts, temperatures, models) is therefore a primary reliability decision, not a detail. Abstention buys reliability cheaply. Figure 4(d) is the riskâcoverage curve from a calibrated harness score: committing only on the most-confident 20%20\% of instances drops the error rate from 0.450.45 (no abstention) to under 0.10.1. Selective answering plus escalation is the cheapest reliability available when full coverage is not required. The hybrid controller wins. Table 3 ablates the mechanisms from a weak base (p0=0.55p_0=0.55, Î=6 =6). Voting alone is nearly useless this close to threshold (0.55â0.590.55â 0.59); two gates reach 0.9780.978 at 7.47.4 calls; four gates reach 0.9990.999. Combining a small vote with gating gives the best reliability-per-call at the high end. The controllerâs job is to pick the point on this surface that meets the target at least cost: here, âverify k=2k=2â for a 0.970.97 target and âk=4k=4â for 0.9990.999. (a) amplification vs. theory (b) costâreliability (c) diversity floor (d) riskâcoverage Figure 4. Simulation results (Monte Carlo over the parameterized solver/verifier model; not measurements of a deployed model). (a) gate reliability matches the odds law; (b) verification reaches a target at far lower cost than voting; (c) error correlation caps voting gains; (d) abstention trades coverage for reliability. Table 3. Ablation (simulation): reliability, coverage, and expected base calls for harness configurations on a weak base (p0=0.55p_0=0.55, verifier Î=6 =6, T=20T=20). Hybrid configurations dominate at the high-reliability end. Configuration Reliability Coverage Calls single shot 0.549 1.000 1.0 vote n=5 0.591 1.000 5.0 verify k=2 0.978 1.000 7.4 verify k=4 0.999 0.999 17.4 vote5 + verify k=2 0.980 1.000 16.0 vote5 + verify k=4 0.999 1.000 28.8 13.1. Sensitivity to verifier quality and base reliability The two parameters that matter most are the verifier discrimination Î and the base reliability p0p_0, and their effects are exactly those the theory prescribes. The number of gates to reach a target scales as 1/logâĄÎ1/ , which is why the Î=8 =8 curve in Figure 4(a) needs one third of the gates of the Î=2 =2 curve (logâĄ8=3âlogâĄ2 8=3 2). A higher base p0p_0 shifts the whole costâreliability frontier left by the additive term logâĄp01âp0 p_01-p_0 in the log-odds, so a stronger base solver needs fewer gates for the same target but does not change the geometric character of the amplification. The practical implication: because the required depth is divided by logâĄÎ , a modest improvement in the verifier multiplies through the entire frontier, and often helps more than a large increase in vote count or a slightly better base model. This is the empirical form of the theoryâs recommendation to invest in robust checkers. Calibration. The selective-answering results (Fig. 4(d)) depend on the harness confidence being calibrated: the abstention threshold is only meaningful if a reported 0.90.9 confidence corresponds to a 0.90.9 empirical correctness rate. After fitting the monotone calibration map of §7, the harness confidence is well-calibrated by construction in the simulation, so the riskâcoverage curve is the true achievable frontier; on real models, calibration error (ECE) would be reported alongside it, and miscalibration would manifest as a gap between the nominal threshold and the realized risk. Calibration is thus not a cosmetic metric but the precondition that makes abstention and gating trustworthy. 13.2. Deployment profiles and cost-to-target Operators rarely tune individual mechanisms; they pick a profile and a target. Table 4 distills the ablation into three profiles, and Table 5 inverts the relationship: given a reliability target, the cheapest configuration the controller selects and its expected cost. The pattern is clear: each order-of-magnitude reduction in error costs only a few more calls under verification, because cost grows with logâĄ1ÎŽ 1ÎŽ while voting grows far faster. Table 4. Deployment profiles (simulation, p0=0.55p_0=0.55, Î=6 =6). Profile Mechanisms Reliability Calls Cheap single solve 0.55 1.0 Balanced vote 5 + verify k=2k=2 0.98 16.0 High-reliability verify k=4k=4 (+abstain) 0.999 17.3 Table 5. Cost-to-target (simulation). Verification reaches each target with slowly growing incremental cost; the voting-only column is the approximate cost for a p=0.62p=0.62 solver (normal approximation) and is roughly an order of magnitude larger. Target reliability Config Verify calls Voting calls 0.90 k=1k=1 3.8 ⌠27 0.97 k=2k=2 7.4 ⌠60 0.99 k=3k=3 11.7 ⌠90 0.999 k=4k=4 17.3 ⌠160 Summary. The harness reproduces every qualitative prediction of the theory and quantifies the trade-offs an operator faces: verification is the high-leverage mechanism when a discriminating checker exists, voting is a cheap supplement bounded by diversity, and abstention converts confidence into reliability. The controllerâs marginal-rate policy reduces all of these choices to two settings: a target reliability and a budget. 14. Case Studies The same harness specializes to very different tasks by changing only the solver pool and the verifier ensemble; the controller and invariants are unchanged. We sketch three configurations to make the mapping concrete. Grade-school and competition mathematics. The base solver samples chain-of-thought solutions at moderate temperature; diversity comes from multiple seeds and two prompt styles. The verifier ensemble is deliberately robust: a deterministic arithmetic re-evaluator recomputes the final expression, a units and sanity checker rejects out-of-range answers, and, for problems with a checkable form, substitutes the candidate back into the problemâs constraints. Because these checks reduce to executing the problemâs own definition, their false-acceptance is low and stable, so Î is high and the controller leans heavily on gating, falling back to self-consistency voting only when no closed-form check applies. The expected behavior is the amplification curve of Figure 4(a): a few gates take a near-threshold solver to high reliability at modest cost. Program synthesis. Here verification is nearly ideal. The base solver proposes a program; the verifier executes it in the sandbox against unit tests, a type-checker, and property-based fuzzing, with failures counting as rejections (invariant I2). Execution-based checking has very high discrimination: a program that passes a strong test suite is very likely correct, and one that fails is certainly rejected. The controllerâs dominant mechanism is therefore a single high-Î gate plus refinement: on rejection, the failing test output is fed back as a critique and the solver revises. Decomposition appears naturally for multi-function tasks, with each function gated by its own tests before integration; this is the recursion master theorem realized as test-driven assembly. This is the regime where orchestration most clearly beats single-shot generation. Open-domain question answering. Verification is hardest here because correctness is not mechanically checkable. The harness leans on grounding: a retrieval step supplies sources, the solver must answer with citations, and the verifier checks that each claim is supported by a retrieved passage (a corroboration check) and cross-examines with an independent judge model prompted to find unsupported assertions. No single check is decisive, so the controller combines a modest verifier panel with self-consistency over diverse retrievals, and, crucially, sets a conservative abstention threshold, declining or escalating when corroboration is weak. The operating point sits on the riskâcoverage frontier of Figure 4(d): the system answers confidently where sources agree and abstains where they do not, which is the responsible behavior for factual tasks. Adaptive allocation versus fixed pipelines. A fixed pipeline, such as âalways sample five and verify twice,â spends the same budget on every instance, over-paying on easy cases and under-serving hard ones. The controller instead reads each instanceâs running log-odds and stops early when the target is already met, redirecting budget to the instances that need it. Because difficulty is heavy-tailed (most instances are easy, a few are hard), this adaptivity is where much of the practical cost saving comes from: the average cost is dominated by the easy majority, on which the controller commits quickly, while the hard tail receives the deep verification it requires. The fixed pipeline is the special case the controller reduces to when every instance happens to have the same difficulty, which is rare in practice. 15. Discussion: Failure Modes and Guidance Verifier gaming (Goodhart). When solvers are optimized against a fixed checker, the checkerâs effective false-acceptance rises and its discrimination collapses toward Î=1 =1, and amplification silently fails. (This is Goodhartâs law: a proxy measure stops tracking what it was meant to measure once it is optimized directly.) Mitigations: prefer robust verifiers whose soundness is independent of the generator (execution, proofs, types, corroborated retrieval); monitor each verifierâs online Î and demote drifters; rotate or ensemble diverse verifiers; and hold out a ground-truth stream for recalibration. Correlated errors. A pool of near-identical solvers inherits shared blind spots; voting then plateaus far below 11 (Fig. 4(c)). Mitigation: engineer diversity (distinct prompts, temperatures, tools, and ideally distinct models) and measure Îł directly from disagreement rates. Decomposition error compounding. Aggressive decomposition multiplies per-stage error and can underperform a monolithic solve. Mitigation: decompose only when a clean split is confident, and gate every recombination boundary so each level is restored before it propagates; this is the recursion master theorem in practice (companion, ). Cost and latency. Reliability is bought with calls; the controllerâs budget cap and abstention keep total cost bounded, and caching plus parallel fan-out keep latency manageable. The right operating point is application-specific and is exactly the marginal-rate threshold λ. When not to use a harness. Orchestration is not free, and not every task warrants it. For tasks where the base solver is already reliable enough, where no informative verifier exists (Îâ1 â 1), or where latency dominates and a single fast answer is preferable to a slow reliable one, the cheap profile (single solve) is correct and the overhead of voting and gating is waste. The controller makes this an explicit decision: if the estimated marginal rate of every mechanism is below λ from the start, it commits the single solve. The harness adds value exactly in the regime the theory identifies: weak base solvers with discriminating, robust checkers. Interaction with model improvements. A better base model raises p0p_0 and shifts the whole costâreliability curve left: the same target is reached with fewer gates and votes, and the controller spends less by default. Crucially, orchestration and model quality are complements, not substitutes: a stronger model with a robust verifier reaches extreme reliability more cheaply than either alone. The harness therefore remains valuable as models improve, simply operating at a cheaper point. The exception is verification quality: if generation improves faster than checking, the verifier becomes the limiting factor, which reinforces the paperâs central recommendation to invest there. Hallucinations and long-running jobs. Two deployment problems map directly onto the harness. The first is hallucination: a generative modelâs confident production of incorrect or unsupported content (ji2023hallucination, ). This is exactly the failure that calibrated confidence targets: a hallucinated candidate either fails corroboration and test gates and is rejected, or fails to accumulate enough log-odds and becomes an abstention or an escalation. Confident errors are thereby converted into checked refusals. The second is the long-running, multi-step job: because per-step error compounds, even a step that is 99%99\% reliable fails almost surely over hundreds of steps. Verifying every boundary bounds end-to-end error at logarithmic overhead (the recursion master theorem of the companion theory), and idempotent, replayable state lets such jobs checkpoint, suspend, and resume, which is what long-horizon automation requires. Safety. Fail-closed verification (treating errors and timeouts as rejections), calibrated abstention, and full traceability make the harness conservative by construction: when it is unsure, it declines or escalates rather than emitting a confident guess. The full execution trace also makes every answer auditable after the fact (which candidates were generated, which verifiers accepted, and why the controller stopped), itself a requirement for high-stakes deployment. 16. Limitations and Threats to Validity The headline results are simulations of a parameterized model, not measurements of a deployed system; they validate the harness logic and the reliability laws but do not, by themselves, establish absolute numbers on any benchmark. Real models violate the simulationâs clean assumptions: verifier errors are not perfectly conditionally independent, solver correctness is instance-dependent rather than a single p, and ÎČ,α,ÎłÎČ,α,Îł vary across the input distribution. The companion theory (companion, ) bounds the cost of these violations (correlated verifiers lose effective Î ; correlated solvers can hit a floor when shared causes push the committee below chance), and the harness estimates the relevant quantities online, but a full real-model evaluation under the §12 protocol is necessary to claim deployment numbers and is the natural next step. Finally, our controller is greedy; the constrained optimum it approximates can in principle be solved more globally when marginal-rate estimates are reliable. 17. Conclusion Generalization. Although we describe the harness in terms of language models, nothing in the architecture or the controller depends on that choice. A base solver is any process behind the solve interface (a model, a heuristic, a search procedure, a tool, a human, or another harness), and a verifier is anything that returns a calibrated accept/reject. The same controller would organize a pool of human reviewers with an automated checker, or a mix of models and classical algorithms, identically. This is the practical payoff of grounding the system in an algebra over abstract solvers: the harness is a general-purpose organizer of unreliable problem-solving, of which the language-model case is one instance. We presented a model-agnostic harness that organizes unreliable solvers into reliable problem-solving systems by compiling four structural combinators into runtime components and a budget-aware controller that spends compute where it buys the most reliability. A faithful simulation reproduces the predicted laws: geometric amplification by verification, threshold-and-floor behavior of voting, and the value of abstention. It also shows that a controller-driven organization reaches reliability targets at a small fraction of the cost of voting alone, automatically selecting the cheapest mechanism for the regime at hand. The practical message mirrors the theory: build robust checkers, diversify solvers, verify every boundary, and let the controller allocate at the margin. Reliability is not a property of a model; it is a property of how models are organized. 18. Artifact and Reproducibility Statement All experimental results in this paper are Monte Carlo simulations of the parameterized solver/verifier model of §12; no proprietary models, datasets, or services are required to reproduce them. The full source code is publicly available at https://github.com/hidayetaksu/maestro-order, together with pinned dependencies, reference outputs, and a README with step-by-step instructions. One-command reproduction. With Python 3.10+ and the pinned packages from requirements.txt (NumPy 2.2.6 is the version that matters for bit-exact randomness), python reproduce.py all regenerates every artifact in two to four minutes on a single CPU core, writing to ./output. Table 6 maps each artifact to its subcommand and seed. The four panels of Figure 4 and the ablation table share one pseudo-random stream in a fixed order, so the figures subcommand runs them together; the exact pattern of random draws inside the simulation primitives is documented in the code and is part of the artifact. Table 6. Reproduction map: each published artifact, the subcommand of reproduce.py that regenerates it, and the PCG64 seed. Artifact Subcommand Seed Fig. 4(aâd), Table 3 figures 20260607 Table 2 (trace, stop rate) trace 7 Fig. 3 (trajectories) traj 11 Closed-form numbers in the text predictions â Verification. Reproduced outputs can be checked against the published artifacts by direct comparison: the regenerated ablation table in output/ is byte-identical to the published copy in figures/, and JSON summaries of every data series (including the measured maximum deviation between simulation and the closed-form odds law, 0.0019â€0.0040.0019†0.004) are provided as reference outputs. Derived quantities quoted in the text (the voting cost-to-target estimates of Table 5, the diversity plateaus of §13, and the marginal rates in the trajectory analysis) are computed in closed form by the predictions subcommand, with no random input. The paper itself builds from the repository root with pdflatex and the ACM acmart class; figure and table sources are read from the figures/ directory that the reproduction script can regenerate. References (1) Hidayet Aksu. 2026. Odds Law: The Decomposition AlgebraâOn How Intelligence Organizes Itself to Solve Difficult Problems Reliably. arXiv:2606.15712. https://arxiv.org/abs/2606.15712 (2) Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed Chi, Quoc Le, and Denny Zhou. 2022. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. In Proc. NeurIPS. (3) Xuezhi Wang, Jason Wei, Dale Schuurmans, Quoc Le, Ed Chi, Sharan Narang, Aakanksha Chowdhery, and Denny Zhou. 2023. Self-Consistency Improves Chain of Thought Reasoning in Language Models. In Proc. ICLR. (4) Shunyu Yao, Dian Yu, Jeffrey Zhao, Izhak Shafran, Thomas L. Griffiths, Yuan Cao, and Karthik Narasimhan. 2023. Tree of Thoughts: Deliberate Problem Solving with Large Language Models. In Proc. NeurIPS. (5) Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. 2023. ReAct: Synergizing Reasoning and Acting in Language Models. In Proc. ICLR. (6) Noah Shinn, Federico Cassano, Edward Berman, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. 2023. Reflexion: Language Agents with Verbal Reinforcement Learning. In Proc. NeurIPS. (7) Aman Madaan, Niket Tandon, Prakhar Gupta, et al. 2023. Self-Refine: Iterative Refinement with Self-Feedback. In Proc. NeurIPS. (8) Yilun Du, Shuang Li, Antonio Torralba, Joshua B. Tenenbaum, and Igor Mordatch. 2023. Improving Factuality and Reasoning in Language Models through Multiagent Debate. arXiv:2305.14325. (9) Karl Cobbe, Vineet Kosaraju, Mohammad Bavarian, et al. 2021. Training Verifiers to Solve Math Word Problems. arXiv:2110.14168. (10) Hunter Lightman, Vineet Kosaraju, Yura Burda, et al. 2023. Letâs Verify Step by Step. arXiv:2305.20050. (11) Lianmin Zheng, Wei-Lin Chiang, Ying Sheng, et al. 2023. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. In Proc. NeurIPS Datasets and Benchmarks. (12) Patrick Lewis, Ethan Perez, Aleksandra Piktus, et al. 2020. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. In Proc. NeurIPS. (13) Timo Schick, Jane Dwivedi-Yu, Roberto DessĂŹ, et al. 2023. Toolformer: Language Models Can Teach Themselves to Use Tools. In Proc. NeurIPS. (14) Mark Chen, Jerry Tworek, Heewoo Jun, et al. 2021. Evaluating Large Language Models Trained on Code. arXiv:2107.03374. (15) Ziwei Ji, Nayeon Lee, Rita Frieske, et al. 2023. Survey of Hallucination in Natural Language Generation. ACM Computing Surveys 55, 12, Article 248. (16) John von Neumann. 1956. Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components. In Automata Studies. Princeton Univ. Press, 43â98. (17) Marquis de Condorcet. 1785. Essai sur lâapplication de lâanalyse Ă la probabilitĂ© des dĂ©cisions. Paris. (18) Jeffrey Dean and Sanjay Ghemawat. 2004. MapReduce: Simplified Data Processing on Large Clusters. In Proc. OSDI. USENIX, 137â150.