What's the job?
Today's conditions
Tap what matches. The job card has already picked the likely ones.
How fresh is our data?
Traffic in the window
Sign-off
Your assurance statement, under your name — that the hazards are captured and mitigated. This is not a permit approval; the decision is yours, the tool only gave you the evidence.
Hold on — a reason is required
Activity / change intake
New assessment — a works package or a management-of-change activity
Load an activity preset — a works package on or adjacent to the runway, or a Management-of-Change activity such as a new procedure or infrastructure change — or fill the form from scratch. Every field either feeds the risk ledger or is echoed in the assessment record.
Evidence pack
Assessment results
AIrport 360 is assurance and decision support — it gives confidence that the relevant hazards are identified, captured and mitigated. It sits alongside your permit process, not within it: it does not approve or reject anything. It produces supplementary evidence behind your accepted matrix, and the residual it shows is a living value that moves as conditions — weather, traffic, serviceability, manpower — change. The assessor remains responsible for every decision.
Conditions & mitigations — what-if (scenario copy)
Toggles run a working copy of the submitted permit and show both results side by side. The submitted permit is never altered by a toggle — use “Apply to permit form” to adopt a variation explicitly.
Assessor sign-off
The assessor's own assurance statement — that the hazards are identified and mitigated. Not a permit approval; the tool's role ends at evidence, and the residual remains a living value that moves with conditions.
Gate rule (stated here because it blocks generation): a named, typed rationale is mandatory whenever (i) the computed cell of any active chain is lower-risk than the hazard-register entry, or (ii) the assessor’s decision is more permissive than the evidence summary — accept / accept-with-conditions while the worst active chain is in a beyond-validated-range cap regime or its assigned cell sits in the matrix top corner (likelihood + severity indices ≥ 8: L5/C, L4/B, L3/A or worse; a bare L5 with severity mass in D/E does not gate, because the frequent-but-minor chains sit there at baseline). Inactive chains never gate. No record can be generated with an empty rationale in those cases. Model-driven upgrades pass automatically; downgrades and overrides never silently.
Sign-off gate — named rationale required
Plain-English glossary
- Distribution
- The spread of results across all simulated repetitions of tonight, not a single number.
- Percentile (e.g. 90th)
- The value that 90% of simulated repetitions stay below.
- 90% interval
- The range holding the middle 90% of simulated outcomes — a statement of uncertainty, not a forecast.
- Exceedance
- The chance of at least one event at or above a given severity class.
- Central chain
- The hand-recomputable headline: posterior-mean rate × the median of each active factor.
- MC median
- The middle value of the full Monte Carlo sample — sits below the central chain because rare-event rates are right-skewed.
- RR-propagated 90% interval
- The uncertainty coming from the risk factors (RR = risk ratio, the “×4 wet runway” style multipliers) only, drawn around the central chain — the base rate is held fixed.
- Posterior mean
- The class base rate after your own history has been folded in — the “best single number” for the rate.
- Conjugate update
- The exact arithmetic (no simulation) that folds your history into the base rate: add events to one number, add exposure to the other.
- Estimand
- The precise quantity a number claims to be. Every figure here is labelled with its estimand so a mean is never passed off as a median.
- σ base → eff
- The factor’s uncertainty width from its evidence, and the widened width actually sampled when the driving observations are stale or missing.
- Log-asymmetric (flagged)
- A declared interval that isn’t symmetric around its middle in ratio terms — reported to the methodology owner rather than silently reshaped.
- “≥” on a figure
- A floor, not an estimate: the stacking cap has clipped the upper tail, so the true value can only be higher.
Moving residual
Living residual — moves with conditions
This is the same accepted assessment, live: the residual you signed off is not frozen. Move the conditions below — surface, wind, edge lighting, GRF-current cover, traffic — and watch the residual and its matrix cell change. It is assurance that the hazards stay captured and mitigated as conditions change, not a permit approval; the tool's role ends at evidence and the assessor remains responsible. Same engine, same seed — identical conditions always give the identical residual.
Run an assessment first — then this view lets you move its conditions and watch the residual move.
Move the conditions
You are moving these by hand — the manual precursor to a connected airport that would feed them in automatically. This runs a working copy of the accepted assessment; the submitted permit and its record are never altered.
How the residual has moved
Methodology
How AIrport 360 works
What it is. AIrport 360 is a forms-fed state model: the state of the aerodrome changes when a form is submitted — a works permit, a daily inspection, a METAR — never by magic. From that state it produces supplementary evidence behind your accepted matrix: probability and severity distributions with every assumption on display. The residual it reports is a living value — it moves as the state (weather, traffic, serviceability, manpower) changes, so the same job reads differently at 05:30 than it did the night before. It is assurance, not a permit-approval gate: it gives the operator confidence the hazards are captured and mitigated, and the assessor remains responsible for every decision, forever.
The frequency model. Each event chain — runway excursion on landing (RE), vehicle/pedestrian deviation (RI, the works-driven incursion mode), vehicle/plant–aircraft ground collision (GCOL), bird strike (BIRD), works-debris damage (FOD, ADRM-coded) and jet blast (JETBLAST, RAMP/OSHE-coded — the management-of-change demonstration chain) — starts from a class base rate encoded as a Gamma prior over the event rate. Each chain carries a first-class evidence grade (P-fit: published fitted models; P-anchor: published aggregate with assumed decomposition; E: elicited — jet blast is E, an expert estimate, because no published jet-blast rate model exists) and, for P-anchor chains, its single load-bearing assumption printed in the ledger header. Chains keep separate exposure denominators — bird-strike and excursion exposure runs across the whole assessed horizon; incursion, vehicle-collision and debris exposure exists only during works windows — and per-chain probabilities are never summed into one figure. Your own history updates it by exact conjugate arithmetic (Poisson–Gamma). With zero local excursions in 60,000 landings the posterior barely moves: you are your class, and the tool says so — with the credibility weights printed in the ledger. Local learning is precursor-based: the model learns your risk-factor profile (surface state, friction currency, works discipline) — never "your accident rate".
Conditioning. Tonight's state activates multiplicative risk factors, each a lognormal random variable specified by a median and 90% interval, with its source and evidence class (P published / E elicited) printed in the risk ledger. Correlated covariates enter as one coherent set (no wet × low-visibility double-count); the total stacked factor is capped at ×30 with the cap status displayed, never hidden. The headline is the central chain — posterior-mean rate × median factors — recomputable on a calculator from the printed ledger. Uncertainty bands come from a seeded Monte Carlo (documented PRNG, seed and iteration count on every output).
The cap regime (validated range). The ×30 stacking cap is a guard-rail, not physics. When the cap binds materially — the median stack exceeds ×30, or more than 20% of iterations are capped — the combination of factors sits beyond the model’s validated range and the tool stops quoting precise probabilities: affected figures are printed as floors (“≥”), the answer line says so in plain words, and the results list which mitigations would bring the stack back within range. A capped figure is a floor because the true uncapped value can only be higher. This threshold (20%) is fixed and documented here; stale-data widening that is clipped by the cap is flagged next to the interval rather than silently absorbed.
Data coverage. Stale or missing observations widen the sampled intervals mechanically: observation weight decays with a published half-life, and unobserved variables fall back to the class prior at full width — never to a silent "serviceable". The coverage panel shows observed / aged / imputed per variable, with the widening effect stated in plain English.
Severity and the matrix. Severity is a distribution over ICAO Doc 9859 classes A–E, conditioned on your actual RESA and obstacle geometry via a location-curve model; it is never multiplied into frequency to make a single score. The 5×5 view is a projection of the distribution onto the operator's accepted matrix under a fixed, versioned rule (likelihood cell = band of the 90th percentile), with band edges configurable to the operator's SMS manual and cell occupancy always shown, so the matrix can never disagree with the distribution behind it.
Governance. Model-driven cell upgrades may be automatic; any downgrade against the hazard register — and any assessor decision more permissive than the evidence summary — requires a named sign-off with a typed rationale before a record can exist (to see the downgrade gate fire, run the grass mowing preset). The tool never issues a verdict or approval: the results page opens with an evidence summary, written in evidence-voice and labelled as such, for the named assessor to adopt or strike; completion is "assessment record generated", nothing more.
References
- mvp/data/data-notes.md — per-number sources and confidence for every coefficient in the demo dataset (the audit table).
- ACRP Report 50 — fitted excursion frequency/location models; the Phase-1 coefficient source (illustrative magnitudes until transcription).
- FAA RWS / ATADS — incursion counts over movement denominators anchoring the V/PD class prior (parameters illustrative).
- ICAO Doc 9859 (4th ed.) — severity classes A–E; matrix scales are the operator's own.
- UK CAP 760 — precedent for numeric likelihood-band quantification.
- Vose, Risk Analysis: A Quantitative Guide (3rd ed.) — Poisson-Gamma conjugate pattern and lognormal factor parameterisation.
No regulatory authority has assessed or accepted this tool or its outputs.
Band definitions, decay constants and mapping rules are demo defaults, configurable to the operator's
SMS manual at onboarding. Verification: the engine ships with a self-test suite (engineer checklist
T1–T5 + M-checks + five-chain C-checks + jet-blast J-checks, 32 tests) — run the self-tests in this browser or
node js/selftest.js.
Verification
Engine self-tests (engineer checklist T1–T5 + M-checks + five-chain C-checks + jet-blast J-checks)
Running 32 checks at 20,000 iterations — typically 5–20 seconds on this machine. If nothing appears after that, an error has occurred and will be printed here.