Multi-domain fusion.

Why fusion is an entity-resolution problem, and why the integration approach has failed.

The dominant pattern in defence software for two decades has been point-to-point integration. The radar talks to the C2 system. The SIGINT collector talks to the intelligence database. The drone video feed talks to the operator console. Each integration is bespoke, brittle, and shaped by the schemas of its endpoints, not by the questions the operator wants answered.

The result is a graph of pipes that resists the only operation ever asked of it: cross-modal reasoning. When an operator wants to know whether a flagged RF signature in the Northwest Passage correlates to a satellite-imaged surface contact correlated to a crew-pairing disruption on a CP-140 sortie, the answer requires four systems and a watch officer with intuition. The systems are not at fault. The integration pattern is.

An ontology inverts the pattern. Every modality contributes to a single shared graph through ingest. The fusion layer reads against the ontology, not against the source systems. Every cross-modal question becomes a traversal in a single graph. Persistent object tracking, the property defence operations need most, is the natural output of entity resolution against a stable schema.

The fusion stack, six layers.

We define a six-layer reference architecture. Each layer is implementable independently and has a well-defined interface to its neighbours. The architecture is the substrate; the modalities plug in as connectors.

1. 01
   Ingest

   Eight source-type connectors: text/CSV, JSON, REST, database, stream (Kafka, Kinesis, MQTT, AMQP), object storage (S3, Azure Blob, GCS), webhook, and synthetic. Each booting against a sandbox tenant by default. Heterogeneous modalities including imagery, video, audio, RF, and telemetry feed through these connectors as ContactReports.
2. 02
   Alignment

   Spatiotemporal alignment across modalities. ContactReports from different sensors join when they share a window in space and time, weighted by sensor reliability priors. The output is a Detection: a candidate fused observation with a confidence score and an uncertainty bound (Mahalanobis distance, sensor noise covariance).
3. 03
   Resolution

   Entity resolution against the ontology. Detections resolve to existing Tracks where they fit; new Tracks materialize where they do not. Resolution is dynamic: the graph updates as new evidence arrives. Persistent multi-modal object tracking is the property the resolution layer guarantees.
4. 04
   Fusion

   AI-driven scoring across resolved entities. Three scorer classes: spatiotemporal correlators (radar + EO + RF), anomaly detectors (RF without correlated visual return), and platform classifiers (Track to PlatformContact via radio fingerprint, kinematics, signature). Each scorer emits confidence and uncertainty.
5. 05
   Decision

   Severity-banded action gates. Auto-tier executes; review-tier surfaces to operator with a defended recommendation; critical-tier holds for explicit authorization. Every decision carries reasoning visible to the operator and a reversibility window during which it can be undone.
6. 06
   Audit

   Hash-chained lineage. Every entity, score, decision, and action references its predecessor in an FNV-1a chain anchored to a genesis block per tenant. The chain is tamper-evident; tampering breaks the chain visibly. Provenance for every output is one query away.

The ISR extension, six new object types on the eighteen-type core.

Our 2026 ontology paper specifies the eighteen-type core schema across six domains. For ISR fusion we add a six-type ISR extension with explicit cardinality and verb-named relationships:

The relationships are: Sensor emits ContactReport (1:N). ContactReport resolves_to Detection (N:1). Detection correlates_to Track (N:1) — this is the fusion join. Track associates PlatformContact (1:1). Track enters and exits EngagementZone (N:N). Track cites Mission (N:N) — joining the ISR extension to the existing Defence extension (Mission, Asset, Sustainment Order, Authorization).

Six types. Eight relationships. The grammar is identical to every other industry extension MAIA ships: declare types, declare bindings to the core, declare which governance lenses apply. The ISR extension binds to Government of Canada research-security framework cards (Deep Learning for Health Decision Systems, Cognitive Computing) and to Protected B / Secret classification labels.

Spatiotemporal alignment + uncertainty propagation.

The alignment layer is where modality-specific data becomes comparable. ContactReports arrive with their sensor’s native uncertainty (radar: range and azimuth covariance; EO: geolocation residual; RF: bearing fix and frequency). The alignment layer projects each into a shared coordinate frame with its uncertainty preserved.

The correlator joins two ContactReports A and B into a candidate Detection when their Mahalanobis distance d(A, B) is below a time-bandwidth gate that adapts to the sensor reliability priors and the operational tempo. Sensor reliability priors are learned online from the audit chain — a sensor whose Detections frequently fail to associate to a confirmed Track has its prior down-weighted. A sensor whose Detections consistently associate has its prior lifted.

The output is a Detection with an explicit confidence distribution (Beta or truncated Gaussian, depending on the modality combination) and an uncertainty bound the operator can read. The downstream fusion layer respects the uncertainty: high-confidence Detections update Track state with low Kalman gain (preserve the prior); low confidence Detections update with higher gain only if they tighten the existing uncertainty.

