ADatP-3 (STANAG 5500): NATO message text formats explained

ADatP-3 — Allied Data Publication 3, promulgated by STANAG 5500 — is NATO's Message Text Formatting System, known as FORMETS: the rules, constructions and vocabulary used to build every NATO formatted message, from a situation report to an air tasking order. The roughly 400 messages constructed to those rules are catalogued in APP-11 — 407 Message Text Formats in the current edition — and since 2008 every one of them also exists as XML-MTF.

What is ADatP-3 (STANAG 5500)?

Formally, the publication is titled NATO Message Text Formatting System (FORMETS) — Concept of FORMETS (CONFORMETS). You will see it written as ADatP-3 or ADatP-03; both refer to the same Allied Data Publication. The current version is Edition A Version 4, promulgated on 1 July 2021, under the covering agreement STANAG 5500 Edition 8. It is maintained by NATO's Message Text Format Capability Team (MTF CaT), and its promulgated editions are listed in the NATO Standardization Office's public database.

What the standard specifies is best quoted from NATO's own summary: FORMETS provides "the syntax and rules governing the representation of agreed conceptual definitions (fields), and the arrangement of these fields into sentences (sets) and message texts", and is intended for all formatted character-oriented messages in NATO command and control. In other words, ADatP-3 is the grammar of NATO formatted messaging. It does not define individual messages — that is the job of the APP-11 catalogue described below.

The design goal explains its longevity. A formatted message must be readable by an operator on a bare terminal, parseable by software on a modern server, and compact enough for a constrained tactical link. Character-oriented, slash-delimited text satisfies all three, which is why ADatP-3 traffic still flows in 2026 alongside everything else in the NATO interoperability standards stack.

ADatP-3, APP-11, ADatP-34, APP-6: which standard is which

These four get conflated constantly — including in vendor marketing — so here is the correct mapping, verified against NATO's public standardization records:

The relationship between the first two is precise. Per NATO's own NISP description, the ADatP-03 database holds all Message Text Formats under the configuration control of the message-format working group, and "the agreed MTFs, once published in a Baseline, will regularly be inserted into STANAG 7149, NATO Message Catalogue — APP-11". ADatP-3 is the grammar; APP-11 is the dictionary of messages written in that grammar. ADatP-34 sits a level above both: the NISP tells programs and Federated Mission Networking (FMN) spirals which standards to use — including ADatP-3 and APP-11 — and defines no messages itself. We cover the NISP's role in profile selection in our ADatP-34 data structures article, and the symbology side in APP-6 vs MIL-STD-2525.

How a formatted message is structured: sets, fields, delimiters

Every MTF message is a sequence of sets; every set is a set identifier followed by fields. Three conventions carry almost all the syntax:

• A set starts with its set identifier — a mnemonic such as MSGID, REF or NARR — followed by a slash.
• Fields are separated by a single slash /. A field is a fixed-format coded entry (a date-time group like 011800Z, a position like 4040N01100E) or a labelled code such as LM:4040N01100E.
• A set ends with a double slash //. Long sets continue on following lines without repeating the identifier.

The example below — a tactical report in the style published in open USMTF documentation, simplified for clarity and not an operational message — shows all three:

MSGID/TACREP/CTF 124//
MAROP/011800Z/1/US/SUB/CL:WASHINGTON/NAME:SEAROVER/
LM:4040N01100E//
OPSUP/ACTTYP:ASW//
AIROP/020200Z/6/US/FTR/F15/TN:401/LM:4130N01000E/
CRS:180/SPD:600KPH/ALT:12000FT//

