I Started Making a Hockey Highlight Reel. I Ended Up Building a System.

How making hockey highlights for Liam Pecararo became an experiment in AI, software, and human judgment.

I started putting together hockey highlights for Liam Pecararo with a straightforward objective: find useful footage, identify his strongest contributions, and produce something he could use. One early result was a four-minute-and-fifty-second reel. The work behind that video became a much larger project.

A few years ago, Liam and I had been discussing an idea we called HockeyHash: connecting the fragments of a player’s career scattered across teams, leagues, statistics sites, game footage, and hard drives.

HockeyHash is on hold, but the underlying problem never went away. Making highlights brought me back to it through a practical task.

The work expanded into individual game highlights, playoff highlights, season compilations, and reels combining material from different periods. I needed a way to connect games, source footage, individual plays, editing decisions, and the videos those decisions produced.

Alongside the videos, I built interfaces for finding games, reviewing plays, recording decisions, adjusting clips, and comparing source quality. AI helped me develop the workflow. The purpose remained the same: make useful hockey content for Liam and make the work easier to continue.

It Started as an Editing Problem

At first, the task looked like ordinary video editing: find useful plays, cut dead time, put clips in a sensible order, identify Liam on the ice, and export a polished video.

Once I started working through the material, the limitations of that approach became obvious.

A video file does not tell me whether I have every game from a season, whether the same scoring play appears in three sources, or whether an assist was officially credited to Liam. It does not preserve why I selected a play, whether it needs a cleaner source, or which version I should use next time.

If I kept those decisions only in my head or inside an editing timeline, I would have to reconstruct them whenever I returned to the footage.

I did not just need an editor. I needed a way to keep track of what I knew.

The Video Became an Output of the System

Instead of treating the finished video as the project itself, I began treating each part of Liam’s hockey history as structured information.

Games, scoring events, source videos, and individual highlights became records. I could attach editing decisions, tags, timestamps, verification notes, and publication status to them.

The highlight library lets me search by date, season, opponent, home or away, video status, and points. A separate schedule view helps me reconcile game listings, source availability, participation, and scoring information. A game that was played, a game with available footage, and a completed highlight package are three different states.

Table displaying highlight library for player Liam Pecararo, showing game details such as date, opponent, result, points, and video status across different seasons.
The working highlight library tracks games, scoring, source availability, and completed video packages.

Which games am I missing? Which have footage but no finished package? Which scoring records have I checked? Where did a clip come from? The library gives me a place to answer those questions.

Those are boring questions until a project contains dozens of games. Then they become the difference between having a collection of files and having an actual system.

AI Became the Implementation Layer

I did not begin with a finished software specification. I had problems I could describe.

When I could not easily determine which games were missing, I worked with AI to build a schedule reconciliation view.

I wanted every game to have the same predictable structure, so we developed a standard game package with separate areas for source media, evidence, working files, deliverables, posting information, and quality assurance.

When reviewing clips meant jumping between folders and applications, we built an interface around the source library. An edit list gave me control over individual plays, their order, and their place in a reel.

A clip editor let me adjust trim points and carry those decisions into later renders. A comparison view let me inspect an older compressed cut beside a rebuild from a cleaner source.

The pattern repeated throughout the project. I supplied the objective, context, judgment, corrections, and increasingly specific rules. AI helped translate those instructions into code, interfaces, scripts, structured files, and repeatable workflows.

A video playback interface featuring a hockey game highlight with players in blue and yellow jerseys on the ice rink. The scoreboard shows a time of 16:27 and the score indicates SLO 2, TRE 1. The interface includes buttons for watching the reel, reviewing the library, and comparing pictures.
Selected outputs from the project, including individual game highlights, playoff highlights, full-season compilations, and aggregated reels.

It felt like having a very fast implementation layer between an idea and a working prototype. I still had to inspect what we built and explain what needed to change.

A short walkthrough of the working system, moving from game records and reconciliation into clip review, editing, and the reusable highlight library.

A Single Game Became Its Own Package

Each game now has its own package. It can include the source video, game record, thumbnail, posting copy, review notes, edit plan, clean clips, and finished highlight.

Game package interface showing a Liam Pecararo highlight, thumbnail, game information, and production assets.
A single game package connects the game record, finished video, thumbnail, posting copy, review notes, source information, and related assets.

