Six models, one clock. Each answers a different question, over a different stretch of time, against the same present.
As our team continues to build out DeepSky, the second generation of our satellite constellation, our data science and atmospheric modeling group has been working on something else: how we think about weather modeling in the first place.
What has come out of that is a decision-oriented modeling stack — a set of models, each built for a different kind of call.
Read the DeepSky announcementSee DeepSky
Last month we introduced Sky, the atmospheric state model — the picture of the present that every forecast starts from, rebuilt every hour from our own satellites.
Published 5 August
Introducing Sky: The Atmospheric State Model
Why the layer underneath every forecast shapes everything built on top of it.
This month we go further down the stack. Over the next few posts we will walk through the models our customers are running on every day — how the buildout was reasoned, which of them are new, and what makes each one suited to a particular kind of operation.
Starting with why there is a stack at all.
Five windows, five different jobs
Before the models, there are the operational windows they must be optimized for. An operation does not meet the weather once; it meets it five separate times along the decision cycle, and each encounter asks for something different. Sky is not one of the five — it is the picture of the present that the other five all start from.
Decisions made while the job is running. What matters is speed and specificity: when it starts, when it stops, how hard, how long — refreshed on the same clock the weather runs on, resolved as finely as the window needs, and leaning on live observation for as much of the answer as it can carry.
The strategic moves are behind you. This is navigating the operation live, and making the late calls that salvage a shift or take advantage of a gap that opens.
Time is still on the table. The most advantage-creating moves may already be gone, but the options that remain have more leverage now than they will when the event arrives.
What matters is exposure, vulnerability, extent, and the workflow the decision sets in motion — weighed against what it costs and against how certain the operator actually is and the operation’s ability to execute in the time that remains.
The model has to produce scenarios rather than an answer: worst case, best case, most likely, across every parameter that matters to the protocol.
It has to be calibrated to its region, run at higher resolutions, and refresh at the rate the sky is changing — because there is no such thing as a scheduled weather decision, and whenever the call comes, the most current read has to be the one in hand.
This is where the largest moves live and where certainty is lowest, which is the whole tension of the range. Occasionally a call this far out creates real advantage — booking scarce capacity before anyone else wants it, staging equipment, setting a season’s operating calendar. Mostly it is not for triggering action at all. It is for building awareness and putting plans in place, so that when the decision window opens nobody starts from zero.
That changes what the model is for. At this range the useful output is not one answer but the spread between answers. Several sources will disagree, and the disagreement is the information: a plan built on a narrow spread can be firm, a plan built on a wide one should stay optional and cheap to unwind.
So the work is to make that disagreement legible, and to sharpen the picture beyond what the raw sources give on their own — not to manufacture a confidence the atmosphere has not offered.
The event is over, and somebody needs to know exactly what happened. Not what a place tends to see, and not a summary — whether it happened at all, where, when, and how hard.
That is a question of proof rather than planning, and it is answered by rebuilding the recent past in detail: hours or weeks back, at high resolution, across as many parameters as can be recovered.
It is the shortest of the backward jobs and the most exact. The archive can tell you what a location has borne across years; it cannot settle what happened on one particular afternoon.
Here the history is the asset, and specifically the longer-term archive. The question is not how to navigate the next operation, and it is no longer what happened on any one day — that belongs to the forensic window. It is what a place has been exposed to over time, and what a target will bear if it is committed to that location for years.
The model has to recreate the past efficiently and at high resolution, leaning on known observations where they exist and scaling trained models backward where they do not. These are the decisions that move long-term balance sheets, and they get argued long after the weather is gone.
Five windows, and no operation lives in only one of them.
Working session
Work out which window each of your calls belongs in.
Most operations sit in more than one of the five without ever having named them. A working session is where they get named — your decisions, the window each one falls in, and which model that window is asking for.
- You bringThe calls your operation makes against the weather, in the terms you already use for them.
- We placeEach one on the clock — tactics, decision, strategy, forensic or risk.
- You leave withThe window each call sits in, and which model that window is asking for.
Our customers were solving a different problem
Over the 10+ years of building models, we’ve worked with operators across more than 30 different industries. Along the way one thing became clear: none of them benefited from an improved weather forecast alone.
Each organization arrived with a business workflow already sitting in front of them, and what they wanted was to make its success rate better. What met that need was never a better forecast in general — it was a model built for the kind of call they were making, at the range they could act within, and tuned to the risk that decision carried.
And so, over time, we began aiming our modeling improvements at those decisions.
One operation, one forecast, read five different ways. What changes down the column is not the weather. It is what the operator is standing in front of when they read it — and that is what the model has to be built around.
Your rows will not be these ones. Tell us what your operation actually runs on and we will put its decisions in the same grid.
The same window, set differently
Naming the window is the easy half. Two operations can sit in the same one and still need the model set differently — a different place, a different parameter, a different tolerance for being wrong.
The window says which model. The setting says which job.
So the window is only the first choice. Underneath it sits a second one: how the model is set for the job it is doing — how far ahead it looks, how often it refreshes, how tightly it resolves the ground, which measurements it is held to, and which weather it is tuned to get right.
None of those choices is a preference. Each answers a question somebody has to act on, and behind all of them sits one machine. The only question is which dial to move, how far, and for which decision.
Every dial in that row is set deliberately, for a decision somebody has to make, and the models all reach an operator through one platform. A demo of the platform goes window by window and shows where the dials sit for each one.
Which leaves the input. A dial can only be set as finely as the observations behind it allow, and that is the part we stopped waiting on.
What we’ve been building all along
The models came first, aimed at those decisions. Then we began layering in our own constellation. Instruments we operate change what a model can be told about the atmosphere — what it is doing right now, sampled on a schedule we set rather than one we wait on, and what it has already done, in the record those same instruments keep building.
None of this was aimed at a model that scores better in the abstract. It was aimed at the moment an operator is standing in, and at what is still possible to do about it from there.
Still to come
Five more posts, one per window. They are laid out here in clock order — starting at the event itself and working outward, forward first, then back.
What is about to happenthe event, then days out, then weeks out
The event is already on you
Why a forecast is the wrong instrument once the job is running
The calls made while the work is already under way, and what they ask for instead.
One to two days out
Weighing a decision instead of forecasting one
Why one model is not enough when the call has to be made against a threshold.
One to two weeks out
What a plan can and cannot assume
Where the largest moves live and certainty is lowest, and what a model is for when it cannot give one answer.
What already didweeks back, then years of record
Hours to weeks back
Proving what actually happened
Not what a place tends to see and not a summary — whether it happened, where, when, and how hard.
Years of record
Defending a number long after the weather is gone
Recreating the past so what a place has been exposed to can be argued from the record rather than from memory.
In testingWe have been running this one with partners for over a year.
The names come with the posts. We will take them one at a time.
Two ways in
You can reach the models directly, or start from the operation and work back to them.
Build on it directly.
The same models sit behind the API. You can sign up and start pulling from them without talking to anyone first.
Or start from your operation.
Tell us what you run and which calls hurt, and we will work out which of these windows the decision belongs in before anyone talks about a model.
