Skip to content

feat(leaderboard): surface the composite score-to-beat (the number that decides approval) - #397

Merged
James-CUDA merged 1 commit into
James-CUDA:mainfrom
galuis116:feat/competition-score-to-beat
Jul 22, 2026
Merged

feat(leaderboard): surface the composite score-to-beat (the number that decides approval)#397
James-CUDA merged 1 commit into
James-CUDA:mainfrom
galuis116:feat/competition-score-to-beat

Conversation

@galuis116

Copy link
Copy Markdown
Contributor

What does this PR do?

trinity.leaderboard answers "what score must a submission beat?" — but it only builds per-benchmark BenchmarkTargets from benchmarks.*. The crown is composite: pr_eval evaluates one head on every benchmark and approves a submission only when its mean score clears the reigning competition.best_composite_score by win_margin.

So the single number a miner must actually beat to be crowned — best_composite_score + win_margin — is surfaced nowhere. The per-benchmark best_scores a contributor sees do not decide approval. This is the same "the competition is composite" gap I just fixed in standings (#387) and hardened in the integrity verifier (#384).

How

Add CompetitionTarget + summarize_competition(leaderboard): it reads the competition object and reports

  • score_to_beat = best_composite_score + win_marginpr_eval's exact APPROVE threshold;
  • the reigning king (miner / generation / pr) and their per-benchmark breakdown;
  • the baseline_best_single / baseline_random reference points;
  • a reachable flag (score_to_beat <= 1.0) — a king at 0.99 with a 0.02 margin is effectively unbeatable.

It returns None for an older benchmarks-only leaderboard (no competition), and tolerates missing / string / null fields. scripts/leaderboard_targets.py now prints the composite headline above the per-benchmark reference rows:

COMPOSITE: beat >= 0.8700 (king 0.8500 + margin 0.0200) [alice (gen 3, #42)]
    king per-benchmark: livecodebench 0.7500, math500 0.9000, mmlu 0.9000

Scope

Pure stdlib — no torch, no network. Read-only; the committed leaderboard.json parses (seed: beat >= 0.02, no king yet). New tests cover the threshold, the seed, the unbeatable case, the no-competition None, field coercion, and JSON round-trip; they exercise the new summarize_competition symbol (absent on main).

  • ruff + mypy clean; pytest tests/test_leaderboard.py green (22 tests).

Duplication note

Touches only trinity/leaderboard.py + its CLI/tests. The two open PRs (#377 definition-of-done, #373 R11 coordinator-vs-LLM) are both in analysis/ and touch neither — verified against their file lists.

…benchmark targets

trinity.leaderboard answers 'what score must a submission beat?' but only builds
per-benchmark BenchmarkTargets from benchmarks.*. The crown is COMPOSITE, though:
pr_eval evaluates one head on every benchmark and approves a submission only when
its MEAN score clears the reigning competition.best_composite_score by win_margin.
So the single number a miner must actually beat to be crowned -- best_composite_score
+ win_margin -- was surfaced nowhere; the per-benchmark best_scores a contributor
saw do NOT decide approval.

Add CompetitionTarget + summarize_competition(leaderboard): reads the competition
object and reports score_to_beat = best_composite_score + win_margin (pr_eval's
APPROVE threshold), the reigning king + per-benchmark breakdown, the baselines, and
a 'reachable' flag (score_to_beat <= 1.0). Returns None for an older benchmarks-only
leaderboard. scripts/leaderboard_targets.py now prints the composite headline above
the per-benchmark reference rows (and includes it in --json).

Pure stdlib -- no torch, no network. The committed leaderboard.json parses (seed:
beat >= 0.02, no king yet). Offline tests only.
@James-CUDA
James-CUDA force-pushed the feat/competition-score-to-beat branch from 9110b6f to 14a717b Compare July 22, 2026 13:02
@James-CUDA
James-CUDA merged commit 60bec23 into James-CUDA:main Jul 22, 2026
1 of 2 checks passed
James-CUDA pushed a commit that referenced this pull request Jul 23, 2026
…ap-to-king

summarize_competition (#397) tells a miner the composite score-to-beat, but not
whether their own run clears it or WHERE it falls short. The competition is
composite: pr_eval approves only when the mean of the per-benchmark scores clears
the reigning best_composite_score by win_margin.

Add trinity.competition_preflight: given the leaderboard + a miner's {benchmark:
score}, compute the composite the same way pr_eval does (mean over the declared
benchmarks, an unscored board counting as 0.0), decide go/no-go against king +
win_margin, and report the per-benchmark delta versus the reigning king plus the
weakest board -- so the miner sees which benchmark is dragging the composite down
before spending a PR. scripts/preflight_composite.py exits non-zero when the
submission would not win. Pure stdlib -- no torch, no network. Offline tests only.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants