Analysis: Defence Open Architecture
Grounding a PYRAMID avionics bridge in IES and HQDM
PYRAMID is the UK Ministry of Defence's open reference architecture for avionics and mission systems. It standardises how software components plug together and deliberately leaves what the data means across them to per-deployment bridges. This is a worked, open example that fills that gap with a shared 4D ontology, using standards the UK government already owns.
Focus
Semantic interoperability
above the architectural layer
Components bridged
3
Geography, Tactical Objects, Data Fusion
Verification
SHACL
bridge conforms; false friend rejected
The Challenge
PYRAMID (now UK Defence Standard 00-134, released under the Open Government Licence) decomposes avionics and mission-system software into well-defined components. By design it has no single shared data model. Its own Technical Standard states that there is "no shared interface definition between PRA components", so "a deployment will use bridges to close the semantic gap, aligning the interfaces between components so that they are able to share information". The same standard is explicit that "the PRA does not include a shared data model", while recognising that a data architecture is needed.
So PYRAMID standardises how components connect and leaves what the data means to bridges that are, today, hand-built per deployment. That is exactly the slot a shared, published 4D ontology fills. On the UK side those ontologies exist: the Information Exchange Standard (IES) for the operational picture and HQDM for the built and physical environment, both 4D and both descended from the same BORO tradition, which is why our IES to HQDM crosswalk can join them.
What we built
A reference semantics for one PYRAMID bridge, between the Geography component and the Tactical Objects component, extended up the sensing chain to Data Fusion. Every entity is taken verbatim from the public Technical Standard and grounded in an IES or HQDM term.
| Deliverable | What it is |
|---|---|
| Entity grounding (SSSOM) | Each component entity mapped to an IES or HQDM term, with predicate, confidence and justification. |
| Bridge (RDF) | A machine-readable bridge that resolves the same object across three components to one referent. |
| Executable proof | A runnable check showing the components cannot be joined without the grounding, and do with it. |
| Enforcement shapes (SHACL) | A co-reference is valid only when both objects denote the same referent, which forbids the false-friend unification. |
| Negative fixture | The naive mistake, committed on purpose, so the shape provably rejects it. |
The finding: one building, two types, and a false friend
The standard's own text supplies the case. A Tactical_Object may be "a building that is the target of an attack"; the Geography component models that same building as a Geographical_Feature. One real object, two disjoint component-local types, and nothing in the architecture tells a deployment they are the same thing. Grounding both in ies:Entity, with the spatial side carried to hqdm:physical_object through the crosswalk, lets the two views resolve to one referent that a machine can check.
The trap is the mirror image: the word Capability appears as a distinct entity in Geography, in Tactical Objects and in Data Fusion, meaning something different in each. A bridge that unifies them on the shared label corrupts all three. The grounding records them separately, and a SHACL shape refuses any co-reference whose two sides do not denote the same referent, so the mistake fails validation rather than shipping silently. This is the same discipline as the crosswalk's headline ies:Event false friend, applied one layer up.
Why it matters now
The demand is loud and the solution is unnamed. The MOD's Data Strategy for Defence records that, in a review of 100 systems, just a quarter of MOD systems have automatically discoverable data, and calls for a shift from platform-centric to data-centric. Yet the enabling programmes, the Single Information Environment, SAPIENT, FACE, the combat cloud, reach for transport, access and exchange mechanisms, and none names a shared meaning layer, even as the Digital Targeting Web needs sensor-to-shooter data to compose and GCAP needs it across a UK, Italy and Japan coalition. The US Department of Defense has, by contrast, adopted a foundational ontology baseline (Basic Formal Ontology and the Common Core Ontologies, mandated through the DoD-IC Joint Enterprise Standards Committee in November 2024). The UK already owns the two ontologies that could close the gap; they have simply never been applied to avionics.
We could find no published work that grounds PYRAMID, or the related FACE Shared Data Model, in any upper ontology. This example occupies that gap with open, government-owned standards.
Outcome
An open, machine-readable, validated bridge released under CC-BY-4.0 and built on Tesseract's open-ontologies engine and the IES to HQDM crosswalk. It is not affiliated with or endorsed by the MOD PYRAMID programme; it is an independent demonstration built entirely on the public standard and open ontologies.
- ›Three components resolve to one referent; the grounding is not a cherry-picked pair.
- ›The bridge conforms to the crosswalk's own SHACL shapes; the false-friend fixture is rejected.
- ›Everything is reproducible from the Open Government Licence Technical Standard, no gated model required.
"Open architecture is necessary but not sufficient. PYRAMID guarantees the components can be connected; a shared ontology is what lets them mean the same thing once they are. The UK already owns that ontology layer. This shows it doing the job, on the public standard, with the traps named honestly."
Fabio Rovai, Tesseract Academy
View the open bridge
The entity grounding, the machine-readable bridge, the executable proof, and the enforcement shapes.
