Platform
Modules
By sector
By sector
By standard
Blog
News
Events
AEDP-12
Engineers and programme teams building or integrating NATO ISR tracking systems that must produce or consume STANAG 4676-conformant track data
AEDP-12 is NATO's technical specification for the data model, XML schema and optional binary encoding used to exchange ISR tracking data between NATO systems, under the STANAG 4676 agreement.
AEDP-12, the NATO ISR Tracking Standard's technical document, is the Allied Engineering Documentation Publication that carries the actual content behind STANAG 4676. The two names are often used as if they were interchangeable, and the document itself heads that off in its own conventions: "AEDP-12 refers to the technical standard document, including its data model," while "STANAG 4676" refers to "the agreement among the nations to implement the standard." Its stated aim is "to promote interoperability for the production, exchange, and exploitation of tracking data among North Atlantic Treaty Organization (NATO) Intelligence, Surveillance, and Reconnaissance (ISR) systems." What that means concretely is a data model, expressed in UML, of everything a "track" is built from - sensors, detections, track points, position and velocity, evidence, identity, and the relationships (splits, merges, stitches) between tracks - together with a normative XML schema and an optional binary encoding, EXI, that turn the model into a file or stream a system can actually transmit.
The current edition, read here, is Edition B Version 2, promulgated March 2022. It is not a light revision: "STANAG 4676 Ed. 2 is incompatible with STANAG 4676 Ed. 1," because the data model and XML syntax were re-architected from scratch to meet functional and data-size requirements the earlier edition could not. A system built against Edition A cannot exchange data with one built against this edition without a deliberate translation step.
The document speaks throughout to the people who build the systems that produce or consume this data - "data producers" and "data consumers" in its own terms, rather than "suppliers" as such. Its extension rules are written straight at them: "if the data producer has additional data to communicate for an object, it shall use those extension mechanisms to add additional data fields to the object," and any such extension must sit in "a namespace specific to the program, system or developer of the extension." In practice, that is the contractor or programme office building or integrating a NATO ISR tracking capability.
How it binds follows the pattern common to every Allied Publication: the STANAG covering it is what nations ratify, and AEDP-12 supplies the technical substance that ratification puts into effect. A nation can ratify with reservations against specific parts of AEDP-12 rather than all of it - this edition's own promulgation record shows France declining to implement Annexes B and C "as it stands because they were drafted using a process that does not comply with APP-15," and Belgium accepting the standard for its existing air assets while reserving judgement on the F-35 pending delivery. AEDP-12 itself does not describe how this reaches a particular company; that is a matter for the contract or national authority that invokes STANAG 4676/NITS conformance on a given programme, not something the technical document sets out.
Every conformant file or data stream carries exactly one root object, NITSRoot - "a conformant instantiation of the model shall contain one and only one NITSRoot object" - holding a compliance-profile declaration, a creation timestamp, an edition/version string, and blocks describing the product, the collection, the sensors and trackers involved, and the TrackMessage itself. TrackMessage is where the tracking content lives: detections, TrackData built from one or more TrackSegments of TrackPoints, ProcessedTrack records for fused or smoothed output, TrackLinkage records for splits, merges and stitches between tracks, and MotionEvent records for a maneuver of interest such as a start, stop or convoy.
A file declares one of two compliance profiles. STANDALONE means every object it references is included in that same file. DATASTREAM means later files may reference objects sent earlier rather than repeat them, which is more compact but places a real burden on the consumer: a system that cannot retain data between files, or that reads the stream too slowly to catch every part, cannot use DATASTREAM output at all. Which profile a system chooses is an architecture decision made when the system is designed, not something changed later without effect.
Annex A, though the document marks the whole annex informative, walks through the fields Chapter 2 already makes mandatory: a compliance profile, creation time and edition/version string on the root object; an identifier and name for the product; the collection's intent (operational, exercise, test, and so on) and essence (real, simulated or a mix); a sensor name and modality; a tracker type, name and version; a message base time and time increment; and, on each block of position and motion data, the coordinate system and position itself. "Table A.1-1 are the minimum mandatory data fields that must be supplied." Anything short of that is not a conformant STANAG 4676 track, whatever else the file contains.
A producer with data the model does not cover has to use the schema's own extension mechanism rather than repurpose an existing field, and disclose it fully: "the complete syntax and semantics of all extensions shall be disclosed to the owning party with sufficient detail to allow a vendor of the owner's choice to correctly parse and interpret the data." An extension cannot redefine how the core standard is interpreted, and a consumer that does not recognise a given extension still has to correctly interpret the rest of the file around it.
Classification is handled through STANAG 4774's confidentiality metadata labels rather than anything AEDP-12 defines itself: the root object "must contain the originatorConfidentialityLabel element and may also contain the alternativeConfidentialityLabel element and the metadataConfidentialityLabel element, as required by system requirements." Nation-specific labelling schemes layer on top of those elements, not instead of them.
On encoding, a conformant implementation transmits data as plain-text XML or as EXI, the W3C's binary format for XML: "Conformant implementations shall exchange data using one of these two encodings specified in this standard," and the Custodial Support Team's own recommendation favours EXI over plain text for anything beyond small, low-rate data, since plain text "will be detrimental to satisfying program requirements" wherever low latency or limited bandwidth matter.
There is no certification body for AEDP-12, and the document sets none up: no accredited body, no NATO-run scheme, no government surveillance regime is described anywhere in it. What the document does define is a technical, testable property: "The XML schema defined within the standard is normative for conformance only. Implementations may use any method to write the XML formatted data as long as that resulting data conforms to the schema." In practice a producer's output either validates against that schema, and for EXI decodes back to the same schema-conformant content, or it does not; a consumer either correctly interprets a conformant file's object model or it does not. The document names no periodic audit or interoperability-testing cycle of its own, beyond noting that new extensions and compliance profiles should be registered with the Custodial Support Team.
AEDP-12 is covered by STANAG 4676, the ratified agreement that gives it force. Beyond that cover, it draws on and points to a wide set of other Allied and civil documents, each for a specific piece of the model: STANAG 4774 and ADatP-4774 for confidentiality labelling; STANAG 4607 for the Ground Moving Target Indicator fields the radar classes map onto directly; STANAG 4609 for the motion imagery standard its imagery classes are aligned to; STANAG 4545 for the imagery format its station-ID fields come from; STANAG 1241 for the identity values its identity class is built from directly; STANAG 2019, covering APP-6, for the symbology table used to classify a tracked object; STANAG 4162 and AIDPP-01 for the identification data-combining process behind its ID-source classes; and STANAG 7194, STANAG 4193, STANAG 5516, STANAG 4559 and its companion publications AEDP-17, AEDP-18 and AEDP-19, AJP-2.1, and APP-15, named in this edition's own reservations record as the drafting standard two of its annexes were found not to follow.
AEDP-12 is a technical, operational standard rather than a management-system one. The work it actually demands - building a conformant data model, implementing the XML schema, choosing an encoding, registering extensions with the Custodial Support Team - is systems and software engineering, and ComplyTrain has no part in writing or testing that code. What we can honestly help with is the evidence trail around that engineering effort: a controlled place to hold the design decisions a programme has to make and justify (which compliance profile, which encoding, what extensions were registered and to what namespace), the confidentiality-labelling procedure a system follows, and the records an integration or interoperability review would ask to see. That is the same documentation and training-record discipline ComplyTrain supports for any technical standard, not a substitute for the engineering itself.
What ComplyTrain does not do: it does not implement, test or validate a system's STANAG 4676/AEDP-12 conformance, and it holds no certification against this standard, because none exists. Which standards a given programme has to meet is set by the contract and the customer's quality clause, not by us. See what else sits alongside AEDP-12 in the standards explorer, and talk to us about the evidence trail behind a technical implementation like this one.
Tell us how you need to work with AEDP-12 and what you need from it. We will come back to you about what ComplyTrain can do.
Thank you. Your list is on its way to your inbox, and we will come back to you on what working with these standards in ComplyTrain involves, usually within one business day.
No, though the two names are often used loosely as if they were. STANAG 4676 is the agreement among NATO nations to implement the standard; AEDP-12 is the technical document itself, holding the data model, the XML schema and the encoding rules that agreement puts into effect.
AEDP-12 does not itself say. It binds through STANAG 4676, which nations ratify (sometimes with reservations against specific parts of AEDP-12), and reaches a particular contractor only when a contract or programme requirement calls for STANAG 4676/NITS-conformant tracking data. The document names no mechanism by which it applies automatically to a supplier.
No. The document describes no certification scheme, accredited body or government surveillance regime. Conformance is a technical property: whether a system's output validates against the XML schema in Annex B, which a programme or its customer tests directly rather than something an external body certifies.
STANDALONE means a single file includes everything it references, so it can be read on its own. DATASTREAM means later files can reference data sent in earlier ones instead of repeating it, which is more compact but only works if the consumer can retain and reassemble the full sequence.
Not without translation. AEDP-12 states plainly that "STANAG 4676 Ed. 2 is incompatible with STANAG 4676 Ed. 1," because the data model and XML syntax were rebuilt from scratch between editions.
One system for the whole compliance programme. Start with the module you need most.
Collect information the same way every time, and decide in advance what happens next.
Know whether your controls are operating, not just whether a policy says they exist.
Turn the compliance work you already know about into a plan with owners, dependencies and dates.
Know what you can offer, and hold the evidence behind every configuration you offer it in.
Eight built-in reports across every module, scheduled, delivered, and filed where the evidence lives.
The sector news that matters to your organisation - read and rated by AI, and delivered as a scheduled digest in your own language.
AI reads the tender pack and pulls out the requirements, deadlines and rules - then helps you draft the response from your own approved content, with you reviewing every step.
One current register of the suppliers and partners you depend on - each risk-assessed, re-assessing itself on schedule, and wired straight into your risk register.
See every requirement you face - across every standard, plus your own contracts and policies - traced to the documents, evidence and processes that satisfy it.
Identify, score, treat and review your risks in one place - with AI to help anyone run a proper assessment, and a defensible trail behind every decision.
Assign training, prove it was understood, and hold the competence records an auditor asks for.
Draft compliance documents with AI, keep every version under control, and export them beautifully branded - all in one place.
Audits, corrective actions, processes and approvals in one quality system, organised around ISO 9001.
Medical device manufacturers operate under more regulatory pressure than almost any other sector outside pharmaceuticals. The rules govern how you design a device, how you make it, how you track it after it ships, and how you respond when something goes wrong.
Learn how EU dual-use export controls apply to encryption, sensors, and software, how classification works under Annex I, and why sending source code by email can count as an export.
A practical way to turn in-your-head risk management into a register that survives staff turnover and answers the risk questions now showing up in tenders.