Took a hard look at this dataset for a modeling pipeline. The scorecard angle is genuinely novel, but the fidelity story doesn't hold up to scrutiny, and anyone ingesting this blind is going to inherit problems they can't see. Concretely:
-
The scorecards are OCR output presented as data. merged_stats_n_scorecards.csv comes from PaddleOCR over scorecard images with — as far as I can tell — no validation pass. OCR silently transposes numerals (10-9 → 10-8, mangled judge totals), and there's nothing in the repo documenting an accuracy rate, a spot-check, or a QA step. Numbers this easy to get subtly wrong shouldn't ship without a stated error bound. What is it?
-
stats_raw.csv is fight-level only. Every stat is a bout total — there's no per-round breakdown at all (round is just the finish round). For anything analytical, that's a hard ceiling, and it's not disclosed up front.
-
No stable identifiers. The schema is name-keyed (red_fighter_name, blue_fighter_name, event_name) with zero ufcstats.com fighter/bout IDs. Name-joining is lossy the moment two fighters share a name or a name is spelled inconsistently across events — and there's no ID to fall back on.
-
No consistency checks. Is anything validated — landed ≤ attempted, method/round sanity, totals reconciled against ufcstats.com? Is there a quarantine list of known-bad events, or does bad data just flow through?
Happy to be wrong on any of these if there's validation I missed — point me at it. But as it stands the data needs a lot of defensive review before it's trustworthy, and none of these limitations are flagged in the README.
Took a hard look at this dataset for a modeling pipeline. The scorecard angle is genuinely novel, but the fidelity story doesn't hold up to scrutiny, and anyone ingesting this blind is going to inherit problems they can't see. Concretely:
The scorecards are OCR output presented as data.
merged_stats_n_scorecards.csvcomes from PaddleOCR over scorecard images with — as far as I can tell — no validation pass. OCR silently transposes numerals (10-9 → 10-8, mangled judge totals), and there's nothing in the repo documenting an accuracy rate, a spot-check, or a QA step. Numbers this easy to get subtly wrong shouldn't ship without a stated error bound. What is it?stats_raw.csvis fight-level only. Every stat is a bout total — there's no per-round breakdown at all (roundis just the finish round). For anything analytical, that's a hard ceiling, and it's not disclosed up front.No stable identifiers. The schema is name-keyed (
red_fighter_name,blue_fighter_name,event_name) with zero ufcstats.com fighter/bout IDs. Name-joining is lossy the moment two fighters share a name or a name is spelled inconsistently across events — and there's no ID to fall back on.No consistency checks. Is anything validated — landed ≤ attempted, method/round sanity, totals reconciled against ufcstats.com? Is there a quarantine list of known-bad events, or does bad data just flow through?
Happy to be wrong on any of these if there's validation I missed — point me at it. But as it stands the data needs a lot of defensive review before it's trustworthy, and none of these limitations are flagged in the README.