Sugra Earth: the weather is not the answer

Nobody actually wants the weather. They want to know whether the plan survives contact with it.

Those are different questions and the gap between them is where operations live. Twenty-two degrees and eight knots of wind is not an answer to “can the crew work the site today”, “does this flight go”, or “do we hold the shipment”. Somebody still has to turn the observation into a decision, and in most organisations that somebody is a person with experience, doing it in their head, differently each time, at six in the morning.

Sugra Earth is built around that conversion rather than around the observation.

Three things stacked, and only one of them is weather

Observation. What an instrument recorded. A station report, a point forecast, sea state, solar radiation. Precise, narrow, and silent about consequences.

Event. Something is happening that has a name and a boundary. A cyclone, a flood, a wildfire, an earthquake. Events are not observations: they are declared by an authority, they have severity, and they persist.

Derived quantity. A number that did not come off any instrument, computed to answer an operational question directly. This is the layer that most weather APIs do not have, and it is the reason this direction exists.

Events arrive in one shape, whatever they are

Twenty-four hazards were active worldwide at the time of writing, and they came back in a single schema:

GET /api/v2/hazards/alerts

total_matched: 24        schema: hazard-event/2

tropical_cyclone   5     Tropical Cyclone GEZANI-26      Red      3
earthquake         6     ...
flood              4     Flood in Brazil                 Orange   2
drought            4     ...
wildfire           4     ...
volcanic_activity  1     ...

An earthquake and a drought have nothing physically in common. One is seconds long and measured in energy release, the other unfolds over seasons and is measured in rainfall deficit. They arrive here with the same field names, the same severity scale and the same geometry, because the consuming code should not need six parsers to ask one question: is anything happening near my asset.

That normalisation is unglamorous and it is most of the work. Each hazard family also has its own dedicated route when you want to watch one thing closely: wildfires from the thermal-anomaly feed, cyclones from the hurricane centre, quakes from the survey, tsunami messages from the warning centres.

The dedicated routes return the same schema. Asking the earthquake endpoint directly gives back hazard-event/2 records, magnitude in the metrics block, place as a string, geometry in the same field:

GET /api/v2/hazards/earthquakes

earthquake   2 km ESE of The Geysers, CA              mag 0.76
earthquake   12 km WSW of Harding-Birch Lakes, Alaska mag 1.6
earthquake   260 km N of Ama, Japan                   mag 4.4

So narrowing from “anything near my asset” to “earthquakes only” is a change of URL, not a change of parser. That sounds small until you have written the second parser.

The derived layer, with the formula left open

Here is the part worth reading closely, because this series has spent several posts arguing against opaque scores, and this is a score.

GET /api/v2/transport/disruption-risk?airport=KJFK

index:            0.0
band:             low
dominant_driver:  convection
components_used:  convection, flight_category, gust, hazard_overlay,
                  precipitation, wind

factors:
  flight_category  score 0.0   VFR, station KJFK, visibility 10+,
                               observed 2026-07-26T05:51Z, source noaa-awc
  wind             score 0.0   3.0 kt
  gust             score 0.0   5.4 kt, spread 2.5
  precipitation    score 0.0   0.0 mm/h, observed 2026-07-26T06:30Z
  convection       score 0.0   advisory state

One number on top, and underneath it every component that produced it, each carrying its own score, its own source and its own observation time. You can see which factor dominates, you can see what was measured, and you can disagree with the weighting because the weighting is visible.

That is the distinction the whole series keeps drawing. A derived quantity is not the problem. A derived quantity you cannot take apart is the problem. “Risk 0.73” with no components is cosplay. An index that decomposes into six timestamped measurements is an argument you can audit, and if your operation cares more about crosswind than about precipitation, you have everything needed to build your own weighting instead.

Where it changes the answer: the corridor

Point risk is useful. Corridor risk is the case that actually earns the direction its keep, and it is the one people get wrong.

Ask about a route rather than a place:

GET /api/v2/transport/disruption-risk/route?origin=KJFK&destination=EGLL

samples_scored: 24
peak:  sample 17, 4,093.7 km along, at 53.65N 21.62W
       index 75.56, band severe, dominant_driver wave
