The median-to-geomean swap is moot: RDCO's conviction pipeline has no numeric panel-probability aggregation step to swap
The question
Does the RDCO /decisions/ conviction pipeline currently collapse panel probabilities with median, arithmetic mean, or geometric-mean-of-odds — i.e. is there an actual median-to-geomean swap to make, or is the point already moot? (Gating self-audit for the geomean-of-odds recommendation surfaced as open follow-up #1 in [[2026-06-18-probability-aggregation-scoring-rules-panel]].)
What we already know (from the vault)
- The implementation finding (load-bearing): there is no panel-probability aggregator in the live pipeline to swap. A grep across
~/.claude/skills/,~/.claude/scripts/, the/decisions/HTML pages (~/rdco-hq/public/decisions/), and the HQ route (~/rdco-hq-api/src/routes/decisions.ts) finds zeromedian()/mean()/ geometric-mean-of-odds operating on a set of per-seat probabilities. The onlynp.mean/np.mediancalls in the whole estate are inside backtest return math (01-projects/investing/backtests/*.py) — averaging trade returns, not pooling forecaster probabilities. - The actual collapse gate is qualitative, not numeric. [[verify-strategic-output]] is the gating step before any
/decisions/page or paper-trade deploy; it emits aPASS | ITERATE | SCRAPverdict from a six-item mechanical rubric plus an ACCEPTANCE-CONTRACT check. It never combines several probability numbers into one — there is no probability arithmetic in the skill at all. (Confirmed by reading~/.claude/skills/verify-strategic-output/SKILL.mdin full.) - Conviction on the decision surface is expressed as narrative + structured labels, not a pooled probability. The live paper-trade pages (e.g.
2026-05-18-paper-trade-nvidia-adjacent-v1-go.html) carry smart-money manager-count labels ("1-manager high-conviction," "2-manager threshold"), R-unit sizing tables (1R = $5,000; AMD 1.5R + AVGO 1.0R + INTC 0.25R), and prose bear cases — there is no "82% confidence" number anywhere, let alone one produced by collapsing a multi-agent panel. - [[2026-06-18-probability-aggregation-scoring-rules-panel]] (the brief this audits) recommended
median → geometric-mean-of-oddsconditional on "if the pipeline is going to collapse the panel to one number anyway" — and explicitly filed this audit as its own open follow-up #1, flagging it as "a cheap code audit, not research." It also warned the swap is a rounding-error optimization next to preserving disagreement spread. - [[2026-06-20-conviction-score-binary-collapse-point]] independently observed the same thing from the binary-collapse angle: the verify-* two-gate
PASS/FAILis "currently a binary-shaped surface," and its open follow-up #1 asks whether the live page even renders per-seat spread today — implying it does not yet. [[binary-decision-around-continuous-probability]] is the governing anti-pattern.
What the web says
- Ranked aggregator family (Satopää/Mellers/Tetlock et al. 2014, 1,300 forecasters / 69 questions): extremized geo-mean-of-odds > geo-mean-of-odds > arithmetic mean > median. The naive median is the worst of the standard family (EA Forum: geometric mean of odds).
- Geometric mean of odds is the recommended default — empirically more accurate than arithmetic mean / median and Bayesian-coherent (behaves correctly as pooling of independent prior-updates). It is a closed-form deterministic formula, not a market or training loop (EA Forum: how to aggregate forecasts).
- The win over median is small in the normal range. With member probabilities between 10–90%, the absolute method-to-method gap is typically 0–3%; it only grows large (up to ~18%) with extreme sub-1% / >99% inputs (EA Forum: geometric mean of odds).
- Weighting by forecaster quality dominates the choice of mean. On ~850 Metaculus questions, weighted-geometric beat unweighted methods by far more than geometric beat arithmetic — the practical lever is who you trust, not which mean (EA Forum: how to aggregate forecasts).
- Extremizing is justified ONLY by information diversity and backfires on correlated/homogeneous panels. Tetlock's GJP found extremizing helped the diverse crowd but superforecaster teams needed little/none; the projective-substitutes condition fails when forecasters share information (EA Forum: principled extremizing; Satopää et al. 2014).
Convergences and contradictions
- The web "best practice" and RDCO's current method do not even contact each other — because RDCO has no aggregation step. The literature answers "which mean is best when pooling probabilities"; RDCO never pools probabilities, so the question is well-posed but currently unaddressed in the live system rather than answered wrongly.
- All three vault briefs converge on the same scope-narrowing. [[2026-06-18-probability-aggregation-scoring-rules-panel]] (geo-mean is correct but a rounding-error vs spread), [[2026-06-20-conviction-score-binary-collapse-point]] (collapse late, at the deploy gate, against cost asymmetry — not via a fancier mean), and the current implementation reality (qualitative gate, no number) all point away from "go install geomean" and toward "decide whether to instrument a numeric panel at all."
- No contradiction; one inherited precondition. Per [[verifier-as-epistemology]], any future pooled number is only informative if the seats' errors are independent — and RDCO's homogeneous same-model panel is exactly the regime where a pooled point estimate (and especially extremizing) would manufacture fake conviction.
Synthesis for RDCO
The point is moot. There is no median-to-geomean swap to make today, because the /decisions/ conviction pipeline does not collapse a panel of probabilities at all — there is no probability-pooling step in verify-strategic-output, in the decisions HTML, or in the HQ route. What the pipeline actually does is qualitative: verify-strategic-output emits PASS / ITERATE / SCRAP from a mechanical rubric, and the decision pages express conviction through smart-money manager counts, R-unit sizing, and narrative bear cases. The 2026-06-18 recommendation was correctly conditioned ("if the pipeline collapses to one number") and the precondition is simply not met. So the recommendation is neither already-implemented nor in need of implementation — its trigger does not exist. This closes open follow-up #1 of [[2026-06-18-probability-aggregation-scoring-rules-panel]] with answer: moot — no aggregation point exists.
That makes the geomean-of-odds recommendation a contingent design choice, not a bug fix. It only becomes live if RDCO first decides to build a numeric multi-agent conviction panel (Stage 1–2 of the architecture sketched in [[2026-06-20-conviction-score-binary-collapse-point]]) where N seats each emit a probability. If and when that panel is built, the swap is pre-decided and trivial: the seats should be pooled with geometric-mean-of-odds, never median or arithmetic mean, as a ~5-line closed-form formula with no new infrastructure. Worth pre-registering that as the default now so the question never has to be re-litigated at build time — but it is a note-to-future-self, not a task.
The more useful reframe, which all three briefs already converge on: do not treat "pick the right mean" as the open work item. The two things that actually move calibration are upstream of the mean — (1) whether the panel seats are independent enough to pool at all (homogeneous same-model seats are fake-tight, per [[verifier-as-epistemology]]), and (2) surfacing disagreement spread to the founder rather than any single collapsed number (per [[binary-decision-around-continuous-probability]] and [[2026-06-20-conviction-score-binary-collapse-point]]). At RDCO's handful-of-decisions-per-week volume, per [[brier-score]], the system structurally cannot accumulate enough resolved outcomes to measure geomean beating median anyway — so building aggregator machinery to chase an unmeasurable 0–3% edge fails the instrumentation layer of [[feedback_targeting_system_prioritization_filter]]. Net: mark the geomean recommendation as "pre-decided default, dormant until a numeric panel exists," and put the complexity budget into spread-surfacing and seat-independence, not into the mean.
Open follow-ups
- If RDCO does build a numeric multi-agent conviction panel, where does it slot relative to the existing qualitative
verify-strategic-outputgate — does it feed the gate, or replace the rubric's confidence-evidence item? (design question, gated on the panel existing) - Does the live
/decisions/page render any conviction gradient today (manager counts / R-units count as a crude spread proxy), or is the founder seeing only binary go/no-go? (cheap template audit — the concrete first fix per [[2026-06-20-conviction-score-binary-collapse-point]] follow-up #1) - Before committing to any numeric panel, retro-test on the existing paper-trade decision log: would a pooled conviction number have changed a single past sizing/deploy call vs the current qualitative R-unit method? If not, the panel itself is the un-anchored shiny object, independent of which mean.
- Should the geomean-of-odds default be written into a dormant spec stub now (so build-time doesn't re-open the question), or left as a vault note until heterogeneity + a panel both exist?
Related
- [[2026-06-18-probability-aggregation-scoring-rules-panel]]
- [[2026-06-20-conviction-score-binary-collapse-point]]
- [[2026-06-16-multi-agent-ensembles-conviction-calibration]]
- [[binary-decision-around-continuous-probability]]
- [[verifier-as-epistemology]]
- [[brier-score]]
- [[2026-06-12-agentic-targeting-conviction-calibrated-confidence]]
- [[feedback_targeting_system_prioritization_filter]]
Sources
- Implementation (skill):
~/.claude/skills/verify-strategic-output/SKILL.md— the actual gating step; qualitative PASS/ITERATE/SCRAP rubric, zero probability arithmetic - Implementation (skill):
~/.claude/skills/log-bet-decision/SKILL.md— appends YAML decision traces; no aggregation - Implementation (pages):
~/rdco-hq/public/decisions/2026-05-18-paper-trade-nvidia-adjacent-v1-go.html,~/rdco-hq/public/decisions/2026-05-17-paper-trade-power-v1-go.html— conviction expressed via manager counts + R-unit sizing + narrative, no pooled probability - Implementation (route):
~/rdco-hq-api/src/routes/decisions.ts— HQ decisions route; no probability-aggregation logic - Implementation (grep):
~/.claude/skills/,~/.claude/scripts/,~/rdco-vault/01-projects/investing/— onlynp.mean/np.medianuses are backtest return math, not panel pooling - Vault: [[2026-06-18-probability-aggregation-scoring-rules-panel]] —
~/rdco-vault/06-reference/research/2026-06-18-probability-aggregation-scoring-rules-panel.md(the recommendation this audits; filed this exact audit as open follow-up #1) - Vault: [[2026-06-20-conviction-score-binary-collapse-point]] —
~/rdco-vault/06-reference/research/2026-06-20-conviction-score-binary-collapse-point.md(collapse-point architecture; verify-* gate as binary surface) - Vault: [[2026-06-16-multi-agent-ensembles-conviction-calibration]] —
~/rdco-vault/06-reference/research/2026-06-16-multi-agent-ensembles-conviction-calibration.md(calibration ceiling; spread-as-asset) - Vault: [[binary-decision-around-continuous-probability]] —
~/rdco-vault/06-reference/concepts/binary-decision-around-continuous-probability.md(collapse as late as the pipeline allows) - Vault: [[verifier-as-epistemology]] —
~/rdco-vault/06-reference/concepts/verifier-as-epistemology.md(independence precondition; fake-tight homogeneous panels) - Vault: [[brier-score]] —
~/rdco-vault/06-reference/concepts/brier-score.md(small-sample noise; measurability at RDCO volume) - Vault: [[feedback_targeting_system_prioritization_filter]] — targeting-system filter (instrumentation layer fails at low decision volume)
- Web: When pooling forecasts, use the geometric mean of odds — https://forum.effectivealtruism.org/posts/sMjcjnnpoAQCcedL2/when-pooling-forecasts-use-the-geometric-mean-of-odds
- Web: My current best guess on how to aggregate forecasts — https://forum.effectivealtruism.org/posts/acREnv2Z5h4Fr5NWz/my-current-best-guess-on-how-to-aggregate-forecasts
- Web: Satopää, Baron, Foster, Mellers, Tetlock, Ungar (2014) — Two Reasons to Make Aggregated Probability Forecasts More Extreme — https://www.researchgate.net/publication/275937752_Two_Reasons_to_Make_Aggregated_Probability_Forecasts_More_Extreme
- Web: Principled extremizing of aggregated forecasts — https://forum.effectivealtruism.org/posts/biL94PKfeHmgHY6qe/principled-extremizing-of-aggregated-forecasts