Why the review happens before the save becomes routine
Last updated: September 1, 2026
Imported play-by-play is structured evidence, not a guarantee that every field matches the official book. A partial copy can omit innings. A player name variation can split one athlete into two rows. An error-versus-hit decision can change several rate stats. The safest moment to catch those problems is while the completed game is still open beside the import.
Do not start by checking every cell. First confirm that this is the right game in the right team and season. Then move from team totals to player detail.
The sanitized sequence we use to explain the parser
This short sample is part of the regression coverage used around the GC Stats play-by-play parser. It contains no private team record.
Ava Rodriguez doubles on a line drive to center fielder. Zoe Carter singles on a ground ball to right fielder. Ava Rodriguez scores. Mia Johnson homers on a fly ball to center fielder.
The expected offensive events are three plate appearances, three hits, one double, one home run, and the runs that can be named from the text. That makes a useful spot check. A complete game needs much more context, including innings, outs, pitching changes, baserunning, and the final score.
This example proves what those three lines express. It does not pretend to reconstruct details the text does not contain.
1. Confirm the game identity
- Team and season: Make sure the import is attached to the intended roster and season before reviewing player totals.
- Opponent and date: Compare both with the completed game. Dates are especially important when teams play the same opponent twice.
- Final score and result: Check runs for both teams and whether the saved result is a win, loss, or tie.
- Location and tournament: Add these while the source is open if they matter to later filters or team records.
- Complete source: Confirm that the paste begins at the start of the game and includes the final inning rather than a selected excerpt.

2. Check names before calculating meaning
Names are identifiers in a season record. “Ava Rodriguez,” “A. Rodriguez,” and a misspelling may describe one player to a coach but become separate rows to software. Scan the imported hitters and pitchers against the roster before trusting leaders or averages.
Look for split players
If one athlete appears twice, compare spelling, punctuation, suffixes, and abbreviations. Resolve the identity before both rows accumulate more games.
Look for the wrong team's players
Play-by-play can mention both teams. Confirm that each imported player row belongs in the saved team record.
Keep corrections explainable
When you merge or rename a player, make the change while the source is available so another coach can understand why it was done.
3. Reconcile the offensive line from totals to details
Start with the broad signals: runs, hits, and the number of hitters who appeared. Then inspect the player rows that drove them. In the three-line sample, Ava should have a double and a run, Zoe should have a single, and Mia should have a home run. If the event labels do not match, stop before analyzing AVG, OBP, or SLG.
- Compare hits and extra-base hits with the completed scorebook or trusted game summary.
- Check walks, hit-by-pitches, strikeouts, sacrifices, and sacrifice flies where the source records them.
- Review runs and RBIs in the context of the actual scoring sequence, not only a team total.
- Inspect any play scored as a hit, error, fielder's choice, or reached-on-error when the distinction is uncertain.
- Recalculate a suspicious rate from its counting stats. A display value can only be as correct as the inputs beneath it.
4. Review pitching as its own record
Pitching changes make a complete game harder than a short hitting sample. Confirm who entered, which outs belong to each pitcher, and whether runs, earned runs, hits, walks, and strikeouts line up with the trusted source. If pitch counts are available, verify them separately rather than inferring them from batters faced.
Innings pitched are based on outs recorded, so a line such as 4.2 represents four innings and two outs, not a decimal fraction of an inning. A missing out around a pitching change can shift both pitchers' displayed innings and downstream rate stats.
If the play-by-play does not prove an earned-run or pitcher-of-record decision, mark it for human review. Do not manufacture certainty from incomplete text.
5. Resolve flags and duplicate-game risk
Parser flags are not failures. They identify rows where the text may support more than one interpretation or where the product needs a coach's scoring judgment. Read the original play, make the narrow correction, and then check the affected player and team totals again.
Before saving another attempt, search for the same team, opponent, and date. Doubleheaders and tournaments mean those fields are not always unique, so include score and game context. A duplicate import can double an entire game's contribution while every individual row still looks plausible.
Fielding needs evidence
Assists, putouts, errors, catching events, and position innings should be reviewed against the source. Do not treat an offensive play sentence as a complete defensive record.
Correct the smallest unit
If one play is wrong, fix that play or row. Avoid replacing unrelated stats that already reconcile.
Export after review
A reviewed export creates a useful checkpoint before the next batch of games is added.

The two-minute final pass
- Right team, season, opponent, date, score, and result.
- No duplicate game and no player split by naming.
- Team hits and runs agree with the trusted completed record.
- Extra-base hits, walks, strikeouts, sacrifices, and scoring decisions look plausible by player.
- Pitching appearances and outs are assigned correctly.
- Every flag is resolved or deliberately left for review.
- Season leaderboards change in a way this one game can reasonably explain.
If any final check fails, keep the game out of decision-making until the underlying row is understood. That is faster than trying to reverse a season-wide conclusion later.
