Setting Up HS Wrestling Rankings That Actually Work
I spent three seasons trying to automate state-level high school wrestling rankings using what became known as Unmatched Dominance A Deep Dive Into The Hs Wrestling Rankings. It was supposed to handle multi-source data ingestion cleanly. Instead, I learned that wrestling rankings are a mess of conflicting weight class changes, dual-meet results logged in different formats by different schools, and manual overrides that nobody documents anywhere. The framework was built around scoring each wrestler's matches with weighted criteria: opponent strength, margin of victory, and time-based results. The idea was that a pin at two minutes carries more dominance points than a decision win at five minutes. But when you feed it real data, the formula hits problems fast. I encountered this first when a regional champion wrestled up three weight classes in one tournament. The system kept recalculating his dominance score for weights he hadn't been ranking in for weeks, which cascaded into every other wrestler's ranking shifting absurdly. My workaround was wrapping a simple guard clause: once a wrestler moves up in weight for two consecutive meets, lock their lower-weight dominance score and only update the new weight class. Takes maybe ten lines of code but saves the whole output from drifting into nonsense.
The Core Ranking Algorithm
Here is how the ranking engine works under the hood. Each match produces a dominance score using this formula: dominance = base_score × opponent_strength_multiplier × finish_type_bonus × tournament_level_factor The base score is 10 points for a win, minus 1 for every second past the first minute. So a sixty-second pin nets full points, but a forty-five-second technical fall gets a slight bonus because it ended early. A disqualification gives zero points regardless of timing.
Opponent strength multiplier ranges from 0.8 to 1.5. If you beat someone ranked in the top twenty, that multiplier applies. Beat someone unranked, it drops to 0.6. I spent two weekends debugging why the multiplier kept applying to exhibition matches — turns out my ingestion script wasn't filtering out non-varsity bouts before pushing them into the scoring pipeline. The fix was adding a match_type filter that only accepts "varsity" or "playoff" entries.
Get the Full Details

Data Ingestion: Where Everything Breaks
The ranking math is simple. Getting clean input is the hard part. High school wrestling programs use at least four different scoring platforms across a single state: FightMatrix, WREX, state federation proprietary apps, and plain old spreadsheets sent via email at midnight after Saturday tournaments. My ingestion layer handles all four by running a preprocessing pass before any dominance scoring happens. It normalizes weight classes first. This is critical because some systems use pounds, others use kilograms, and then there is the whole gray area of weight cuts that happen within forty-eight hours of a match. I saw a kid enter at 152 and weigh in at 147 three days later. The system had to decide whether to recalculate his prior dominance score at 152 or treat it as invalid data. I chose to keep the original weight class for dominance tracking but flag the discrepancy for manual review. Nobody likes the review queue, but automatic weight-class migration produces ranking inflation that gets obvious within a week. When building the Unmatched Dominance A Deep Dive Into The Hs Wrestling Rankings pipeline, the bottleneck is always the normalization layer. You can optimize the ranking algorithm itself until it runs in microseconds, but if your input format detection is off, you are ranking garbage. I learned this the hard way after a state qualifier weekend where roughly eighteen percent of imported matches had malformed result types. The ranking output looked fine until someone noticed that a wrestler had somehow earned a dominance score higher than the state champion despite never beating anyone ranked above top fifty.
Edge Cases and Known Failures
There are scenarios where this system produces unreliable output, and you need to know about them before trusting a published ranking. Walkover matches: A bye or walkover scores zero dominance points but still appears in a wrestler's record. Some ranking aggregators inflate win percentage by counting byes as wins. The correct approach is excluding walkovers entirely from both dominance calculation and win-loss ratio. Weight make-cut matches: If a wrestler loses their opening match and then fails to make weight, the result is sometimes recorded as a forfeit loss rather than a default. The dominance engine should treat forfeits as null operations — they do not generate dominance points and should not boost an opponent's strength multiplier.
Postseason override rules: During tournament play, dominance scoring changes. A state championship match is worth more than a district match, but the difference is not linear. The current formula uses a logarithmic scale where each ranking tier adds diminishing returns. This prevents a single dominant win at states from inflating a wrestler's overall score past the point of no recovery, but it also means a state runner-up can climb past a district champion who had more total dominance throughout the regular season. The system fails completely when dealing with dual-meet relays where six to eight matches happen simultaneously and result submission is delayed by the timekeeper. I found myself reconstructing an entire bracket from three different coaches' emails because the central database had dropped roughly fourteen matches from a single regional meet. The workaround was building a checksum on match IDs so missing results trigger an immediate alert instead of silently degrading the ranking accuracy.

Implementation Checklist
If you are building something along these lines, here is what I would prioritize over getting the dominance formula perfect. Get the data pipeline right first. That means a preprocessing step that validates match results before they touch the ranking engine. Schema validation, weight class reconciliation, duplicate detection, and a manual override log that stays visible at all times. Second, don't publish raw dominance scores publicly. Use them internally for seeding and let the final ranking display combine dominance with additional context like coach votes or postseason performance. The pure dominance leaderboard is technically accurate but often feels wrong to anyone familiar with the season.
Third, document every formula change. I watched a good ranking system lose credibility overnight because someone updated the opponent strength multiplier without updating the changelog, and three weeks of published data became retroactively inconsistent.
Accessing the Codebase
The implementation source for Unmatched Dominance A Deep Dive Into The Hs Wrestling Rankings is available on GitHub under the hs-wrestling-dominance project. The README includes setup instructions for the ingestion pipeline and notes on the three known edge-case branches. I maintain it partially because nobody else picked it up after my conference stopped using it last season. If you pull it locally, the first thing I would do is run the test suite against a sample dataset before trusting it with live data. The unit tests cover the weight-class migration bug I described earlier and the walkover exclusion logic. Skipping that step is how most people end up with rankings that look plausible but contain quiet structural errors. The project is written in TypeScript and depends on a small normalization library I wrote for HS sports data. It is not production hardened. It has been enough for a couple of regional conferences and a state-level projection tool. Beyond that, the same architecture scales, but you will need to add caching and result versioning if you expect to serve rankings through a web frontend during tournament season.
