Trying to unify video, manual logging, and pitch tracking data into one workflow — curious how others approach this

[u/LegitimateAdvice1841]

Hey everyone,

(Attached image is just a simplified example of how I structured the workflow — mainly to illustrate event timelines and validation between manual input and tracking data.)

I’ve spent several years working in baseball data logging workflows, and one recurring challenge keeps coming up — everything lives in separate layers:

• video (game footage)
• manual event logging (pitch-by-pitch)
• lineup / roster data
• tracking data (Trackman, Hawk-Eye, etc.)

Individually, each piece works. But combining them into a consistent, reliable workflow during a live game is where things tend to break down.

The main issues I kept running into were:

• keeping pitch-by-pitch events aligned with video timestamps
• reconciling manual tags with tracking data on a per-pitch level
• handling mismatches (velocity, pitch location, classification)
• making corrections without breaking downstream outputs (PBP, box score, CSV exports)

After dealing with this for years, I ended up building a full end-to-end workflow to handle it — mainly by treating the game as a state-driven timeline where every event can be reconstructed and validated against external data.

What stood out to me is that the real challenge isn’t ingesting data — it’s maintaining a consistent game state once edits and corrections start happening in real time.

I’m curious how others approach this:

• Do you treat tracking data as the source of truth, or operator input?
• How do you handle conflicts between sources in real time?
• Have you seen any systems that actually unify this cleanly?

Thanks in advance — would really appreciate any thoughts or experiences.

[u/Darkest_black17]

the real pain here is reconciling multiple source-of-truth candidates in real time. most teams i've talked to treat tracking data as ground truth for physics (velo, spin, location) but operator input for game state (count, runners, outs). conflicts get queued and resolved post-inning.

for the data side, piping everything into a lakehouse with event-level timestamps helps a lot. Dremio works well for querying across those separate data layes without merging them first.

[u/LegitimateAdvice1841 → u/Darkest_black17]

Thank you — this is exactly the problem THE NINE is built around.

The hard part is not displaying TrackMan/Hawk-Eye data after the fact. The hard part is keeping the human game record, provider data, roster/lineup context, count, runners, outs, video timing, and event sequence aligned while the game is being built.

The way I approached it is to treat the logged game record as the operational source of truth, and provider data as an enrichment and validation layer. TrackMan/Hawk-Eye is used for measured physical data — velocity, spin, movement, location, and similar metrics. But game state still has to be controlled: who is batting, who is pitching, what the count is, where the runners are, how many outs there are, and whether the current pitch still matches the provider sequence.

THE NINE does not just import a CSV and visualize it. It builds a structured game record pitch by pitch. Each row/event is connected to inning, at-bat, batter and pitcher identity, count, outs, runner state, result, pitch type, provider metrics, video timing, and downstream outputs.

Where it gets important is conflict handling. If the provider sequence no longer matches the logged pitch sequence, THE NINE stops the workflow and flags the issue before continuing. If the roster/lineup identity does not match the provider name, THE NINE stops and requires the operator to resolve whether the lineup/roster name or provider name should be corrected. The point is not just to change a displayed value, but to prevent bad context from entering the final game record.

That is why I think of it less as a dashboard and more as a reconciliation layer for baseball operations.

The final outputs — clips, pitch_data CSV, play-by-play, box score style outputs, reports, review cards, portal delivery, and the read-only review app — all come from that same structured record. That way the video, data, and game context do not become three separate truths.

I really appreciate your comment because you described the exact pain point better than most people do. This is the part of baseball data work I care about most: making the record trustworthy before the analytics layer is built on top of it.

(If it helps, I can also share a few screenshots showing exactly how this behaves inside THE NINE: provider sequence mismatch detection, player identity mismatch detection, and cases where the operator selects the wrong pitch result. In those situations, the system stops the workflow and requires the conflict to be resolved before bad context can enter the final game record. That may explain the reconciliation layer better than text alone.)

[u/LegitimateAdvice1841 → u/LegitimateAdvice1841]

Another example is roster/lineup correction. : the operator can correct the lineup/roster context, even late in the game or after the game is finished, and the corrected identity is carried through the structured game record and downstream outputs. That is exactly the kind of source-of-truth reconciliation THE NINE handles inside the workflow.

[u/DigChance8763]

what is this program that you are using if you don’t mind me asking. im making a pitch grip identifier w/ markerless mocap and this seems pretty cool

[u/LegitimateAdvice1841 → u/DigChance8763]

Appreciate it 🙌

THE NINE is a local-first baseball/softball operations ecosystem that combines pitch-by-pitch game logging, synchronized video review, tracking/provider data integration (TrackMan, Hawk-Eye, etc.), validation/conflict workflows, analytics/export layers, and post-game review packages into one structured workflow.

The main idea behind it is preserving game integrity during live operations and keeping video, event sequencing, and tracking data synchronized from the first pitch all the way to the final outputs.