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.
The aerodrome baseline (rule AB-0.1). An assessment starts from the state of the aerodrome itself — the Aerodrome Manual, the SOPs, the markings, signs, lighting and fencing, and the inspection and maintenance record behind them. AIrport 360 carries that as a standing register, and it prices it in one direction only.
Meeting the declared standard is worth ×1.00 — no reduction. The published rates behind every chain in this model were measured across aerodromes operating to Annex 14, so the standard is already inside the base rate: an aerodrome that meets it is not safer than the reference population, it is the reference population. Crediting conformance would count the same thing twice. What the register prices is drift away from the declared state:
- Condition below standard, from an inspection — markings faded, signs obscured, fence breached. Scaled by how recent the finding is, on the same observation-weight machinery everything else uses.
- Maintenance past its interval. The schedule in the manual exists because not every kind of decay shows up on an inspection, so an overdue round is priced even when the element still inspects clean. It is not charged on top of an already-observed degradation — there, the overdue round is what caused the finding, and charging both would count one lapse twice.
- Condition never recorded — neither evidence of degradation nor evidence of conformance. Takes the class-share mixture at full prior width and is flagged, never silently assumed serviceable.
- Defeats reported in service — the driver who crossed a lit holding position and was stopped. The aerodrome's own defeat rate is conjugate-updated against the rate the reference population implies, exactly as a chain's event rate is. Occurrences that are the modelled event go to the chain's history instead, where they already raise the rate; splitting them keeps one occurrence from being counted twice, and means near-miss reporting visibly moves the number.
A clean defeat record returns the reference and earns nothing beyond it. A complete movement count legitimately pulls a chain's rate down, because it is auditable; defeat reports are voluntary and under-reported, so their absence is weak evidence and paying for it would price silence.
Every element is reported whether or not it is priced — "considered, nothing found" is what an auditor needs, and silence would read as "never looked at". The tool consumes the operator's own recorded positions from its own manual as evidence; it does not assess or certify conformance with any standard.
Controls already in place (rule CR-0.1). A change is never assessed against a bare hazard. The SOPs, permit processes, infrastructure, markings and handling arrangements the airport already has are declared on the assessment and credited into the residual — otherwise the tool prices a hazard nobody actually runs, and every scenario reads as unacceptable. What belongs here is what is supplementary to the aerodrome baseline above: controls put in place for this specific change, over and above the standing state the base rate already assumes. Three rules keep that credit honest, and all three are visible on the output:
- Credit follows evidence, not assertion. Each control is credited only against a current assurance record — a permit register, an apron audit, an inspection, a bulletin acknowledgement. The credited factor is the elicited effectiveness raised to the power of the assurance weight, so a record that is fully current gives the full credit, a stale one relaxes it toward no effect, and a missing record — or one that falls short of the condition the credit was elicited against — gives no credit at all. The control is still listed; it simply earns nothing until the operator can show it is working. Refreshing the record brings the credit back mechanically, which usually makes it the cheapest item on any action list.
- Same-pathway controls are not multiplied. Controls that work through one mechanism — a painted jet-blast warning and a bulletin both rely on the driver noticing and remembering — are not counted twice. The strongest is credited and the others are recorded as reinforcing it. This is the same rule that stops wet runway and low visibility being double-counted on the hazard side, applied to the credit side.
- Total credit is floored, and the cap comes first. Stacked elicited control effectiveness is exactly as untrustworthy as stacked elicited hazard factors, so the combined credit is floored at ×0.10 and says so when it binds. The ×30 cap is applied to the hazard stack before credits, so a real control on a capped chain still moves the number instead of being silently swallowed.
The output shows all three rungs — the hazard before credit, the residual with the controls already in place, and the residual as assessed including any proposed mitigation — because the credited figure on its own tells you nothing about how much of it rests on controls continuing to work.
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.