Risk Window & Go/No-Go Gates
The Risk Window Gate is a mandatory acknowledgment modal when ETD intersects forecast IFR or thunderstorm conditions, with a Zulu-stamped persisted decision.
Risk Window & Go/No-Go Gates
The Risk Window is the briefing's hard gate against the most common preventable accident pattern: launching VFR into a forecast that is about to deteriorate. It evaluates whether your estimated time of departure intersects a window of forecast IFR conditions or thunderstorms, and if it does, it forces an explicit acknowledgment before the briefing can be treated as complete.
When the gate fires
The gate fires when the destination or en-route forecast — interpreted under AC 00-45H §5.11 group weighting (PROB30 0.3, PROB40 0.4, TEMPO 0.6, BECMG 0.85, FM 1.0) — produces an IFR or TS window that overlaps your ETD. A clean forecast over the planned departure time produces no gate; a TEMPO IFR group during your taxi-out produces a hard one.
The modal itself is rendered with a red border and is mandatory — it cannot be dismissed by clicking outside it. The briefing cannot reach a CLEARED Ops Authority verdict while the gate is unanswered.
The four pilot acknowledgments
The Risk Window Gate offers exactly four options. Each one is a different operational response to the same forecast:
| Option | Meaning |
|---|---|
| Delay | Push ETD past the forecast window. The briefing is regenerated against the new departure time. |
| Special VFR (§91.157) | Pilot intends to request a Special VFR clearance. Surfaced only when the airspace and conditions make §91.157 applicable. |
| IFR file | Pilot will file IFR rather than push VFR through the window. |
| Acknowledge VFR with mitigations | Pilot accepts the risk and documents the mitigations they are applying. |
The gate is not a recommendation engine. It does not pick for you. It documents that you saw the window and chose a response.
Server-stamped, persisted decision
The selected option is server-stamped with a Zulu timestamp and persisted to FlightPlan.riskWindowDecision. The read path uses a Zod schema (riskWindowDecisionReadSchema) so a malformed or partial decision blob degrades safely rather than crashing the briefing.
The persisted decision serves three purposes:
- It feeds the Ops Authority Panel as one of the inputs that gates a CLEARED verdict.
- It reappears in the rendered PDF, so the artifact carries proof the gate was answered.
- It is part of the briefing snapshot diff — if you regenerate the briefing later under different conditions, the prior decision is preserved as historical evidence.
Other Go/No-Go gates the briefing layers on top
The Risk Window is one gate among several. The briefing also evaluates:
- The §91.103 affirmative preflight action checklist — eight rows (runway lengths, takeoff and landing distance, fuel, alternates, traffic delays, weather, airworthiness verified). Any red row blocks a clean verdict.
- §91.151 / §91.167 fuel reserves appropriate to category (helicopter day VFR 20 min, helicopter IFR 30 min, otherwise the airplane defaults).
- §91.169 1-2-3 IFR alternate rule check against the destination forecast.
- Airworthiness — §91.7(a), §91.409, §91.411, §91.413, §91.207 inspections plus ARROW documents, each with time-remaining color codes.
- Currency — aircraft-aware (tailwheel hidden for non-tailwheel; high-altitude hidden for unpressurized; SFAR 73 for R22 and R44 with 24-month recurrence).
The Ops Authority Panel: one verdict, not five
The Ops Authority Panel is the single source of truth at the bottom of the briefing. It collapses the §91.103 checklist, compliance, airworthiness, FRAT, and the Risk Window decision into one composite verdict — CLEARED, HOLD, or NO-GO — with action recommendations.
This explicitly replaces older briefing layouts where Page 1's GO/NO-GO and Page 10's risk assessment could disagree. If the Ops Authority Panel says HOLD, the briefing says HOLD. There is no second opinion further down the page.