34. The San Diego scoresheet

This whole book makes a claim — that the architecture on these pages is what separates elite robot code from the rest — and a claim that big deserves to be checked against reality, not just asserted. So we ran the rubric on our own backyard. We scored 24 active San Diego FRC teams on the D1–D8 dimensions, paired each with its season-matched Statbotics EPA — the modern, normalized strength rating built purely from match results — and asked the blunt question: does better code actually correlate with winning? The short answer is yes, moderately, and unevenly — and the uneven part is where the real lessons live. This chapter is the receipt. For what the architecture is supposed to predict, see what the architecture predicts; for the scoring instrument itself, see the rubric in full.

What the study was

Twenty-four active San Diego FRC teams, scored on the eight-dimension code-sophistication rubric, each paired with the Statbotics EPA of the exact season repo we scored. This is a hand-scored regional study, distinct from (and a companion to) the 55-team, 232-team-year cross-validated study reported in the rubric in full: that study calibrates the instrument on the full indexed corpus; this one asks whether the scores track winning among our neighbors. Five more teams were excluded as inactive or legacy — their newest competition code predates the 2024 WPILib baseline the rubric measures, or no real season repo exists — and since those teams also carry no recent EPA, dropping them doesn’t bias the correlation. Two methodology calls shaped the numbers: D1 uses the lenient reading (a maintained 254-style generic base counts toward the top of D1 even without a Real/Sim IO swap), and D8 credits a team library that demonstrably exists.

The dimensions, abbreviated throughout: D1 Architecture · D2 Coordination · D3 Simulation · D4 Testing · D5 Logging · D6 Autonomous/Path planning · D7 Vision/Localization · D8 Sustainability. EPA is season-matched to the scored repo; the state percentile (st%ile) is that team’s standing within California for that season, so a 2023 repo is ranked against 2023 California, not 2026.

The raw data behind every table below lives in two machine-readable files. sd-frc-master.csv carries one row per team — team number, name, season, language, the eight rubric scores, the total, and four external metrics (norm_EPA, state_pctile, winrate, epa_points). sd-frc-correlations.csv carries one row per dimension — its code (D1…D8) and its Spearman ρ against each of the three external measures (spearman_normEPA, spearman_state_pctile, spearman_winrate). The tables here are those two files, read straight.

The full scoresheet

Twenty-four active teams, ranked by code total. Σ is out of 32.

† This survey pass scored 4738’s 2025 season from the shallow clone. The full-history re-score in the Patribots case study confirmed the Superstructure’s guarded transitions and raised D2 to 3, for Σ = 20.0. Both numbers are kept as scored; the correlations here use the survey values.

What predicts results

Rubric total versus normalized EPA lands at Spearman ρ = 0.55 (Pearson r = 0.60, p ≈ 0.002). Better software is associated with better results — but it explains only about a third of the variance. The headline number is real, and it is modest; anyone who tells you clean code guarantees banners is overselling.

The per-dimension breakdown is the more useful cut. Spearman ρ against each external measure, n = 24, sorted by how strongly the dimension tracks the two most robust measures:

Three dimensions carry the signal — Sustainability (D8), Autonomous/Path planning (D6), and Vision/Localization (D7) — and two barely register: Simulation (D3) and Testing (D4). (The numbers are in the table; the prose that follows is the interpretation.)

That split has a clean reading. D6 and D7 are the dimensions that put points on the board directly — a team that runs real autos and aligns to targets with vision scores more, immediately. D8 (CI, a carried team library, real docs, a formatter) is a proxy for overall program maturity and resourcing, which sustains competitiveness across a season. D3 and D4 — simulation and testing — are internal engineering-quality investments whose payoff is robustness and developer velocity, not raw match points; teams adopt them for reasons largely orthogonal to a given season’s standings. And a caution on D4: it is near-constant here — almost every team scores 0 — so its low correlation is partly a low-variance artifact, not evidence that testing hurts. The one team that genuinely tests, 6695 GalvaKnights, sits mid-pack in the code ranking (12th of 24) while posting a 72nd-percentile EPA — a result that, if anything, argues for the testing investment rather than against it.

The outliers are the interesting part

A correlation of 0.55 is loose enough that the mismatches carry most of the signal. Three profiles are worth memorizing.

