05 Occurrence reporting, and a proposal to feed our data as the start of a standard

Status: DRAFT v0.2, 2026-08-19. Part A is the reporting route each member follows (and the service supports). Part A applies to us as member one. Part B is the proposal we intend to float with the CAA (BVLOS Ops Forum, UTM consultation) and NATS.

Part A: reporting route

A1. Obligations

Mandatory Occurrence Reporting under UK Regulation (EU) 376/2014 as retained, via the CAA's ECCAIRS 2 portal, within 72 hours of becoming aware. Applies to accidents, serious incidents and the listed occurrence classes, including loss of control, airspace infringement and airprox.
Accidents and serious incidents to the AAIB immediately.
Anything else: internal occurrence record, same schema, no external obligation but shared under Part B where the operator consents.

A2. Internal route

Trigger: any SPI alert (03), any BATT_CRITICAL, BATT_EMERGENCY_LAND, HOLD_TIMEOUT_LAND, airborne AIRFRAME_REFUSED, INTRUSION_DETECTED unresolved, WAVE_OFF with third party present, or any report by a person.
Within 1 hour: SM opens an occurrence record (schema occurrence in schema/reporting-v0.json) and takes a read-only copy of the ledger slice for the flight.
Within 24 hours: HE class, phase of flight, barrier story, configuration identifier and part status filled from the ledger; outcome and escalation path recorded.
Within 72 hours: MOR filed if in scope; otherwise record closed as internal.
Review at next weekly SPI review; hazard log updated if a barrier did not hold.

A3. What the ledger gives the report for free

Report field	Ledger source
Configuration identifier	`PERMIT_ISSUED` / `MISSION_REQUEST` config_hash
Part identity and life status	`modules` table, `OVERHAUL`, `SCHEDULED_MAINTENANCE`
Barrier story	gate denials (`MISSION_DENIED` reason), `BATT_*` ladder, `DIVERT_ORDERED`, `DIRECTIVE_ENFORCED`, `WAVE_OFF`
Outcome and escalation	`flights.status`, `LANDED`, `REFUGE_LANDING`, `HOLD_TIMEOUT_LAND`, `BATT_CRITICAL`
Timeline	`_ts` on every event, chain order

Part B: the proposal

B1. The ask, in one paragraph

The CAA accepted an action on 9 July 2026 to define the minimum data it wants from BVLOS operators. We propose not to wait. We will begin submitting our own assurance data now, on a small typed schema, to whichever neutral party the forum nominates (or to the CAA directly if preferred), and we invite other operators to do the same. The schema starts with five fields any operator already has, and grows toward the full minimum reporting set in the CAA's own hazardous-event and barrier vocabulary. The goal is that when the CAA's formal data request lands there is already a corpus, a habit and a proven pipe, and that the request can be written against what the data has shown rather than what a committee predicts. We ask the CAA to treat this as the seed of a reporting standard, and NATS to treat the same records as the interface data for corridor operations in or near controlled airspace.

B2. What we commit to

First submitter: from our first live flying day, day-one records for every flight.
Seed corpus now: the v1 simulated evidence run through the schema, labelled simulated, so the standard is shaped against worked records before anyone flies (06 section 6, schema/examples/periodic_summary_v1_sim.json).
Occurrence records on the full schema for every occurrence, anonymised at source.
A periodic summary each month.
Publishing the schema (schema/reporting-v0.json) under an open licence, and accepting changes from any operator or from the CAA.
Machine delivery: a Signet.SMS export that emits these records directly from the ledger, so the cost to us of submitting is zero after setup, and we can show the CAA what "conformance as a delivery target, not a compliance project" looks like.

B3. The three tiers of the schema

Tier	Record	Fields	Who can do it today
0 Day-one	`flight_day_one`	platform type, hours of service, flight start/stop, operating location, free text	Every operator, by hand, in minutes
1 Occurrence	`occurrence`	HE class, phase, barrier story, configuration id, part status, outcome/escalation, plus the novel classes: refusal-to-arm reason, pilot intervention/handover reason	Operators with any flight log; SigNet fills it from the ledger
2 Periodic summary	`periodic_summary`	flight hours and sorties per type, fleet size and configuration classes, life-limited-part status and retirements, refusals to arm by class, interventions by class, SPI values	SigNet automatically; others as tooling allows

Every record carries integrity for its key claims (L1 to L6, ADR-0007) so a regulator can weigh a self-reported hour against a measured one without the schema pretending they are the same.

B4. The broker

We prefer an industry-governed neutral broker that stores, anonymises and works the data before anything reaches oversight: the CAA gets worked signal, operators get protection, the corpus starts now. Candidates exist within the forum's reach. If none is stood up within a quarter, we will submit directly to the CAA and publish our own aggregates.

B5. What we ask of the CAA

Say whether the five day-one fields are the right five.
Adopt (or correct) the HE01-04 plus barrier-story framing in Tier 1, so occurrence reports speak the regulatory SMS's own language natively.
Accept refusals-to-arm and pilot interventions as reportable near-miss classes.
Let authorisation carry or reference a per-flight statement of condition, verifiable by the authorising party (our UTM consultation answer to Q18), so Tier 1 and 2 records can be bound to the flight they describe.

B6. What we ask of NATS

Confirm whether the same occurrence and periodic_summary records, plus a live picture feed (ADR-0009), would satisfy the data side of an ATM-interface safety case for a corridor adjacent to or inside controlled airspace.
Name the integration point (data format, cadence, who holds the chain-head anchor).
Consider holding the L5 independent-custody anchor for authority ledgers: a periodic signed chain-head deposit, no operational data, which makes every operator's evidence verifiable against them rather than against the operator.

B7. What this is not

Not a UTM, not a competing service, not a claim that the data proves safety. It is an evidence pipe, started early, offered to the bodies whose job it is to judge.