NATO Interop Implementation Walkthrough, Part 1: STANAG Selection and ADatP-34 Profile Alignment

The single most consequential decision in a NATO-interoperable defense software programme is which STANAGs to implement — and crucially, which ones not to. The list of NATO Standardization Agreements runs into the thousands; the relevant subset for any given platform is bounded but never obvious from the outside. A programme that picks too narrow a STANAG envelope fails coalition deployment six months in; a programme that picks too broad an envelope sinks engineering time into compliance work that has no operational customer. This four-part series walks through how to make these decisions well. Part 1 covers the foundation: STANAG selection and ADatP-34 profile alignment.

The architectural framing for this series is in The Complete Guide to NATO Interoperability. The companion engineering walkthrough for the C2 platform that consumes these standards is in Building a C2 System from Scratch. This series goes narrow on the interop subsystem.

Step 1: Scope the Conformance Envelope Before Anything Else

The conformance envelope is the set of STANAGs the platform commits to implementing. The envelope is a procurement document as much as an engineering one — it appears in RFP responses, in accreditation files, and in coalition exercise scoping. Get it right early and the engineering work has clear boundaries; get it wrong and the work scope shifts under the team for the platform's life.

The questions that define the envelope:

• Echelon. Brigade level and below has different STANAG priorities than corps-level or strategic. A tactical platform must speak Link 16 and CoT; a strategic platform may not need either but must speak MIP4 and the broader staff-level catalogue.
• Domain. Land, maritime, air, joint, or multi-domain. Each pulls in different STANAG families — air-defense brings Link 16 plus the surrounding time-distribution and message-format STANAGs; maritime brings COMPD and AIS integration; ground brings MIP4-IES.
• Coalition partners. A platform operating bilaterally with the U.S. has different needs than one operating multilaterally across NATO. Bilateral relationships often work with narrower subsets; multilateral coalition deployment demands the broader ADatP-34 profiles.
• Classification ceiling. Higher classification levels pull in STANAG 4774/4778 binding requirements that lower-classification platforms can defer.
• Time horizon. A platform fielding in two years can target the current STANAG editions; a platform fielding in five years should track the next spiral and budget for the version transition.

Write the answers down. Tag every architecture ticket with which envelope decision it serves. The most common failure pattern in NATO-interop programmes is silent envelope drift — a programme starts targeting "tactical NATO interop" and ends up implementing every STANAG referenced in any RFI response, with no rationale for which ones are operationally required.

Step 2: Build the Relevant STANAG Catalogue

NATO publishes thousands of STANAGs; the software-relevant subset is in the low hundreds; the subset relevant to any one platform is usually 20-40. Build the catalogue explicitly.

The catalogue captures, for each candidate STANAG:

• STANAG number and edition. Version matters: STANAG 4559 Edition 4 is meaningfully different from Edition 3.
• Friendly name and scope. What the standard governs in operational terms — not just "imagery exchange" but "exchanging national-source ISR imagery between coalition C2 systems".
• Operational driver. Why this platform needs it. "Required by procurement RFP" is not enough; the operational use case matters too.
• Implementation effort estimate. Rough categorization: light (under 2 person-months), moderate (2-6), heavy (6-18), extreme (over 18). The estimate is rough; its purpose is to surface the cost-benefit early.
• Conformance test source. Where the conformance test is run — internal CI, NATO CWIX, bilateral with a specific partner, vendor-supplied test harness.
• Implementation status. Not started, in progress, conformance-tested, deployed.

The catalogue is a living document, stored in the programme repository alongside source code, reviewed by engineering and procurement leads. The detailed treatment of the major STANAG families — Link 16, MIP4, STANAG 4559, ADatP-34 — is in NATO Interoperability Standards for Software.

Step 3: Align to an ADatP-34 Profile

ADatP-34 is the NATO master catalogue of interoperability profiles. Where individual STANAGs define standards in isolation, ADatP-34 defines combinations — "tactical brigade profile", "operational corps profile", "strategic joint profile" — that bundle the standards used together in real operational contexts.

The strategic implication: align the platform's conformance envelope to one or more ADatP-34 profiles, not to ad-hoc STANAG combinations. A platform claiming "we implement Link 16, MIP4, and STANAG 4559" without naming the ADatP-34 profile it aligns to is making an unscoped claim that procurement evaluators struggle to verify.

The detailed teardown of ADatP-34 — including the structural anatomy, the profile-versioning model, and the procurement implications — is in ADatP-34 Data Structures: What NATO Interoperability Actually Requires.