Sophisticated code, weak results — 3647 Millennium Falcons. The single most feature-complete codebase in San Diego (Σ = 20: maple-sim whole-robot simulation, AdvantageKit, 254-style architecture, multi-camera vision, Choreo, spotless + CI) finished in the bottom third of California in 2025 — state percentile 28, a 44% win rate. Their software comes close to a working model of this book’s architecture; their 2025 on-field result did not follow. This is the textbook case that code sophistication and competition performance are different axes, and that a robot is more than its repo.

Modest code, strong results — 4419 Team Rewind and 3749 Team Optix. Rewind’s minimal 14-file C++ repo (Σ = 5) paired with a 72nd-percentile 2024 EPA; Optix’s 2023 repo (Σ = 10.5) with percentile 75. Whatever drove those results, it wasn’t software the rubric can see — a fast, reliable mechanism and a good driver don’t show up in an AST scan.

The aligned top — 4738 Patribots and 3128 Aluminum Narwhals. Patribots is the cleanest case of code and results agreeing: Σ = 19.5 in this survey pass (20.0 on the full-history re-score — see the table footnote), a real AdvantageKit IO layer across every mechanism, and the best competition record in the set — state percentile 96, 77% wins. 3128 pairs Σ = 17 with percentile 94. When the architecture is real and the program is strong, the two axes line up — which is the outcome this book is arguing for. The Patribots’ four-year climb to that point is its own study; see the Patribots case study.

A few per-team notes worth keeping

• 5137 Iron Kodiaks — the most balanced sophisticated codebase: a generalized MotorIO layer with three hardware implementations, AdvantageKit across six subsystems, physics sims (Shooter/Intake/SwerveModule). Highest D3 among the AdvantageKit teams.
• 1538 Holy Cows — the only C++ program of note: a custom framework (CowLib, a hand-rolled command system, a threaded Localizer with PhotonVision pose fusion, Choreo). Sophistication reached without WPILib’s Java idioms — and it shows in the results (state percentile 92).
• 6995 NOMAD — a Real/Sim/None vision-and-climb IO layer without AdvantageKit logging: architecture-forward, telemetry-light.
• 6695 GalvaKnights — the only team that writes real unit tests (4 Kotlin suites with assertions), though CI runs spotlessCheck, not the tests. The rarest marker in the set, sitting on an otherwise baseline codebase.
• 2102 Team Paradox — the strongest simulation profile (physics sims across six mechanisms plus maple-sim and replay vendordeps) on an otherwise mid-tier architecture.

Caveats — read these before you quote the number

The 0.55 is honest, but it is a small, imperfect study, and it deserves to be reported with its limits attached.

1. Correlation, not causation, and a likely confound. That D8 (sustainability / program maturity) tops the list suggests a lurking variable: older, better-resourced programs have both better software hygiene and better results. Team age (rookie year) plausibly drives both. The rubric measures code, not budget, mentorship, or build quality — all of which move EPA.
2. Small n, mixed game years. Twenty-four teams across four FRC seasons (2023–2026). Normalized EPA and within-season state percentile are designed to be comparable across years, which justifies pooling, but the games differ. A 2025/2026-only cut (n = 18) gives a materially similar ranking of dimensions.
3. Repos are shallow clones with .git stripped, so D8 is artifact-only — no commit history, CI run logs, or release discipline — and should be read as a floor. D4 is near-constant and its correlation is statistically weak.
4. EPA measures the whole robot and its alliance context, not the software. A great drivetrain controller can’t compensate for a slow intake or a no-show alliance partner.
5. The per-dimension ordering is suggestive, not stable. At n = 24 the confidence interval on a single Spearman ρ spans roughly ±0.3, so “D8 beats D1” is a reasonable reading of this sample, not an established ranking.
6. Scoring was not blinded to team identity. The scorer knew which team’s repo was open, and for the LLM-confirmed pass a model may carry knowledge of team reputations — either can inflate the confirmed pass’s apparent validity.
7. Only teams with public repos are scoreable. That is a selection filter: teams that publish code may differ systematically from teams that don’t, in ways that touch both code quality and results.

The takeaway is not “write clean code and you will win.” It is narrower and more defensible: the dimensions that either put points on the board (D6, D7) or index a mature, well-resourced program (D8) track results; the dimensions that are pure internal engineering investment (D3, D4) do not track a single season’s standings — which is exactly what you’d expect, and exactly why you should still do them. The architecture in this book is designed to make D6 and D7 cheap and reliable to build, and to make D8 a byproduct rather than a chore.

Performance data: Statbotics v3 API (api.statbotics.io), season-matched per team, retrieved June 10, 2026.