Most computer-vision papers report wall-clock model latency. We report something different: frame in to catalog out. That measurement includes ingest, inference, tracking, disposition assignment, and the publish hop into a partner Lattice instance. Median across our validation corpus: under two seconds.
This note opens the pipeline.
Stage 1 — Multi-sensor fusion
A bird at runway approach can be observed by camera (visible + IR), solid-state radar (360° sweep), or acoustic array (4-channel). No single sensor is enough — visible-band cameras lose signal at dusk; radar struggles with small avian cross-sections; acoustic is ambient-noise limited at busy airfields.
Stage 1 normalises all three streams into a sensor-agnostic frame representation. The downstream pipeline never sees "this is a radar return"; it sees a frame with confidence-scored detections.
Stage 2 — Re-ID tracking across frames
A single detection is not an entity. An entity is what persists. Our Re-ID head consumes the frame stream and assigns persistent identifiers across frames — the bird that crossed the inner marker is the same bird crossing the outer marker thirty seconds later, even if the camera changed.
The Re-ID head is small. Jetson Orin Nano hardware is the deployment target; we cannot afford a 200 ms re-identification cost per frame. The practical budget: ~4 ms per frame for detection + Re-ID combined.
Stage 3 — Disposition assignment
This is the doctrine layer. Default disposition is NEUTRAL.
Escalation paths are explicit and bound to allied references — see the
Mudflat note for why this defaulting choice is doctrinal. The
disposition field is not an LLM output; it is a deterministic function
of (species classification × airport doctrine ruleset).
If the species classification is uncertain, the entity ships with
_uamkt_extensions:species_confidence so the operator can see the
ambiguity rather than have it laundered.
Stage 4 — Catalog publish
The publish call is the only network hop in the loop. Payload size is ~1.2 KB per entity; the Lattice Entity API accepts PUT in under 300 ms median to our partner sandbox. We do not maintain a queue — back-pressure applies upstream, in stages 1 and 2.
The 19/19 validation run hits stage 4 nineteen times per scenario and expects 200 OK every time. Anything else is a bug, not a "soft fail."
Why the pipeline is small on purpose
Every component we add is one more thing the partner has to audit. Sensor fusion, Re-ID, disposition, publish — four stages, each necessary, each replaceable. We resist tempting additions (anomaly detection, generative scene reasoning, reinforcement-learning controllers) because they would obscure the doctrinal commitments the disposition stage already encodes.
A small pipeline is a checkable pipeline. That is the design parameter.
—
Inquiries: ceo@uamkt.com
Primary reference: ICAO Doc 9332 — Manual on the ICAO Bird Strike Information System (4th ed.).