ADatP-5656 federated service management and control interface

What it is

Nine volumes, one federated interface

ADatP-5656 is NATO's Federated Service Management and Control (SMC) interface: a REST/JSON API standard that lets the Communications and Information Systems (CIS) of different Federated Network Participants (FNPs) exchange service management data across a coalition network. It is published as nine volumes rather than one document. Volume I is the main interface specification, described in the set's own words as the common base every other volume extends: generic payload rules, confidentiality metadata handling, record identifiers, filtering, publish/subscribe and error handling. The remaining eight volumes each standardise one IT service management process as a federated interface: service catalogue management, incident management, request fulfilment, event management, service asset and configuration management, change management, location management, and service request catalogue management. All nine volumes are Edition A, Version 1, each promulgated under its own NATO Letter of Promulgation dated 8 December 2025.

The document names "engineers, system integrators, but also service designers involved in the solution and implementation of SMC systems in FNEs" as its primary audience, and every volume's Scope clause binds "all Service Providers, and the Mission Commander" to be aware of the interactions and dependencies within the federation. Nations' agreement to use the publication is recorded in STANAG 5656. As with any STANAG-covered Allied Publication, that is an agreement between nations, not a rule that reaches a supplier directly: a systems integrator meets ADatP-5656 because a coalition programme, mission mandate or contract requires a Federated Service Management System (FSMS) to expose these interfaces at the federation boundary, not because the document exists.

Each of the eight process volumes builds directly on an existing TM Forum Open API specification, the REST APIs the telecoms industry uses for its own service management, adapted with NATO-specific "federated" extensions. Every volume states that the specifications it references, wherever cited in its text, "constitute provisions of this ADatP," so this borrowing is binding rather than background reading.

What each volume standardises

Volume II, Service Catalogue Management, splits a provider's offerings into Customer Facing, User Facing and Resource Facing Services and requires Customer Facing Services to be published through the Service Catalogue API specifically, keeping orderable items in the separate Service Request Catalogue.

Volume III, Incident Management, is built on the TM Forum Trouble Ticket API and governs the handover of an incident between the participant that raises it and the one that owns the affected service. Only those two participants may write to the incident; an incident already exchanged "must not be forwarded or reassigned to another Service Provider to prevent record chaining," a new one is created instead; and an incident left in a resolved state closes automatically after a waiting period if the originator does not respond.

Volume IV, Request Fulfilment, extends the TM Forum Service Ordering Management API. A request always relates to a Customer Facing Service in the catalogue, carries a single order item, and a provider can only accept or refuse it outright. Only the provider, never the requesting consumer, can mark a request cancelled through the API, and requests are deliberately left out of the publish/subscribe mechanism because they are "not considered critical information in federated environments."

Volume V, Event Management, adapts the TM Forum Alarm Management API to hand events between a sending and a receiving participant. Purely national events must not be shared into the federation; nations are expected to filter and correlate before sharing. Any event concerning a federated CIS Service is itself treated as federated, and only the affected service's owning provider may change an event's status.

Volume VI, Service Asset and Configuration Management, defines twelve types of Federated Configuration Item, from software and databases to network devices and physical servers. A provider that shares a configuration item into the federation keeps ownership of and responsibility for it throughout.

Volume VII, Change Management, extends the TM Forum Change Management API. A change affecting a federated service is routed to the Service Management Authority (SMA) for coordination and must never be circulated onward to another participant; "only the two participants service owner (Service Provider) and change owner (SMA) have write-access to the Change," and a Service Consumer cannot originate one.

Volume VIII, Location Management, standardises three related resource types - a geographic site, a geographic address and a geographic location - each identified and exchanged separately, of which only the location type carries publish/subscribe support.

Volume IX, Service Request Catalogue Management, governs the catalogue of orderable offerings a provider exposes to the federation. Every offering must tie back to a service already in the CIS Service Catalogue, and a provider is expected to keep at least a daily refresh of what it publishes.

What is common across every volume

A handful of rules recur through the whole set rather than belonging to any one process. Mandatory attributes must always carry a value; a null or empty mandatory field is not accepted. Collection queries default to excluding closed, terminated or retired records unless a caller specifically asks for them. By default a provider returns only the data it owns, not the whole federation's, except in specific circumstances such as a formal transfer of management authority. Deleting a subscription is the only DELETE operation the interface permits anywhere, which the document ties to keeping the record's own history traceable and transparent. And a lighter "Remote FNP Provider" mode of participating in the federation is stated, volume after volume, never to be enough on its own to let a participant take on the coordinating Service Management Authority role for that process; that role needs a fully functional Federated Service Management System with full support for the volume in question already built.

Two points are worth flagging because they bound what the standard covers. Implementers are told it is "crucial to ensure information security and protection of the REST API interfaces proposed," but the document is explicit that meeting that requirement is left to "governance and framework agreements in the area of operation" or national implementation guidelines, and states plainly that it "is not part of this standard." And this edition's machine-checkable JSON Schema files had not yet been issued when it was promulgated, with several volumes noting they would follow in a future annex, so conformance for now is checked against the written attribute tables and worked examples rather than an automated validator.

How conformance is checked

No certification body, test house, government quality-assurance representative or accreditation scheme appears anywhere across the nine volumes. Each volume states that its Conformance Profile "follows the TM Forum guidelines," and conformance is demonstrated by matching an implementation's own request and response payloads, operation by operation, against that volume's attribute tables (each attribute marked mandatory, conditional, optional or not applicable) and against the worked REST/JSON examples in the volume's own annex. An organisation confirms it is ready to interoperate through Volume I's Operational Readiness Interoperability procedure: building its own service registry, configuring its outbound connections, and being formally "activated," typically through the Change Management or Request Fulfilment process itself. That is a technical and procedural readiness check between federation participants, not a certificate any third party awards, and nothing in any of the nine volumes states that a Service Provider, a vendor or a product can hold a certification against ADatP-5656.

Standards it references

ADatP-5656 is covered by STANAG 5656, the NATO Standardization Agreement recording nations' agreement to use it. Confidentiality metadata on SMC data is labelled and bound under ADatP-4774 and ADatP-4778, both cited as binding.

Outside NATO's own catalogue, every volume extends a named TM Forum Open API specification: the Trouble Ticket API for Incident Management, the Service Ordering Management API for Request Fulfilment, the Alarm Management API for Event Management, the Resource Inventory API for Service Asset and Configuration Management, the Change Management API for Change Management, the Geographic Address, Site and Location Management APIs for Location Management, and the Service Catalog Management API for both catalogue volumes, each profiled against TM Forum's own REST API Design Guidelines and API REST Conformance Guidelines. The interface also builds on IETF's rules for reading "shall/should/may," JSON Merge Patch for PATCH requests, the data URL scheme for inline attachments, and the IANA Media Types registry for MIME types. None of these TM Forum or IETF specifications are in our catalogue.

Standards it references

• AJP-6.1Background
• ADatP-4774Background
• ADatP-4778Background