Cross-Domain Solution Message Mapping
Status & scope
- Stage: RESEARCH — Awaiting partner input on approved message formats
- Author: Auto-generated from design discussion, 2026-03-13
1. Purpose
Cross-domain solutions (CDS/CDG) only pass message formats that have been pre-approved through an accreditation process. Proposing a new XSD schema takes months to years. The fast path is to map fusion phase messages to formats the guard already approves.
This spec documents: - Candidate message formats identified so far - How fusion phases could map to each format - What we need to find out from partners - Space domain application (SSA/SDA) as a driving use case
1b. Known CDS Products & Standards
Guard Products (Public Knowledge)
| Product | Vendor | Market | Type | Inspection Mode |
|---|---|---|---|---|
| XTS Guard 7 | BAE Systems | US DoD | Bi-directional | Schema validation, RTB-compliant, up to 20 domains |
| XD Guardian XML | Owl Cyber Defense | US DoD | Dual-guard, quad-diode | XML structured data filters — closest to our CDG approach |
| Owl Talon | Owl Cyber Defense | US DoD | Data diode (one-way) | No content inspection — one-way transfer only |
| TACDS | General Dynamics | US DoD | Tactical CDS | NSA-approved, field-deployable |
| Forcepoint Trusted Gateway | Forcepoint | US DoD | Guard + diode | Content filtering, protocol break |
| Nexor Guardian | Nexor | UK MOD | Bi-directional | Deep content inspection, XML validation, CDR |
| Nexor GuarDiode | Nexor | UK MOD | Managed diode | One-way with content filtering |
| Nexor Sentinel | Nexor | UK MOD | Release authority | Manual review of sensitive transfers |
| Isode M-Guard | Isode | NATO/UK | Messaging guard | Security label checks (STANAG 4774/4778), XML content |
| Isode M-Switch | Isode | NATO/UK | Message gateway | STANAG 4406 MMHS, cross-domain routing |
Relevant Standards
| Standard | Governs | Relevance to Fusion |
|---|---|---|
| MIL-STD-6040 | USMTF message text formats | Text message structure guard validates |
| MIL-STD-6017 | VMF binary message formats | Tactical K-series messages |
| STANAG 4774 | Confidentiality metadata labels | NATO security labels — every message needs one |
| STANAG 4778 | Metadata binding | Binds security label to content |
| STANAG 4406 | Military messaging (MMHS) | Email-like messaging across domains |
| NSA RTB | Raise-the-Bar certification | CDS approval requirements |
Three Guard Inspection Models
The guard type determines the adapter strategy:
-
XML content guard (Owl XD Guardian, Nexor Guardian) — validates message content against an XML/XSD schema. Every field inspected. Our CDG approach (component.parallax.wire-protocol-adapters) maps directly. Derivation type CDG patterns (component.parallax.derived-features) become XSD validation rules.
-
Security label guard (Isode M-Guard) — checks STANAG 4774/4778 classification labels, not message content. Guard verifies who can see it (classification/releasability), not what's in it. Any message format works as long as the security label is correct. Simpler adapter.
-
Message type guard (USMTF/VMF validators) — only passes recognised message types. Content must fit predefined field definitions. Most constrained — format dictated by approved message catalogue.
Critical question for partners: "Is your guard an XML content inspector (Nexor/Owl), a security label checker (Isode), or a message type validator (USMTF/VMF)?" This one answer drives the adapter design.
2. Problem Statement
component.parallax.wire-protocol-adapters defines three deployment options (CDG, xanadu, mTLS). The CDG option assumed we'd propose a custom XML/XSD schema. In practice:
- Guards have a finite set of approved message types
- Getting a new type approved requires accreditation (6-18 months)
- The practical approach is to fit our data into an existing approved type
- Different guards at different boundaries may approve different formats
The engine doesn't care — the adapter translates. But we need to know what the guard passes before we can build the adapter.
3. Candidate Message Formats
3.1 USMTF (United States Message Text Format)
What it is: Fixed-format military text messages. Structured into sets (header, body, narrative) and segments with defined field codes. Descendant of the teletype era but still widely used.
Properties: - Text-based, human-readable (uppercase ASCII) - Rigid field structure with defined lengths and value sets - Guards can inspect and validate every field - Widely approved across classification boundaries - Mature tooling for parse/generate
Potential phase mapping:
| Fusion Phase | USMTF Mapping | Notes |
|---|---|---|
| Phase 1: Bucket Signals | USMTF free-text set with structured key:count pairs? | Need to identify which message type allows structured enumeration |
| Phase 2: Derived Vectors | USMTF data set with named fields? | Soundex codes, year values, hash digests fit fixed-length fields |
| Phase 3: Consensus Scores | USMTF report-type message with confidence values? | Need numeric field support |
What we need to find out: - [ ] Which USMTF message types are approved on the target guard(s)? - [ ] Can we use an existing message type's fields, or do we need a new message definition? - [ ] Is there a USMTF message type designed for data exchange / query results? - [ ] Maximum message size limits? (Phase 2 could have many vectors) - [ ] Does the guard validate field content or just message type/structure?
3.2 VMF (Variable Message Format)
What it is: Binary message format (MIL-STD-6017). More modern than USMTF. Variable-length fields with defined data elements. Used in tactical data systems.
Properties: - Binary encoding (bit-packed fields) - Variable-length — more flexible than USMTF - Defined data element dictionary (DED) with typed fields - Guard must understand binary structure to inspect - Used in tactical networks (Link 16 interop, JTIDS/MIDS)
Potential phase mapping:
| Fusion Phase | VMF Mapping | Notes |
|---|---|---|
| Phase 1: Bucket Signals | K05.1 (General Information) or K02 (Free Text)? | Need DED field for key:count structure |
| Phase 2: Derived Vectors | K31 (Track) data elements? | Track messages already carry entity attributes |
| Phase 3: Consensus Scores | K05.13 (Correlation) or K31.18 (Track Quality)? | Correlation/confidence is native to VMF track domain |
What we need to find out: - [ ] Which VMF message types are approved on the target guard(s)? - [ ] Can VMF K31 (Track) carry arbitrary derived features, or only predefined fields? - [ ] Is VMF correlation (K05.13) semantically compatible with our confidence scores? - [ ] Binary inspection: does the guard parse VMF bit fields or just check message type? - [ ] Bandwidth constraints? VMF is designed for low-bandwidth tactical links
3.3 Other Formats to Investigate
These haven't been mentioned by partners but are common in CDS environments:
| Format | Domain | Why Relevant |
|---|---|---|
| Link 16 J-Series | Tactical data link | J3.x (surveillance), J7.x (information management) — guards pass these routinely |
| OTH-Gold | Over-the-horizon targeting | Track correlation messages — semantically close to our Phase 3 |
| NIEM | US federal data exchange | XML-based, schema-validated — closest to our component.parallax.wire-protocol-adapters CDG approach |
| CCSDS | Space data systems | Standardised space object tracking formats — direct SSA relevance |
| SpaceTrack TLE | Space surveillance | Two-Line Element sets — already a cross-domain standard for orbital data |
| UCT | Unified Correlation Track | Track correlation across sensors — semantically identical to our problem |
| TAP (STANAG 4774/4778) | NATO trusted apps | Metadata binding + content labelling — could carry fusion phases as payloads |
| IC-EDH | Intelligence Community | Enterprise Data Header — classification/handling metadata for any payload |
Action: Ask partners which of these (if any) are approved on their guard(s).
4. Mapping Strategy
Regardless of format, the mapping follows the same pattern:
Fusion Phase Message (Python dict)
↓
Adapter.serialize() ← format-specific
↓
Guard-Approved Wire Format ← USMTF / VMF / XML / JSON
↓
Cross-Domain Guard ← inspects, validates, passes or blocks
↓
Adapter.deserialize() ← format-specific
↓
Fusion Phase Message (Python dict)
The adapter (component.parallax.wire-protocol-adapters WireAdapter) is the only component that changes. The engine, scoring, derived features, consent — all identical.
4.1 Content Validation Levels
Guards operate at different validation depths:
| Level | What Guard Checks | Implication for Fusion |
|---|---|---|
| Type-only | Message type code is in approved list | Any content passes if wrapped in approved type |
| Structure | Fields present, lengths correct, types match | Derived features must fit field definitions |
| Semantic | Field values match expected patterns/ranges | CDG XSD patterns from component.parallax.derived-features must align with guard rules |
| Deep content | NLP/AI content inspection for sensitive data | One-way derived features are the defence — no raw PII to detect |
Key insight: Derived features (component.parallax.derived-features) are designed for Level 3/4 inspection. Soundex codes, year values, hash digests, and geohash strings all have deterministic patterns that a guard can validate. This is the strongest argument for the three-phase protocol over raw data exchange.
4.2 Phase-to-Format Mapping Principles
Phase 1 (Bucket Signals): Easiest to map. Just key:count pairs. Could fit in almost any structured message format. Small payload. Guard validates: keys match blocking pattern, counts are positive integers.
Phase 2 (Derived Vectors): Most complex. Variable number of records, each with multiple derived features. Needs a tabular or repeated-record structure. Guard validates: each feature matches its derivation type pattern.
Phase 3 (Consensus Scores): Moderate. Pair IDs + confidence floats. Guard validates: confidence 0.0-1.0, IDs are opaque references.
PSI Rounds: Will NOT map to any guard-inspectable format. Masked 2048-bit integers are opaque by design. PSI requires a non-inspected channel (mTLS sideband) or same-domain transport (xanadu).
5. Space Domain Application (SSA/SDA)
Space situational awareness is a driving use case for CDS fusion. Multiple sensors (radar, optical, RF, ELINT) observe space objects from different classification levels. Correlating observations requires crossing domain boundaries.
5.1 Space-Relevant Data Elements
| Data Element | Source | Derivation Type | CDG Pattern |
|---|---|---|---|
| Orbital regime | TLE/ephemeris | category |
LEO\|MEO\|GEO\|HEO\|SSO |
| Inclination band | TLE element | numeric_bucket |
[0-9]{1,3} (degrees, 5° bins) |
| Period | TLE/state vector | numeric_bucket |
[0-9]+ (minutes, 10min bins) |
| Epoch | TLE/observation time | temporal_bucket |
[0-9]{4}-[0-9]{2} |
| RCS class | Radar measurement | category |
SMALL\|MEDIUM\|LARGE |
| Object type | Catalogue | category |
PAYLOAD\|DEBRIS\|R\/B\|UNKNOWN |
| NORAD ID | Catalogue (if releasable) | exact or sha256 |
[0-9]{5} or hash |
| RF frequency band | ELINT | category |
UHF\|SHF\|EHF\|Ka\|Ku |
| Country of origin | Catalogue | exact |
ISO 3166 code |
5.2 New Metrics Needed
| Metric | Purpose | Input | Output |
|---|---|---|---|
orbital_proximity |
Compare Keplerian elements | (a,e,i,Ω,ω) pairs | 0.0-1.0 similarity |
state_vector_distance |
3D position+velocity match | ECI/ECEF vectors | 0.0-1.0 (distance-decayed) |
rcs_similarity |
Radar cross-section comparison | RCS values (dBsm) | 0.0-1.0 (graduated) |
tle_correlation |
Two-Line Element set comparison | TLE strings | 0.0-1.0 (multi-element) |
These would be registered in METRIC_REGISTRY (component.parallax.scoring-engine/09) as new
metric functions. Pure functions, same interface as existing metrics.
5.3 Kinematic Filter Extension
component.parallax.tracking-integration's kinematic filter rejects impossible pairs based on physics. For space objects, extend from flat-earth kinematics to orbital mechanics:
- Given object at position A at time T1, propagate orbit to time T2
- If propagated position is within sensor error of observed position B → plausible
- If not → reject pair (can't be the same object)
- Propagation: SGP4/SDP4 for TLE-based, numerical integration for state vectors
This is the space equivalent of "a car can't travel 500km in 5 minutes."
5.4 SSA Lens Example
# space_situational_awareness_v1.yaml
semantic_lens:
name: space_object_correlation
version: "1.0"
domain: space_situational_awareness
identity_fusion:
match_function:
- field: orbital_elements
metric: orbital_proximity
weight: 0.30
- field: observation_time
metric: temporal_proximity
weight: 0.20
params: {max_gap_hours: 24}
- field: object_type
metric: category_agreement
weight: 0.15
- field: rcs
metric: range_comparison
weight: 0.15
params: {tolerance_pct: 30}
- field: inclination
metric: range_comparison
weight: 0.10
params: {tolerance_pct: 5}
- field: period
metric: range_comparison
weight: 0.10
params: {tolerance_pct: 2}
blocking_keys:
- [orbital_regime, inclination_band]
- [orbital_regime, period_band]
thresholds:
initial: 0.60
confirmation: 0.80
# Derivation map for cross-domain exchange
derivation_map:
orbital_elements: sha256 # hash full elements (CDG-safe)
observation_time: temporal_bucket
object_type: casefold
rcs: numeric_bucket # NEEDS: new derivation type
inclination: numeric_bucket # NEEDS: new derivation type
period: numeric_bucket # NEEDS: new derivation type
5.5 New Derivation Type Needed
numeric_bucket — bin a numeric value into a configurable range.
# Example: inclination 51.6° with 5° bins → "50"
# Example: RCS 0.5 dBsm with class bins → "SMALL"
def _derive_numeric_bucket(value: str, params: dict) -> str:
...
CDG pattern: [0-9]+ or category string depending on config.
This would be derivation type #9 in DERIVATION_TYPE_REGISTRY.
5.6 CDS Path for Space Data
Space domain has existing cross-domain message formats:
| Format | What It Carries | Guard Approved? |
|---|---|---|
| TLE (Two-Line Element) | Orbital elements, epoch, object ID | Widely releasable (Space-Track.org is public) |
| CCSDS CDM | Conjunction Data Message — close approach warnings | Used between space agencies |
| CCSDS TDM | Tracking Data Message — radar/optical observations | Sensor-to-catalogue pipeline |
| UCT | Unified Correlation Track — correlated object state | Used in JSpOC/CSpOC systems |
| VMF K31 | Track message — position, velocity, classification | Tactical systems |
If the guard already passes VMF K31 (Track), that's our Phase 2 carrier. Derived orbital features map directly to track data elements.
6. Questions for Partners
CDS / Guard Configuration
- Which message formats are approved on your guard(s)? (USMTF, VMF, XML, JSON, other?)
- At what level does the guard validate content? (type-only, structure, semantic, deep?)
- Are there size limits per message? (Phase 2 may carry hundreds of vectors)
- Is there a process for adding new data elements to an approved message type (faster than new accreditation)?
- Can we use a general-purpose message type (e.g., VMF K02 Free Text) as a carrier, or must content match specific field definitions?
Space Domain
- Which space data formats cross your guard today? (TLE, UCT, CCSDS, VMF K31?)
- Is there an existing correlation message type for space objects?
- What's the classification boundary? (UNCLASS↔SECRET? SECRET↔TS/SCI? Coalition?)
- Are sensor observations (radar tracks) at a different classification than catalogue entries?
- Is there an existing cross-domain workflow for space object correlation that we'd integrate with?
Transport
- Is xanadu (AMQP/RabbitMQ) already deployed in your environment?
- Is mTLS an option for same-classification-level exchange?
- Are there existing message queues / ESBs that carry USMTF or VMF that we could publish to?
7. Implementation Approach
Phase A — Document (NOW): - This spec (component.parallax.cds-message-mapping) captures what we know - Partners answer questions from §6 - Identify which format(s) to target first
Phase B — Prototype adapter: - Pick the most likely format (VMF K31 or USMTF) - Build a concrete WireAdapter subclass that serializes/deserializes - Test with LocalAdapter semantics but format-specific encoding - No guard needed for prototype — just prove the mapping works
Phase C — Guard integration test: - Deploy adapter against actual guard in test environment - Verify all three phases pass inspection - Document any field adjustments needed - Accreditation artifacts (test results, message samples)
Phase D — Space domain metrics:
- Implement orbital_proximity, state_vector_distance, rcs_similarity
- Add numeric_bucket derivation type
- Extend kinematic filter for orbital propagation
- Write SSA lens, test against synthetic TLE data
8. Files
| File | Status |
|---|---|
parallax/ops/fusion/adapters/wire_protocol.py |
EXISTS — interface defined (component.parallax.wire-protocol-adapters) |
parallax/ops/fusion/adapters/usmtf_adapter.py |
FUTURE — Phase B |
parallax/ops/fusion/adapters/vmf_adapter.py |
FUTURE — Phase B |
parallax/ops/fusion/metrics.py |
EXISTS — needs orbital metrics (Phase D) |
parallax/ops/fusion/derived_features.py |
EXISTS — needs numeric_bucket (Phase D) |
parallax/ops/fusion/algorithms/kinematic_filter.py |
EXISTS — needs orbital extension (Phase D) |
9. Dependencies
- component.parallax.derived-features: Derivation types and CDG patterns — guard validation relies on these
- component.parallax.three-phase-protocol: Three-phase protocol — what messages need to cross the guard
- component.parallax.wire-protocol-adapters: Wire protocol adapter interface — adapters implement this ABC
- component.parallax.scoring-engine/09: Metric registry — new space metrics register here
- component.parallax.tracking-integration: Kinematic filter — orbital extension builds on this
Depends on: component.parallax.derived-features, component.parallax.three-phase-protocol
Realizes: product.fusion