For the running example platform — a brigade-level tactical C2 system targeting NATO RESTRICTED coalition deployment — the appropriate ADatP-34 profile is the tactical operational profile that bundles Link 16, MIP4-IES, CoT, STANAG 4559 (consumer-side), and the supporting catalogue of time-distribution, message-format, and classification STANAGs. Different scope decisions would shift the profile choice but not the architectural reasoning.

Step 4: Decide on FMN Spiral Alignment

Federated Mission Networking (FMN) Spiral is a separate but adjacent procurement concern. Where ADatP-34 defines profile bundles, FMN defines a mission-network capability that integrates them with security and service-profile requirements. The current operational spiral is Spiral 4; Spiral 5 is in development.

The questions for the programme:

Does the platform need FMN compliance? Coalition mission-network deployment — Resolute Support successor missions, Allied Reaction Force, equivalent — requires FMN. National-only deployment may not. The programme decision shapes the cost envelope significantly.

Which spiral? If fielding within 18 months, target Spiral 4. If fielding beyond, target Spiral 5 with explicit awareness that the requirements are still moving. Skipping a spiral is rarely viable; the upgrade work becomes its own multi-year project.

What's the conformance testing path? FMN compliance is gated by NATO conformance testing, not self-assessment. Test slots are limited and scheduled well in advance. A programme targeting Spiral 4 should be in the NATO conformance queue 12-18 months before the intended deployment.

The detailed FMN Spiral 4 engineering requirements are in FMN Spiral 4: Requirements and Implementation Notes.

Step 5: Decide on Non-NATO Bilateral Requirements

Most defense platforms also operate alongside non-NATO partners — Ukraine, Israel, Japan, Australia, Korea among others. These relationships introduce standards outside the NATO catalogue but interact with the platform's interop envelope.

The most common non-NATO inputs:

Ukrainian Delta and DZVIN integration. Bilateral data exchange with Ukrainian C2 platforms uses formats outside the NATO catalogue. The engineering pattern, including the Delta format details and integration approach, is in Delta Format and Ukrainian Military Integration. The Brave1 ecosystem context is in The Brave1 Defence Ecosystem.

FVEY-only protocols. Five Eyes partners share intelligence on protocols outside the NATO catalogue. Platforms targeting both NATO and FVEY contexts must handle the dual-track conformance.

Bilateral national standards. The U.S. has additional protocols (CRD, JREAP variants) that are not formally NATO standards but appear in bilateral programmes. The UK, France, and Germany have national overlays. Each is a programme-specific decision.

The non-NATO inputs do not replace the NATO conformance envelope; they extend it. Document them in the catalogue alongside STANAGs, with their own implementation status and conformance testing path.

Step 6: STANAG Version and Spiral Strategy

STANAGs evolve. Editions change, message formats expand, requirements get stricter. The platform must have an explicit strategy for the version transitions that will occur over its operational life.

The pattern that works:

Track current operational editions. The platform implements the editions that current NATO operational deployments require. Older editions remain supported for backward compatibility; newer editions are tracked but not implemented until operationally required.

Plan transitions explicitly. When a new edition becomes operationally required, the transition is a scheduled project with its own engineering budget, conformance retesting, and accreditation update. Treating the transition as routine maintenance produces multi-year delay.

Maintain dual-edition support during transitions. Real deployments straddle editions. The platform supports both for the duration of the coalition transition window.

Engage the standards-development process. Vendors with significant programme exposure participate in NATO standards working groups. The participation surfaces upcoming changes early, gives the team a voice in the requirements, and provides intelligence that procurement competitors do not have.

Step 7: Repository Structure for Interop Code

Interop code is sensitive — touching it incorrectly breaks coalition deployment. Repository discipline reduces the risk.

The structure that works:

• interop/stanags/<stanag-id>/ — one directory per STANAG, with its own implementation, conformance tests, and documentation.
• interop/profiles/<adatp-34-profile>/ — profile aggregations that compose individual STANAG implementations.
• interop/conformance-tests/ — automated test suites, with subdirectories matching the conformance testing source (CI, CWIX prep, bilateral test plans).
• interop/catalogue.md — the living STANAG catalogue.
• interop/profile-decisions/ — Architecture Decision Records documenting the conformance envelope choices.

The structure makes the interop work auditable, allows individual STANAGs to evolve independently, and supports the conformance-testing workflow that gates releases.

What's Next

Part 1 has framed the interop subsystem. Conformance envelope scoped, STANAG catalogue built, ADatP-34 profile alignment chosen, FMN spiral decision made, bilateral requirements documented, version strategy explicit, repository structure committed. The platform now has a defensible procurement story; the implementation work follows.

Part 2 goes into the implementation of the tactical data links that anchor most NATO-interoperable platforms — Link 16, CoT, MIP4. Hardware integration, message marshalling, conformance harness construction, and the engineering disciplines that survive coalition exercise.