advisories_on_corridor: 3

Both airports are quiet. The departure scores zero, the arrival is unremarkable, and any check built on two station reports returns a confident green.

Four thousand kilometres out over the North Atlantic the index is 75.56 and the band is severe, driven by sea state. Nothing at either end of the route contains that information. It is not a forecasting subtlety, it is a sampling one: the question was asked about two points when the exposure lives along a line.

The method is stated in the response rather than left implied. Samples are spaced evenly by distance along the great-circle legs, interpolated spherically, and each one is scored with the same factors, the same thresholds and the same dominant-driver combination as the point index. The corridor is not a different model with different assumptions. It is the same measurement, taken twenty-four times in the places nobody was looking.

This generalises well beyond aviation. A shipping lane, a rail corridor, a convoy route and a fibre path are all lines, and every one of them is normally monitored at its endpoints.

Consequences are observable too

The layer above prediction is what actually happened, and for one domain it is published directly:

GET /api/v2/transport/aviation/delays

airports_affected: 6      by_type: 4 notam, 2 airport_closure
                          by_reason_class: runway 6

PVD   Theodore Francis Green State   airport_closure
SNA   John Wayne Airport             airport_closure, 0630-1315

Two airports closed, six events, every one of them attributed to runway conditions rather than to volume. That is the feedback loop: a derived index says exposure is rising, and this endpoint says whether operations actually broke. Log both and after a season you can calibrate your own thresholds against your own outcomes, which is worth more than any vendor’s default weighting.

The rest of the surface

Weather itself spans point conditions, hourly and daily forecasts to sixteen days, and history back to 1940, which makes “was this normal for this site” answerable rather than rhetorical. Aviation carries station reports, aerodrome forecasts and in-flight hazard advisories. Marine covers wave height, period and direction. Tides come from the national ocean service with predictions and observed water levels. The grid side reports operating data, fuel mix and interchange for several national systems, plus degree-day demand proxies.

The catalogue is large and the reference lists it. What matters for choosing this direction is the shape: observation at the bottom, declared events in the middle, and operational quantities on top with their inputs visible.

Where this stops

Earth reports conditions and computes exposure. It does not decide.

The index is not a clearance and not a permission. A low band is not authorisation to fly, sail, dig or dispatch, and the thresholds behind it are ours rather than any regulator’s. Aviation observations are advisory here and never a substitute for the official briefing your operation is required to use. A forecast is a forecast: state it as one, never present it as an observation, and re-pull before the shift rather than caching a comfortable answer for a week.

The honest description is that we remove the part where a person mentally converts numbers into risk at six in the morning, and we leave the decision exactly where it was.

Running it

H="x-api-key: $SUGRA_API_KEY"
B=https://sugra.ai

# observation
curl -sS -H "$H" "$B/api/v2/weather?lat=40.64&lon=-73.76"
curl -sS -H "$H" "$B/api/v2/transport/aviation/metar?ids=KJFK"

# declared events, one schema for every hazard family
curl -sS -H "$H" "$B/api/v2/hazards/alerts?limit=25"
curl -sS -H "$H" "$B/api/v2/hazards/tropical-cyclones"
curl -sS -H "$H" "$B/api/v2/hazards/earthquakes"

# derived exposure, with its components
curl -sS -H "$H" "$B/api/v2/transport/disruption-risk?airport=KJFK"
curl -sS -H "$H" "$B/api/v2/transport/disruption-risk/route?origin=KJFK&destination=EGLL"
curl -sS -H "$H" "$B/api/v2/transport/disruption-risk/forecast?airport=KJFK"

# what actually broke
curl -sS -H "$H" "$B/api/v2/transport/aviation/delays"

Store the components, not just the index. When someone asks in three months why a shift was stood down, “risk was severe” is not an answer. “Wave driver at 75.56, four thousand kilometres along the corridor, sampled at 06:30” is.

Conditions and computed exposure, not clearance. Values pulled live 2026-07-26.

Previous: Sugra News. Next: Sugra Research. Full series: Platform intro.