The uncertainty propagates end-to-end. A Track whose state was built from low-confidence Detections is itself low confidence. An action proposed against a low-confidence Track is gated to the operator review tier, never auto-executed. The operator sees not just the Track but the chain of evidence and the sensor priors that produced it.

Persistent object tracking via dynamic knowledge graph.

Persistent object tracking is the operational property defence customers need most. A track that exists today must still exist tomorrow when a new sensor observes the same platform from a different aspect, even if the new observation arrives through a different modality, classification level, or coalition partner.

The ontology backbone makes this natural. Every Track has a persistent identity in the graph. Detections resolve to that identity through a learned similarity function (kinematic consistency, RF fingerprint, signature pattern, semantic description from text intelligence). The same Track can be simultaneously observed by satellite imagery, RF SIGINT, ground radar, and human reporting; each observation tightens or challenges the Track’s state.

When evidence diverges — for example, a SIGINT pulse continues after EO confirms the platform departed — the resolution layer opens an Anomaly. Anomalies are first-class objects in the ontology, and they trigger investigations against the same audit chain. The operator does not lose the divergence; the platform surfaces it.

Multi-modal entity resolution at scale, with full provenance, is the hardest part of multi-domain fusion. It is also the part most naturally solved by the ontology architecture.

Policy-aware fusion + cross-classification integration.

Defence operations span classification levels. Unclassified satellite imagery, Protected B operational reporting, Secret signals intelligence, Top Secret special-access compartments — each modality can carry data at a different classification, and fusion must respect the lattice.

We model classification as a runtime property on every entity. A scorer running at level N can only read entities at level ≤ N. A fused output (Detection or Track) is labeled at the maximum of its inputs. Outputs are visible only to operators cleared at or above the output’s level. Cross-classification fusion is therefore impossible to misuse: the platform refuses to surface an output to a viewer below its classification.

The lens binding model extends to allied interoperability. A Track shared with a Five Eyes partner carries a release marking (REL TO USA, GBR, AUS, CAN, NZL) as a property the runtime enforces at every read. The audit chain records which partner received which Track at which time, which is the property interoperability auditors most often ask for and rarely receive.

None of this requires a separate “security layer” bolted on. It is the same code path the runtime uses for any other constraint. Classification is a runtime property, not a documentation property. If the system does not enforce it on every read, it is not enforced.

Real-time pipelines + explainable outputs.

Real-time fusion is a pipeline problem first and a model problem second. The pipeline must ingest at modality-native rate (radar: tens of Hz; SIGINT: continuous; EO video: 24-30 fps; text reports: minutes), preserve order where it matters, drop gracefully under load, and surface latency budgets to the operator.

We deploy on Vercel Fluid Compute, which reuses function instances across concurrent requests and supports graceful shutdown. Stream connectors run as long-lived Functions consuming Kafka or MQTT topics. Database state is Postgres-backed; entity store is a single source of truth queried via the ontology. The runtime produces a heartbeat of fusion events visible in the operator UI: new ContactReports arrive, Detections fuse, Tracks update, Anomalies open, and decisions queue. The platform never goes quiet on the operator.

Explainability is mandatory. Every action proposal carries its reasoning chain: which Tracks it touched, which scorers fired, which counterfactual baseline was applied. The reasoning is visible inline, not in a separate explainability dashboard. Trust scales with legibility, not with model complexity.

We measure operator trust through a single question we ask in every pilot: “Did the platform earn the right to act autonomously?” The platform earns the right by being consistently legible at the action layer, in milliseconds, one decision at a time.

SWaP-aware edge deployment.

Cloud and command-post deployments are not enough. Tactical edge — wearable systems for forward operators, vehicle-mounted compute, forward command posts under degraded connectivity — has hard Size, Weight, and Power constraints. The fusion stack must run within a 5–20 MB binary, on 256 MB to 2 GB RAM, drawing 1–10 W, often offline.

Our edge variant compiles a subset of the runtime (the alignment and resolution layers, plus a single fusion scorer relevant to the deployment) to a Rust binary linked against an embedded SQLite. Heavier scorers and the audit aggregator run in the command post or cloud, with the edge syncing opportunistically over low-bandwidth secure channels. Deterministic mulberry32 RNG seeds the edge state so the same input produces the same fused output, regardless of network state.

The phased deployment: Phase 1, cloud + tactical command post, production-ready today. Phase 2, compiled edge runtime for wearable / vehicle / forward command post, on a six-month milestone with a hardware partner. Phase 3, full mesh-tolerant edge synchronization, twelve-month commitment.