Building a Defense Fusion Pipeline, Part 3: Multi-INT Fusion, Classification, and Releasability

Parts 1 and 2 built a single-source fusion pipeline. Parts 3 and 4 close the gap to operational defense reality. Real defense fusion takes inputs from multiple intelligence disciplines — SIGINT, IMINT, ELINT, OSINT, HUMINT, GEOINT, MASINT — each with its own semantics, latency, classification, and releasability. Treating them as interchangeable observations is the single most common architectural failure in defense fusion programmes. Part 3 covers the engineering of multi-INT fusion and the classification machinery that defense uniquely requires.

The conceptual foundation is in Complete Guide to Defense Data Fusion; the coalition-data-sharing framing is in Coalition Data Sharing Challenges; the RBAC foundations are in Role-Based Access Control in Defense C2 Systems.

Step 1: Multi-INT Semantics Are Not Interchangeable

Each intelligence discipline carries different semantics. A SIGINT bearing-only contact tells you direction but not distance. An IMINT observation gives you precise position at a single point in time but no kinematics. An OSINT report has uncertain attribution but potentially rich context. A HUMINT report has high latency and source-protection requirements. Collapsing these into a generic "observation" record loses the information fusion needs to produce trustworthy tracks.

The fields that distinguish multi-INT observations:

• SIGINT — line of bearing, frequency, modulation, emitter type, intercept time. Position computed by triangulation if multiple stations report the same emitter; otherwise unknown.
• IMINT — precise position from imagery exploitation, identity from visual or automated classification, collection time. Revisit rates measured in hours.
• ELINT — emitter characterization (radar pulse parameters, signature). Overlaps SIGINT but focuses on electronic order of battle.
• OSINT — extracted from public sources, with attribution uncertainty, source confidence, citation chain. Increasingly important; treated in OSINT Threat Monitoring for Defense.
• HUMINT — human-source intelligence, high latency, classification and source-protection sensitivity. Cannot be propagated to coalition partners without releasability scrubbing.
• GEOINT — combines imagery with terrain analysis, route prediction, pattern-of-life inference.
• MASINT — measurement and signature intelligence; covers acoustic, infrared, nuclear, and other specialized sensing. Often domain-specific (anti-submarine warfare, missile defense).

The canonical track schema accommodates these by carrying source-discipline metadata alongside the standard fields. The fusion engine references the discipline when computing association likelihoods (a SIGINT bearing-only observation cannot directly update a kinematic track without bearing-matching logic; an IMINT point fix should update position but not velocity).

Step 2: The Multi-INT Fusion Architecture

The architectural pattern for multi-INT fusion that works in production:

Per-discipline adapters. Each intelligence discipline has its own family of adapters with discipline-specific logic. The adapter's job is to produce canonical-schema observations tagged with the source discipline, not to interpret across disciplines.

Discipline-aware correlation. The fusion engine's correlation logic references the source-discipline metadata. Rule-based gating includes discipline-compatibility rules ("a HUMINT report about a vessel can update an IMINT-confirmed vessel track only if identity matches at high confidence"). Probabilistic association uses discipline-specific priors.

Fusion enrichment, not replacement. When multi-INT observations agree, they reinforce confidence. When they disagree, the fusion engine surfaces the disagreement to the operator rather than picking one. A track with two confident-but-conflicting identity reports is not "wrong" — it is genuinely ambiguous and the operator needs to know.

Cross-discipline analytics as separate services. Higher-order analytics that span disciplines — pattern-of-life detection (Pattern-of-Life Analysis), behavioural anomaly detection, network analysis — run as separate services that consume the fused track stream. They produce enriched annotations on existing tracks, not new tracks competing with the fusion engine.

Step 3: Classification Labelling per STANAG 4774/4778

Every data object the platform produces carries a confidentiality label. STANAG 4774 defines the labelling format; STANAG 4778 defines the cryptographic binding that prevents detaching labels from the data they label. Together they are the foundation of all coalition data sharing in NATO contexts.

The engineering integration:

Source classification is carried by every adapter. Each adapter knows the classification of its source (configured in the source catalogue from Part 1) and tags every observation with it. The adapter is the source of truth for the classification of its observations.

Labels are structured, not strings. A classification label is not "SECRET"; it is a structured object with classification level, compartments, releasability tags, and binding signature. The label library implements STANAG 4774 serialization and STANAG 4778 binding; every observation passes through it.

Labels are propagated, not regenerated. When the fusion engine updates a track, the track's effective classification is computed from the source set, not assigned independently. A track derived from a SECRET radar return and an UNCLASSIFIED AIS message is SECRET. Propagation discipline is mechanical; getting it wrong is an accreditation failure.

Binding survives serialization. When tracks are serialized to disk, to the message bus, or across the wire, the STANAG 4778 binding remains attached. Stripping the binding for "convenience" is the kind of shortcut accreditation reviewers specifically look for.

Step 4: Classification Propagation Through Fusion

The fusion engine creates derived data. A track is a derivation from multiple source observations; its classification must be computed from theirs. The propagation rules:

Classification level is the maximum across the source set. A track derived from SECRET and UNCLASSIFIED sources is SECRET. The high-water-mark rule is unforgiving but well-understood.

