Interfaces
One interface for a mixed fleet
What it takes for a new airframe to be an integration rather than a rewrite — written for the engineer who will have to do the work, and honest about how much of it exists today.
Read this first. The contracts below are specified and reviewed. One adapter is implemented. A second does not exist yet, and until it does, "vendor-neutral" is a design property rather than a demonstrated one. We would rather you knew that from the top of the page than discovered it in a procurement conversation.
Why an abstraction layer at all
Every manufacturer has its own cloud API, its own route file format, its own telemetry vocabulary and its own idea of what a mission is. Software written against one of them is not portable, and an agency that adopts it has quietly chosen a fleet for the next decade. Several North American jurisdictions also restrict specific manufacturers, so a subsystem welded to one vendor can become unprocurable through no technical fault of its own.
The alternative is to name the small number of things every aerial platform genuinely has in common, express those as ports, and put each manufacturer behind an adapter. There are four such things.
1 · The drone adapter
Fleet discovery, capability declaration, route submission, mission lifecycle observation and telemetry normalization. Every method on this port either reads state or makes a proposal.
There is no method that commands an aircraft. That is not a gap to be filled in a later version — it is the boundary, and a build gate rejects any control verb that appears on this path.
2 · The sensor adapter
Normalizes whatever a payload produced into one observation record. The required fields are the ones that decide whether a product may be used at all:
| Field group | Why it is mandatory |
|---|---|
| Acquisition time and time source | Fire moves. An observation whose clock is unattributed cannot be ordered against another one. |
| Position and attitude, with accuracy | Where the sensor was pointing, and how well it knew. Accuracy without a stated bound is not accuracy. |
| Horizontal and vertical CRS and datum | Two coordinate systems that disagree by a hundred metres will agree perfectly about the number. |
| Footprint | What was covered, which is what makes an absence of detection mean anything. |
| Spectral and thermal bands, exposure, radiometry | What was actually measured, rather than what was displayed. |
| Calibration references | Mandatory for thermal. An uncalibrated radiometric product is quarantined, never scored. |
| Processing level and raw asset hashes | What was done to the bytes, and proof of which bytes they were. |
| Missing and corrupt frames | A gap that is recorded is data; a gap that is silently dropped is a false impression of coverage. |
| Privacy classification and lineage | Aerial imagery captures more than fire. What may be retained, shown and shared travels with the product. |
3 · Capability profiles
A versioned, per-model declaration of what an airframe and payload combination can actually do — endurance, payload options, supported route semantics, telemetry available, dock behaviour. A mission is only composed against a declared profile, so nothing can plan a flight an aircraft cannot perform.
Two profiles exist today, covering the dock and aircraft combinations we have modelled. Adding a profile is a data change; adding a manufacturer is an adapter.
4 · Evidence events
Everything the subsystem publishes is an event about something that happened: an asset was received, an asset was quarantined, a candidate was created, a product was accepted or superseded. Each carries its authority, classification, jurisdiction, trace identifier, issue and effective times, schema version and idempotency key.
No event contains a control command. The event stream can be consumed by anything without any consumer gaining the ability to make an aircraft do something.
What porting a new fleet actually involves
- Implement the drone adapter against the manufacturer's API — discovery, capability read, route submission, mission observation.
- Implement the sensor adapter for the payloads, including the calibration state the thermal path requires.
- Declare capability profiles for each airframe and payload combination you intend to support.
- Pass the conformance exercises: a fixed set of protocol and product scenarios both adapters must satisfy identically.
No domain code changes. That is the test of whether the abstraction is real, and it is the test the second adapter will either pass or fail in public.
If you build or operate aircraft we have not modelled, this is the most useful conversation available to us right now. The second adapter is what turns a design claim into a demonstrated one. Get in touch →