SigNet SMS draft v0

SigNet SMS: a shared safety-assurance and reporting service

Status: DRAFT v0.2, 2026-08-19. Supersedes v0.1 (which was framed as a single operator's SMS). This pack now describes a service and a standard: the safety assurance layer of a CAP 722 / CAP 795 (ICAO Annex 19) safety management system, built and maintained by a non-profit for UAS operators, manufacturers, general aviation and the regulator, with one common reporting schema that every member reports into.

The idea in four lines

  1. An SMS has four pillars. Three of them (policy, promotion, and most of risk management) are organisational and stay with each operator. The fourth, safety assurance, is where the money and the hours go, and it is mostly data.
  2. SigNet already produces that data as a by-product of flying: signed permits, configuration hashes, refusals to arm, the outcome ladder, part life, a hash-chained ledger. The work of an assurance layer is therefore a delivery problem, not an authoring problem.
  3. A neutral non-profit runs that layer as a service: a prescribed hazard library, a standard SPI set, a typed reporting schema, a broker that anonymises and works the data, and independent custody of evidence. Members report into it. The regulator reads worked signal from it. Manufacturers and GA plug into the same schema.
  4. We are member one. Our own operation is the first tenant of the service, not the subject of this pack. No platform is named here.

Who it is for

Member class What they get What they give
UAS operators (specific category, BVLOS) The assurance layer of their SMS, ready made: hazard library seeded to CAA HE01-04, SPIs, reporting, evidence custody; a proportionate route to SORA evidence Records on the schema; membership fee
Manufacturers and integrators A reference schema and evidence levels to build to; a conformance route when the certification scheme exists Conformance fees; schema input
General aviation (clubs, schools, pilots, aerodromes) Occurrence and exposure reporting in the same schema; shared airspace picture; a light SMS template aligned to CAP 795 Records; membership; a seat on the safety committee
ANSP (NATS) Interface data for corridor and airspace safety cases; a custody anchor role Integration point; observer seat
Regulator (CAA) Worked, anonymised signal in its own HE/barrier vocabulary; first-submitter corpus before its formal data request Observer seat; says whether the fields are right

Contents

File Role in the service
01-safety-policy.md Safety and data policy of the service; plus the minimum each member operator must hold (the organisational pillars we do not supply)
02-hazard-log.md The hazard library: seeded from CAA HE01-HE04 and our FMEA, with every barrier mapped to a SigNet function and an ADR-0007 evidence level. Members clone it per platform class
03-safety-performance-indicators.md The standard SPI set every member reports, defined over ledger events
04-management-of-change.md Change control for the service, the schema, and member configurations
05-reporting-standard-proposal.md Reporting route (MOR and internal) and the proposal to the CAA and NATS: we start feeding data now as the seed of a minimum reporting standard
06-service-and-governance.md The non-profit: purpose, form, services, membership, governance, data governance, funding, what it does not do
schema/reporting-v0.json JSON Schema for the three record tiers; schema/examples/, schema/validate.py

Coverage of the four pillars, by who supplies what

Pillar Element Service supplies Member operator supplies
1 Policy Policy, Accountable Manager, responsibilities, ERP, documentation Template (01 section 8), service's own policy Their own signed policy, named AM, ERP
2 Risk Hazard identification, risk assessment Hazard library with barriers and evidence levels (02) Their cloned register, SORA at their SAIL
3 Assurance Performance monitoring, reporting, MoC, audit SPI set (03), schema (05), broker, custody, MoC for schema (04), aggregate reports Their SPI values, their occurrence records, MoC for their configuration
4 Promotion Training, communication Aggregates, lessons bulletins, schema training Their own competence and comms

What is true about the data today

All figures quoted in this pack come from the v1 reference implementation flying a simulated fleet on the London corridor model (../evidence/v1-final-report.md). No aircraft has flown under SigNet. The arming gate is proven on the bench. Integrity levels (L1 to L6) follow ../adr/0007-evidence-integrity.md and are stated low. The non-profit is not yet incorporated (see 06 and ~/claudecode/programme-record/DECISIONS.md 2.1).

The standard SPI set

03 Standard safety performance indicators (SPIs)

Status: DRAFT v0.2, 2026-08-19. The standard SPI set every member reports and the service computes (S3). Defined over SigNet ledger events; a member without SigNet maps its own log to the same definitions. Every SPI is computed from ledger events, never from console counters (the console's counters are an in-memory accumulator reset on restart; the ledger is the truth, ../evidence/v1-final-report.md). Targets are proposed, not validated: the only data so far is the v1 simulated fleet. They will be reset after the first 100 real flights.

1. Denominators

ID Indicator Definition Source
D1 Flights count of flights with flights.status in (complete, incident, hold_timeout, refuge) Ledger.stats
D2 Flight hours sum of (LANDED.ts - first LEG_CLEARED.ts) per flight; or CAMO hours accrued on fc module LEG_CLEARED, LANDED, modules.hours
D3 Permits issued count PERMIT_ISSUED ledger
D4 Requests count MISSION_REQUEST ledger
D5 Fleet size and configuration classes distinct airframes with CONFIG_APPROVED in period; distinct class in MISSION_REQUEST ledger

2. Indicators

Integrity = ADR-0007 layer of the underlying evidence, stated low.

ID Indicator Formula Ledger events Integrity Objective Proposed target Alert
SPI-01 Evidence chain integrity chain verifies end to end; 0 breaks all (hash re-verification) L2 O4 100% of flights with verifiable bundle any break
SPI-02 Permit denial rate by reason class MISSION_DENIED / D4, split by reason prefix (config_hash_not_approved, life_limit, insufficient_energy_for_route, bad_*, directive_constraint, non_operational_class, route_hash_mismatch) MISSION_DENIED, MISSION_REQUEST L2 O2, O3, O5 trend only (a healthy gate denies) any bad_request_signature or bad_airframe_credential in live ops
SPI-03 Configuration mismatch at request count MISSION_DENIED reason config_hash_not_approved / D4 as above L4 (hash measured on FC) O2 0 in live ops after first approval > 0
SPI-04 Flights with unpinned config flights where airframe has no CONFIG_APPROVED newer than last CONFIG_PIN_REMOVED CONFIG_APPROVED, CONFIG_PIN_REMOVED, PERMIT_ISSUED L2 O2 0 > 0
SPI-05 Refusals to arm (authority-initiated), by reason class and airborne flag count AIRFRAME_REFUSED, split airborne, reason AIRFRAME_REFUSED, AIRFRAME_REFUSAL_CLEARED, DIVERT_ORDERED L3 (signed) O5 trend; 100% reviewed within 7 days any airborne refusal
SPI-06 Divert rate (BATT_DIVERT + DIVERT_ORDERED) / D1 as named L2 O1 < 0.5% (v1 sim: 0.33%) > 1% rolling 100 flights
SPI-07 Critical forced descent rate BATT_CRITICAL / D1 BATT_CRITICAL L2 O1 0 in live ops (v1 sim: 0.011%) any
SPI-08 Emergency landing rate (BATT_EMERGENCY_LAND + REFUGE_LANDING + HOLD_TIMEOUT_LAND) / D1 as named L2 O1 < 0.3% (v1 sim: 0.26%) > 0.5%
SPI-09 Life-expired part flown flights where any module hours >= limit_h at PERMIT_ISSUED modules, PERMIT_ISSUED, OVERHAUL L2 O3 0 any
SPI-10 Part-life margin min over fleet of (limit_h - hours)/limit_h; count of SCHEDULED_MAINTENANCE modules, SCHEDULED_MAINTENANCE L2 O3 no module below 10% without scheduled maintenance < 5%
SPI-11 Energy margin at permit distribution of energy_margin_wh / usable_wh from PERMIT_ISSUED; landing SoC from LANDED-adjacent soc_pct PERMIT_ISSUED, BATT_* L2; SoC L1 O1 p5 landing SoC > 20% p5 < 15%
SPI-12 Occurrence classification latency time from triggering event to HE class assigned in the occurrence record occurrence records (05) n/a (process) O6 100% within 24 h any > 72 h
SPI-13 Hold time in air sum of time between REFUGE and REFUGE_RESUME/REFUGE_LANDING per flight REFUGE, REFUGE_RESUME, REFUGE_LANDING L2 HE02/HE03 p95 < hold budget HOLD_TIMEOUT_LAND > 0
SPI-14 Pad conflicts WAVE_OFF + PAD_BLOCKED_FOD / landings as named L2 HE02 trend > 2%
SPI-15 Directive compliance DIRECTIVE_ENFORCED / DIRECTIVE_ISSUED affecting active flights; 0 flights continuing in a restricted corridor DIRECTIVE_*, PERMIT_ISSUED L3 (agency-signed) HE03/HE04 100% any non-compliance
SPI-16 Intrusions INTRUSION_DETECTED per 100 flights; response class INTRUSION_* L2; detection L1 HE03 trend any unresolved > 10 min
SPI-17 Human consent gate events per flight: consent given, by whom, against which config hash not yet ledgered (ADR-0005 companion) L1 today O2, X.3 100% of flights n/a until built

3. Review

4. Integrity roadmap that the SPIs depend on

Need Why Plan
L5 independent custody of authority events SPI-01 is meaningless to an outsider while the operator holds the only copy Periodic anchor of chain head to regulator/insurer; ADR-0007
Consent ledger event SPI-17 cannot be computed ADR-0005 companion
Firmware identity L4+ SPI-03 measures params, not firmware Astrial CAAM; module trust WP-1/2a
Second-sensor SoC SPI-11 rests on self-report Module trust power module

5. Implementation note

A Signet.SMS reporting function should compute D1-D5 and SPI-01 to SPI-16 directly from the SQLite ledger and emit the periodic summary record in schema/reporting-v0.json. Until it exists, the SM computes them by query. Do not source any SPI from batt_summary.