Compartments are the union across the source set. A track derived from a HIGH-VALUE-TARGET-compartment source and a HUMAN-INTELLIGENCE-compartment source carries both compartments. Access requires clearance in both.

Releasability is the intersection across the source set. A track derived from FVEY-only and NATO-only sources is releasable only to the intersection (FVEY-and-NATO, which in practice means the four FVEY nations that are also NATO members). The intersection rule is the most operationally consequential and the one most often gotten wrong by ad-hoc implementations.

Per-attribute classification where it matters. A track's position may be releasable broadly while its identity is more restricted. The schema supports per-attribute classification; the policy engine evaluates per-attribute access at query time.

Step 5: The Releasability Policy Engine

Classification labels on data are necessary but not sufficient. Access decisions require a policy engine that knows the user's clearance, citizenship, role, and the requested data's classification, compartments, and releasability. Every query against the track store passes through this engine.

The engineering pattern:

Policy as code. Releasability rules expressed in a versioned policy language — Open Policy Agent's Rego is the defensible default. Policy changes go through code review, not configuration changes. The history of policy decisions is auditable from version control.

Decision evaluation at the query boundary. When a consumer queries the track store, the policy engine evaluates which tracks are visible and which attributes are visible per-track. The result is a filtered view, not the full data with a UI mask. UI-only filtering is a Common Criteria violation and an accreditation deal-breaker.

Per-decision audit log. Every access decision — what user, what data, what classification, what result — is logged immutably. The audit log is the evidence base for accreditation review and operational forensic analysis.

Performance budgets. The policy engine sits on the COP critical path; its evaluation latency must be sub-millisecond per decision. Caching strategies, pre-compiled policy bundles, and per-user policy fingerprints all matter. A naive policy engine is the most common cause of COP slowness in classified deployments.

The detailed treatment of the policy engine pattern, coalition data sharing implications, and the operational anti-patterns to avoid is in Coalition Data Sharing Challenges.

Step 6: Cross-Enclave Data Flows

Defense networks are not single enclaves. A platform operating across NATO RESTRICTED, NATO SECRET, and national-classified networks must move appropriate data between them while preventing inappropriate data flows. The architecture pattern:

Per-enclave fusion instances. Each classified enclave runs its own fusion instance with its own source set, track store, and policy engine. The instances are physically separated; the platform does not assume they share state.

Cross-domain bridges. Where data legitimately moves between enclaves — for instance, an unclassified AIS feed flowing up to a SECRET enclave, or releasability-scrubbed product flowing down to a coalition enclave — the movement goes through an accredited cross-domain bridge, not a direct connection. The bridge enforces the classification rules at the boundary.

One-way diodes where physics enforces direction. For high-side-to-low-side data movement (which is rare and operationally sensitive), one-way data diodes enforce the direction at the network layer. The fusion platform integrates with diode infrastructure rather than implementing its own.

Manual release where automation fails. Some classification decisions cannot be safely automated. Per-product release decisions for HUMINT or compartmented data may require human approval. The platform must accommodate the workflow — surface the candidate release, capture the human decision, propagate the approved release.

Step 7: Operational Considerations

Multi-INT fusion in operations surfaces challenges not visible in development. The disciplines that distinguish operational platforms from demo platforms:

Source attribution survives propagation. When a track is queried, the response includes the source set that contributed to it. Operators need to know whether a position came from radar (high kinematic confidence, identity uncertain) or HUMINT (low spatial precision, identity context-rich). Source attribution makes this transparent.

Disagreement is preserved, not collapsed. When two source disciplines disagree about a track's identity, the fusion engine preserves both alternatives with confidences. The operator decides; the platform surfaces.

Compartment fan-out is bounded. A track with many compartments has many distinct potential audiences. The system must compute releasability efficiently even when the compartment set is large.

Audit covers every release decision. Every cross-domain transfer, every per-query filter result, every compartment escalation is logged. The audit log supports operational forensic review, accreditation evidence, and after-action analysis. The detailed pattern is in Event Sourcing for Defense Audit Trails.

Cyber Observables as Multi-INT

Increasingly, cyber observables flow into the same fusion pipeline as physical-domain observations. A confirmed network intrusion, a leaked credential set, an OSINT-derived attribution lead — each can become an observation in the multi-INT fusion stream. The architectural fit is real but requires care: cyber data has different latency, confidence, and classification semantics than physical-domain data. The pattern is treated in CTI Platforms for Defense and the broader cyber-as-fusion-discipline view in The Complete Guide to Defense Cybersecurity.

The engineering decision: build cyber-specific adapters that produce canonical-schema observations tagged with discipline "cyber" while preserving cyber-specific metadata (indicators of compromise, threat-actor attribution, kill-chain phase). The fusion engine treats cyber observations like other multi-INT inputs; the cyber-specific tooling (CTI platforms, SIEM/SOAR) consumes the same track stream for its own purposes.

What's Next

Part 3 has covered the multi-INT and classification machinery. The platform now correlates observations across intelligence disciplines while preserving their semantic differences, propagates classification through fusion correctly, enforces releasability via a policy engine, and operates across classified enclave boundaries.

Part 4 closes the series with operationalization: drift monitoring on the fusion algorithms, the audit pipeline that supports accreditation, the production deployment patterns (cloud-to-air-gapped), and the long-tail maintenance discipline that keeps the platform operational across a 20-year lifecycle.