“A forecaster called us and said, “you know, the model is saying this and I do not agree.” Between that day and the next, there were 19 avalanches in one canyon just on that layer.”
The challenge
The Utah Avalanche Center has been keeping people alive in the backcountry since 1980. Eight geographic forecast areas, one forecaster for each, two more who float between them, and every forecast assembled by hand from fieldwork, local weather station data, and a longstanding partnership with the National Weather Service. The Utah Department of Transportation, the Department of Public Safety, ski resorts, guide operations, and local search and rescue teams all make decisions off that output.
The process behind it was manual. A forecaster’s morning meant sifting through dozens of weather stations, comparing several weather models, and reading field notes and public observations, then forming a judgment in time to publish.
In 2023 the UAC got access to SNOWPACK, the snow cover model developed by the Swiss Institute for Snow and Avalanche Research (SLF), and retrained it on Utah snow and weather conditions using data from hundreds of rutschblock stability tests. The science worked. The software did not exist.
A lab result is not a forecast
The model ran on a desktop and nowhere else. The UAC used it for backcasting: every few weeks, they would run it over the period just passed and compare what it had predicted against what had actually happened, to check that SNOWPACK was tracking Utah reality. That is exactly the right way to validate a model. It is not a way to forecast with one. It looks backwards, it runs on a cadence that has nothing to do with when a forecaster needs an answer, and it produces raw output that a human then has to interpret alone.
A desktop model
Run by hand every few weeks. Backward looking. Raw output, no visualization of any kind, interpreted by whoever ran it. Valuable as validation, unusable inside a forecasting morning.
A production system
Running on a schedule, on the freshest data available, projected forward, and rendered so a forecaster reads it in minutes. Something an entire prediction system could rest on.
There was no specification for how to get from one to the other. Chad Brackelsberg is direct about it:
“We came to the team with sort of a black box, without a design, without even a requirements document. And that is always the hardest, saying ‘build me a house’, but we never said how many bedrooms, how many bathrooms, how big, where or anything.”
The two constraints that shaped everything came out of how a forecaster actually works. The output has to be waiting at 4AM and 4PM, carrying the most recent data possible, because a run that lands at 6AM is a run nobody uses. And it has to save time rather than cost it: a tool that adds a step to an already heavy morning gets abandoned no matter how good its output is.
What we built
Tarmac owns the whole chain, from the weather station to the forecaster’s screen. Three people built it: a tech lead on architecture and pipeline design, an AI and data engineer on model operationalization, and a data analyst on visualization, working with two UAC forecasters and an SLF SNOWPACK expert across Utah, Switzerland, Minneapolis, and Poland.
-
Ingestion
Microsoft Fabric
Pulls from physical weather stations, NOAA, and HRRR forecast data into a medallion architecture warehouse. One governed place for every input the model needs.
-
Compute
Azure VMs, on demand
SNOWPACK is a C++ library, not a service. The VMs spin up to run it and shut down when the run finishes, so the model's cost follows the schedule instead of the calendar.
-
Delivery
Power BI
Its design workflow is iterative, which is the real answer to the black box: forecasters argued with working dashboards throughout development instead of signing off static mockups they could not test.
-
Ingest
1. Collect every input
Weather station telemetry, NOAA observations, and HRRR forecast data land in Fabric. The run is only as fresh as its slowest source, which is why the schedule is built backwards from 4AM rather than forwards from whenever the data arrives.
-
Prepare
2. Clean and shape it for the model
PySpark transformations move the raw feeds through the medallion layers into the exact form SNOWPACK expects. This is the stage that got rewritten, and the stage the speed came out of.
-
Model
3. Run SNOWPACK
Azure VMs spin up, execute the model across every configured site, and shut down. Danger level and instability models run alongside it, with a separate validation workspace comparing output against known data results before anything is promoted to production.
-
Publish
4. Render it as a decision
Results land in Power BI segmented by location, user, and organization, so each group sees only what is relevant to them. The forecaster opens one dashboard, not a folder of model output.
Prove it first, then make it fast
During the proof of concept we built the architecture as a literal, one to one translation of the initial flowchart. No cleverness, no optimization, just get the early data moving so everyone could see whether the output was accurate and whether it was useful. Optimizing an architecture before you know it is the right architecture is how teams spend a season making the wrong thing fast.
Once it was proven, we optimized. Rewriting the processing in PySpark cut the end to end time by a factor of six.
Five hours is the difference between a forecast built on last night's data and one built on this morning's. It matters most on exactly the mornings that matter most, when it has snowed overnight.
What the forecaster gets out of it is instability trends by aspect, north, south, east and west, with yesterday, today and forecast side by side; modeled danger level plotted against human forecasted danger level over time; weak layer development tracking surface hoar formation and facets in the top 30cm; projections at 12, 24, and 48 hours; and season, week and day views with change indicators.
The results
Through the proof of concept and prototyping stages, the model achieved a 0.86 correlation with human forecasts. That number is the license for everything else: a decision support tool that disagrees with an expert forecaster most of the time is noise, and gets ignored within a week.
The numbers that matter more are the ones where the model caught something people had missed.
-
19 avalanches
Late February into early March 2025, the model identified weak layers in the snowpack that forecast staff had missed and predicted high danger. A forecaster called to say he did not agree with it. Between that day and the next, 19 avalanches ran in one canyon, on that layer.
-
4 of 4
The system identified all four radiation recrystallization events across three seasons. These happen once or twice a year and are easy for a human to overlook. The model did not miss any of them.
-
16 miles
On 20 March 2025 the system flagged high danger and pronounced instability layers near the Skyline area, working from a weather station 16 miles from where an avalanche later occurred. The model forecast it, and it happened.
-
3 road events
For UDOT, the instability model identified conditions tied to real events on the road network: debris reaching the edge of a roadway, a 50 foot wide slide onto a closed road where maintenance workers were present, and an event that struck three cars.
None of those four is a claim that the model is better than a forecaster. They are the cases that build the only thing a decision support tool can actually run on, which is trust.
Every few weeks, backwards
No visualization of SNOWPACK output existed at all. A forecaster who wanted model data ran it on a desktop and interpreted the raw results, never close to real time, and only ever about a period that had already happened.
Twice a day, forwards
A dashboard that updates at 4AM and 4PM with the most current data available, projected 12, 24 and 48 hours ahead. Most valuable on the mornings when it has snowed overnight and yesterday's picture is worthless.
The efficiency gain is quieter than the accuracy story but it is the one forecasters feel daily. The tool works as an additional data source that helps prioritize where to look next: narrowing 20 weather stations down to the four that matter this morning. That gets the forecast published sooner, and it improves the decision behind it, particularly for the rare events a manual scan is most likely to walk past.
It left the building
The system had to serve more than UAC forecasters. It started at 3 sites during the prototype phase. By the 2025/2026 season it was running at more than 15, and the dashboard segments by location, user, and organization so each group sees what is relevant to them.
- 15+sites, up from 3 at prototype
- 2avalanche centers, in Utah and Montana
- 1department of transportation
- 4ski resorts
- 1guiding operation
- 1consultancy
What is next
The current models are built for persistent grain avalanches and do not yet account for new snow or wet snow events. We are building bolt on models for both, including using temperature sensors in the snowpack. Wet snow is the priority: those avalanches are difficult to predict, frequently large, and often the ones that reach roads and infrastructure.
Beyond that, an adaptable learning model that would predict avalanche danger from historical weather, avalanche, and danger level data, similar in concept to what Google DeepMind has done for weather forecasting. A purpose built web viewer to replace Power BI as the delivery surface as the user base grows. Longer term, agentified models with automated triggers, on demand runs, and notification when conditions change.
None of which changes what the thing is for. Chad again:
“Our goal is not to have a model that is smarter than the human. It is a decision support tool. Through these use cases, we can help gain that trust of the forecast team, so that when they look at it, maybe they do not have 100% confidence that the layer is a concern, but enough to come back to in their forecast. They can write ‘this might be an issue, watch out for it’.”
The hardest part was never the algorithm. The algorithm arrived from Switzerland already working. The hard part was everything between a model that produces a correct answer and a forecaster who has that answer in front of them at 4AM, in a form they can trust.
Have a project like this one? Talk to us about your data and AI work.
Tech stack
- Microsoft Fabric
- Power BI
- Azure
- Python
- PySpark
- SNOWPACK
- Medallion Architecture