Certain general-purpose sets recur across operational and administrative traffic: MSGID (message identification — message type, originator, serial), EXER and OPER (exercise and operation identification), REF with its companion NARR (references and their narrative expansion), SUBJ, POC, and GENTEXT, which carries general text under a content specifier (GENTEXT/REMARKS/…//). The exact set composition of each message — which sets, in what order, how often — is defined per message in APP-11.

Each set in a catalogue entry carries occurrence information (mandatory, or conditional on other content) and a repeatability (how many times it may appear — a message citing three references carries three REF sets). Fields have prescribed formats and, for coded fields, defined value tables. Physically, sets are laid out linearly (fields run on after the identifier, as in the example) or as columnar rows — the air tasking order's tasking lines are the classic columnar example, one aligned slash-delimited row per mission or sortie. All of it is upper-case, character-oriented text in a restricted printable character set, which is what lets it survive any terminal and any bearer.

Baselines and editions: which catalogue your parser targets

"Which ADatP-3 are you on?" is the first interoperability question. The message catalogue evolves through versioned baselines, and the deployed fleet is spread across two decades of them:

This timeline is compiled from the public edition history published by the catalogue's maintenance community and from NATO's public records. Two APP-11(E) changes matter to implementers: WGS 84 became the only geodetic datum permitted for positional information (the option to select another datum was removed), and previously coded geographical entities became free text governed by operation-specific lists. Behind the catalogue, the rulebook itself moved from STANAG 5500 Edition 4 (the 1999 baseline era) through Edition 7 (2010) to the current Edition 8, under which ADatP-03 Edition A Version 4 was promulgated in 2021.

Operationally, the baseline in force is set by the tasking chain — the operation plan, the maritime or air tasking messages, or the FMN spiral specification an operation affiliates to. The FMN air-operations profile, for instance, moved formatted-message support from the legacy Baseline-11 ATO/ACO definitions (documented in older Allied publications) to APP-11(E). The same tasking discipline governs data-link operations, where the OPTASK LINK provisions the entire network — see how the OPTASK LINK governs Link 16.

XML-MTF: the same message in XML

Until 2008, formatted messages existed only as slash-delimited text. Since then the APP-11 catalogue also includes XML-MTF definitions, with a deliberate one-to-one mapping between the textual and XML representations — the bandwidth advantage of the text form is preserved while standard XML tooling becomes usable. The concept part of ADatP-3 (CONFORMETS) specifies the XML-MTF family of technical specifications as they are applied to ADatP-03 MTFs to produce equivalent derived XML formats.

Two practical consequences for engineers:

• Standard XML tooling works. Catalogue schemas can drive validating parsers, XPath extraction and XSLT rendering instead of bespoke message code.
• Naming is managed. NATO registered a formal URN namespace (urn:nato:) in RFC 7467, with message-text-format artefacts as a named resource type, so XML namespaces and schemas receive persistent, collision-free identifiers.

The XML representation is also the maintenance path: current catalogue support work includes updating the XML to the latest NATO naming and design rules and introducing a JSON variant of the messages. If you come from the TAK world, note that XML-MTF is a far heavier convention than the Cursor on Target XML that tactical awareness apps exchange — annotated CoT examples show how minimal that format is by comparison, and gateways between the two worlds are their own integration project.

USMTF (MIL-STD-6040): the US counterpart and how it relates

The United States runs its own message text formatting program, USMTF, governed by MIL-STD-6040 (since 2008 the MIL-STD-6040B series, with the catalog delivered as XML-MTF schemas) and managed under the Chairman of the Joint Chiefs of Staff Instruction CJCSI 6241.04E (October 2023). The instruction is explicit about the mapping: the NATO equivalent of the MIL-STD-6040 rules and conventions is ADatP-3, and APP-11 is the equivalent of the USMTF Message Catalog. USMTF is mandatory for all formatted character-oriented message exchange requirements in US systems unless specifically excluded by multinational agreement.

The two rule sets are close: published guidance from the maintenance community describes the rules as very similar with only minor differences, and a number of messages have been harmonized across the two catalogues. Fielded USMTF baselines (1998, 2000 and 2004 in legacy systems) parallel the NATO baseline history. For an implementer the practical takeaway is that one MTF engine can process both — but it must be driven by the correct catalogue pack, NATO APP-11 or USMTF, for the baseline the partner actually runs. And do not confuse either with VMF (MIL-STD-6017), a binary, bit-oriented format for radio links rather than a character-oriented messaging format.

How software processes MTF: parser, validator, generator — and the road into the C2 picture

Formal message traffic is payload, not transport: it rides on military message handling (MMHS, STANAG 4406), on legacy ACP 127 relay, or simply as an email or chat attachment — the FMN profiles explicitly allow formatted messages as payload over several transports. Our companion piece on NATO military messaging covers the handling layer. What the C2 system owes the message when it arrives is a processing pipeline:

• Grammar-driven parsing. Tokenise the text into sets by identifier, split fields on the delimiter, rejoin continuation lines, and build a message tree. The grammar is stable across the catalogue, so one parser handles every message type.
• Catalogue-driven validation. Identify the message type from MSGID, then check set order, occurrence and repeatability, field formats and coded values against the definitions for the agreed baseline. Errors must be reported with set and field position, because the sender has to find them.
• Conversion and mapping. Convert between slash-delimited text and XML-MTF (one-to-one), then map fields into the system's data model. NATO maintains reference models for this — the NATO C2 Information Model (NCIM) and the MIP specifications — and concrete mappings already exist in standards: the friendly-force-tracking standard ADatP-36 specifies the mapping between FFI message text formats and NFFI, and an FMN mediation profile translates FFI MTF to the dismounted-soldier data model.
• Generation through the same catalogue. Outbound, forms-based editors generated from catalogue templates enforce mandatory fields and value tables at input; the generator serialises to text or XML-MTF, validates the round trip, and stamps the date-time group, precedence and addressing.

Because both directions are driven by the same machine-readable definitions, the catalogue is effectively the contract between sender and receiver — which is why formatted-message exchange is a first-class test item at NATO's annual interoperability event, where FMN profiles for air, maritime, cyber and medical-evacuation formatted messages are exercised. Preparing for that is its own discipline: see our CWIX certification guide, and how we surface coalition test results in the Interoperability Dashboard.

Pitfalls that break MTF interoperability

Most formatted-message failures are not exotic:

• Baseline mismatch. A partner still on APP-11(D) sends a message your APP-11(E) validator rejects — or accepts while silently misreading a deprecated field. The APP-11(E) transition deprecated 40 messages and made WGS 84 the only permissible datum; a parser that still honours other datums will corrupt coordinates. Pin the baseline in the operation's communications instructions and detect the sender's baseline from the message identification.
• National extensions. Nations add sets and fields in national variants. The robust strategy is accept-and-flag: parse what the catalogue knows, quarantine and log what it does not, and surface the difference to an operator — never silently drop.
• Free-text abuse. Pushing structured data into GENTEXT or NARR prose because the coded fields "don't fit" destroys machine processing for every recipient. If information matters to automation it belongs in coded fields; if a new coded field is genuinely needed, that is a change proposal to the catalogue, not a local hack.
• Stale editor templates. Forms not regenerated from the current baseline let operators omit newly mandatory fields; validation then fails downstream at the partner instead of at input.