That sounds like organizational overhead until you need to revisit a game later.

When I rebuild a season compilation, I can trace a clip to its source. When better footage becomes available, I can see what it should replace. Posting copy and verification evidence belong with the game, so I can revisit them without starting over.

The game stops being a loose file and becomes a reusable part of the system.

Each Play Became Something I Could Actually Manage

The same thing happened at the level of individual plays.

Candidate plays can also have their own records: an identifier, game, date, action type, review decision, chapter, tags, picture-quality assessment, and editorial notes.

Some plays are obvious keeps. Some are weak. Some need a better source. Some matter because of a goal or assist. Others are valuable because of skating, puck protection, a zone entry, defensive work, passing, separation, or another part of Liam’s game that does not necessarily appear in the box score.

A screenshot of a video editing workspace showing a sports highlights reel with various user interface elements, including options for editing, exporting, and viewing saved selections.
Candidate plays can be reviewed independently, tagged, assigned to chapters, kept or rejected, and revisited later.

A reel built only from goals and assists can miss much of what makes a player useful.

A scoring result tells you what happened at the end of a sequence. It does not necessarily tell you why the play was good.

In the clip editor, I can review the footage, adjust the in and out points, change the order, and assign a play to a chapter. Those decisions remain connected to the source.

Clip editor with a hockey video preview and controls for review decisions, chapters, trim points, tags, and notes.
The clip editor preserves both the source video and the human decisions around trimming, categorization, quality, and inclusion.

If a note says “keep the outlet pass and finish” or “remove the remaining celebration,” the editorial decision remains visible. If a clip is marked as needing review, that state remains part of the record.

Verification Became More Important

One of the easiest mistakes to make with AI is confusing a plausible interpretation with a verified fact. Hockey makes that problem obvious.

Players overlap. Camera angles change. Jersey numbers disappear behind bodies. Replays repeat events. Commentary and on-screen graphics can be wrong. A recap can omit the part of a sequence that actually matters.

I needed to separate two questions.

The first question is visual: is the player on screen actually Liam?

The second question is statistical: was Liam officially credited with the goal or assist?

A league game sheet can verify that Liam received an assist without proving that a particular blurry skater in a particular frame is him. Likewise, I can clearly see Liam make a pass without assuming that the official scorer awarded him an assist.

The system therefore treats player identification, video evidence, and official scoring as separate inputs that can corroborate one another.

That also guides how I use the visual player marker. It should appear when Liam’s identity is clear. When identification becomes ambiguous, the marker should disappear.

A small editing choice became a broader rule for the workflow:

Uncertainty should be visible.

Screenshot of an analysis tool interface for possession timing and passing lane in a sports context, featuring options to mark the start and end of puck control, draw lanes, and clear timing for a paused frame.
Player identification, video interpretation, and official scoring are treated as separate forms of evidence rather than assumed to be the same thing.

Human Judgment Never Left the Loop

As I added automation, I became more deliberate about where human judgment belongs.

Keep, Maybe, and Reject are explicit review decisions. Chapters, ordering, tags, trim points, quality assessments, and notes make the choices visible.

A secondary assist may show more skill than a goal. A zone entry without a point may better represent a player’s skating. A strong sequence can become a poor highlight if the camera loses Liam at the critical moment.

AI can help organize alternatives, apply rules, and automate repetitive work. I still need to judge what a clip shows and whether it belongs in the reel.

The notes make those subjective decisions traceable. They do not turn them into objective facts, but they let me understand and reconsider them.

The Quality Problem Became Its Own Workflow

Source quality became another part of the workflow.

Some earlier clips came from compressed or damaged copies. It was tempting to accept them because they were already cut and available.

We built a comparison view so I could place a previous cut beside a rebuild from a cleaner source and inspect the difference.

Comparison of two video clips showing a hockey scene: the left displays the previous cut and the right shows the source-quality rebuild, highlighting differences in clarity and player visibility.
The comparison view makes source quality part of the workflow instead of treating every existing export as equally usable.

Sharpening and upscaling cannot restore detail that the source has lost. For some clips, finding better original footage and rebuilding the edit made the larger difference.

Because the system keeps the connection between an event, its source footage, edited versions, and final output, I can replace a weak asset while retaining the decisions around it.

