Airspace Data & Intelligence API

1. Observations arrive
2. They are correlated and fused
3. The state is published with its evidence
4. A stale source widens the band in the payload
5. The earlier payload is requested and compared

Integrations tend to pass coordinates and drop confidence, provenance and unknowns. The receiving system then treats an uncertain reading as a fact, and afterwards no one can tell what was known at the time.

• Governed state objectsThe state from the core platform, with its confidence, freshness, provenance and explicit unknown or stale fields.
• Access and schema rulesWhich consumer may read which part of the state, under which version of the schema.
• Time-based questionsRequests for what was known at an earlier moment, not only for what is known now.

1. Serialises each state with its confidence, freshness and provenance, and marks unknown or stale fields explicitly.
2. Versions the schemas and applies authorization and audit to every consumer. No endpoint is published on this site.
3. Answers questions of the form 'what was known at t', so a downstream system can reproduce a past picture.

• A successful call is not the same as valid information.
• Unknown is never serialised as zero or false.
• The difference between known then and known now can be requested.

The interface is the last link of the chain. It takes the unified state from the core platform, and from fusion where needed, and carries it to other systems with the evidence still attached, so that the receiving side can see how far to rely on each field.

Read the architecture

Data status: Illustrative

Evidence ladder

1. E0 · Concept reached
2. E1 not reached
3. E2 not reached
4. E3 not reached
5. E4 not reached
6. E5 not reached

Project assurance panel

Mission and context

Let other systems use airspace state without stripping away the evidence that tells them how far to rely on it.

Primary contribution

A governed delivery of state objects whose confidence, freshness, provenance and unknowns travel with every field.

Decision value

Lets an integrating team see, in the data itself, which fields are firm and which are soft. The receiving system still decides how to use them.

Evidence status

Evidence level: E0 · Concept Concept and research direction only. No specification, interface or test result is claimed.

Next validation step

Draft the payload and null-semantics rules, then check them against synthetic degradation scenarios in simulation before any interface is built.

Behaviour when degraded

When a source goes stale, the affected fields carry a wider band and a softened claim, and fields that can no longer be supported become null. The payload stays well-formed.

Role in integration

Delivers states and history to approved consumers under versioned schemas, with authorization and audit. It exposes state; it does not accept commands for sensors.

Human review

An integrator reviews how each consumer uses the state, and a person reviews any action that depends on it.

Public-safe limitation

The payload shown is generalized and invented. It is not a real schema, endpoint or example of customer data.

Open unknowns

Which schema versions consumers will need, how long history must be kept and which authorization models sites will require are not yet known.

When a source goes stale, the affected fields carry a wider band and a softened claim, and fields that can no longer be supported become null. The payload stays well-formed.

• A site system that displays airspace state

  Why it matters here

  Its operators need to see which readings are soft.

  What it contributes

  Fields that carry band, freshness and provenance, so the display can show them.

  What it does not replace

  The site's own display design.

• An archive that has to answer what was known then

  Why it matters here

  Reviews after an event depend on the picture as it was, not as it is now.

  What it contributes

  Time-based queries and a difference between two moments.

  What it does not replace

  The organisation's rules for handling and keeping evidence.

Delivers states and history to approved consumers under versioned schemas, with authorization and audit. It exposes state; it does not accept commands for sensors.

Draft the payload and null-semantics rules, then check them against synthetic degradation scenarios in simulation before any interface is built.

• An interface can only pass on what the state contains. If a source was absent, the payload says unknown; it does not fill the gap.
• Consumers may drop evidence fields. The interface can make them available, but it cannot make a receiving system use them.
• No interface is published and no schema is fixed. What is shown here illustrates the rules, not a product.
• Delivery of state is not an assurance of its accuracy, and a well-formed payload says nothing about whether its content is right.

• Airspace Intelligence Core PlatformEvidence level: E1

  The core platform produces the state that the interface delivers.

• Multi-Sensor Fusion EngineEvidence level: E0

  Fusion supplies the per-source contribution records that travel with a fused state.

• City / Regional Low-Altitude Airspace NetworkEvidence level: E0

  A regional network needs governed sharing of state between sites.

• Airport Airspace IntelligenceEvidence level: E0

  Airport systems are consumers that must be able to see which fields are soft.