One Library, Multiple Outputs

The work has produced individual game highlights, playoff highlights, season compilations, and broader reels. Each serves a different purpose.

A game highlight preserves the context of one appearance. A playoff compilation follows a postseason run. A season package covers a larger body of work. A reel across seasons can prioritize the strongest material. Coverage still depends on the footage available; a season compilation is not proof that every career goal or assist has been recovered.

The early 4:50 reel contained 36 selected plays. It helped establish the review and editing process. The same library could then support other selections and longer compilations.

Screenshot of a video editing interface showing hockey game highlights. The interface displays saved reels, video playback options, and various highlight segments with timestamps and labels.
An early 4:50 iteration containing 36 selected plays. The interface organizes material by chapter and preserves the underlying clips for further use.

The work behind one video remains useful when I return to the material for another purpose. I can reuse the sources, clip records, and review notes while making a different set of editorial choices.

That is what makes this an ongoing production workflow: the finished videos are useful outputs, and the material behind them stays usable.

Watch the full highlights collection or browse the season reels.

The Project Became Structured Enough to Need Its Own Rules

Eventually, the project became too large to manage reliably through memory and intuition.

The project guide now defines the folder structure, authoritative files, standard game package, process for adding a game, master-reel workflow, and archive and rollback procedures.

GUIDE

Project guide detailing the folder map, authoritative files, and standard game package for Liam Pecararo Highlights.
The project guide defines the authoritative files, folder structure, standard game package, and repeatable production process.

SKILL

Instructional document outlining steps for saving and applying brand assets, delivering video packages, and checking for errors in production.
A detailed guide on saving branded content and editing SVG files for optimal image generation and application use, along with instructions for delivering and checking package contents, including video exports and catalog updates.

That would be a lot of structure for one video. It becomes useful when I want to keep working across seasons, sources, statistics, and future edits.

I need to be able to return months later and understand which files to trust, which versions are obsolete, and where a new game belongs.

This Is Where It Reconnected With HockeyHash

This is where the project reconnected with the original HockeyHash idea.

Schedules, statistics, footage, highlights, and scouting notes may live in separate places, but they describe the same career. The project gave me a small working example of connecting them.

Seasons contain games. Games contain events. Events connect to evidence and footage. Clips retain their tags, verification notes, and editing decisions. From that connected material, I can build different outputs.

That is closer to what Liam and I had been discussing than I expected when I started.

HockeyHash remains on hold. This project gives me a working version of one part of the thesis, with plenty still to figure out.

What I Actually Learned About AI

AI made this faster. A lot faster. That deserves emphasis: the speed changed what I could realistically attempt.

I could move between video editing, software development, data modeling, interface design, research, statistics reconciliation, and quality assurance within the same project.

I am not claiming AI made me an expert in all of those disciplines. It reduced the cost of moving between them and made it easier to try an idea, inspect the result, and revise it.

In a more traditional workflow, an idea might pass between a developer, designer, and editor every time something changed. Each handoff takes time and requires explaining the context again.

Here, I could look at a result, explain what was wrong, and work with AI to change the underlying rule. A correction could improve the next game package as well as the one in front of me.

That feedback loop is what felt new.

Expertise still mattered. I needed it to recognize a bad result and give a useful correction. AI shortened the path from that judgment to an implemented change.

The Hockey Still Has to Matter

It is easy to become so interested in the system that the original goal gets lost. The software has to help produce better hockey videos. The library has to make the outputs easier for Liam to use.

That is why I like that the finished outputs are ordinary: hockey highlights. Someone can press play. Liam can send a video to a coach.

The coach does not need to understand the architecture. The complexity earns its place by making those simple outputs better, easier to maintain, and easier to reproduce.

I started by making highlights. Along the way, I built a way to track the games, sources, clips, decisions, and evidence behind them.

That is the change I wanted to document. Working on a concrete problem made it possible to build things I would previously have left as ideas. It also made the limits visible every time a clip, statistic, or interface needed correction.

The skill I kept coming back to was defining what I wanted, recognizing when the result was wrong, explaining why, preserving what was true, and refining the work until it was useful.

That is what I want to get better at.

And I think I am only beginning to understand what can be built with it.

Browse all writing

Discover more from Erik Udahl

Subscribe now to keep reading and get access to the full archive.

Continue reading