Platform
Modules
By sector
By sector
By standard
Blog
News
Events
AEDP-19
Engineers designing, building and testing the systems NATO and its member nations use to exchange ISR collection plans, taskings and requests
AEDP-19 is NATO's technical specification for the web-service interfaces that let ISR systems exchange collection plans, priorities, taskings, requests and order-of-battle data across a coalition network.
AEDP-19 is an Allied Engineering Documentation Publication, NATO's name for the technical document that carries the actual requirements under a covering agreement. It sets out the "NATO Standard ISR Workflow Architecture, proposed for agreement under STANAG 4559 Edition 4," and its own Letter of Promulgation records that "the agreement of nations to use this publication is recorded in STANAG 4559." That distinction matters more here than usual: STANAG 4559 is what NATO nations ratify, and AEDP-19 is the specification a nation is agreeing to when it does. It is not a management-system standard, and nobody is certified against it. It is a service-oriented-architecture specification: a set of SOAP and XML web-service interfaces, message schemas and choreography rules that let NATO and national intelligence, surveillance and reconnaissance (ISR) systems exchange the working data of a joint collection cycle. The document states its aim plainly: "to promote interoperability for the exchange of NATO Intelligence, Surveillance and Reconnaissance (ISR) process elements." It is written for the people who build those systems, "intended to be used by engineers during system design, implementation and testing," not for the people who use them operationally day to day.
AEDP-19 organises its interfaces into two layers of a wider STANAG 4559 service stack. A Core Services Layer carries three domain-independent services: Simple Persistence as a Service (SPS++), a Pub-Sub notification service, and the Enterprise Event Relay Service (E2RS). A JISR COI-Specific Services Layer carries six services built for the intelligence community specifically: Organization, Requirement, Priority, Tasking, Request, and Geographic Area of Interest. A cross-cutting set of business rules fixes the topic namespace, entity-identifier format and security mechanism that every one of those nine services shares, so a system that implements several of them behaves consistently across all of them.
SPS++ is the storage layer the other eight services persist through. It stores versioned XML business entities, replicates them between distributed nodes, and resolves the write conflicts that distributed replication produces by tracking version trees and letting a consumer mark a losing branch dead. Implementers choose one of three compliance levels; the document states a preference without mandating the top one, since "a SPS++ service provider SHOULD provide 'compliance level 3', however lower levels of compliance could still be operationally sufficient in a specific deployment." A dedicated procedure specifies how a new node synchronises into a mesh of SPS++ instances that has been replicating for years without disrupting the ones already running, and the document sets a concrete throughput target for it, in clause A-3.7.8.2.7: SPS++ "SHALL be able to provide a throughput of up to 64,850 messages per day." The Pub-Sub service tells higher-layer services about new content without polling, and the Enterprise Event Relay Service is its opposite in reliability: it "SHALL NOT persist messages" and "SHALL NOT queue messages," because it exists only to relay high-frequency, low-payload traffic such as system-status heartbeats.
The Organization Service manages units, locations, operations, ISR systems and the order of battle (ORBAT) connecting them, and lets systems publish and read asset status and heartbeats. It enforces a publishing order: every unit and system named in an ORBAT structure has to be published before the relationships that build that structure are. The Requirement Service manages Intelligence Collection Plans and the information requirements inside them, allowing only one "Current" plan per unit at a time and moving each requirement through a defined status progression. The Priority Service stores weighted priority values that an administrator sets and a collection manager applies to a request, and calculates a combined priority as a weighted sum of them. The Tasking Service runs a choreography between a tasking unit and a tasked asset, each reporting its own status through a defined state model, covering collection tasks and exploitation tasks and letting one task trigger exploitation of another's product. The Request Service runs a parallel choreography for requests for information and ISR requests through an eleven-state model, enforcing that a request has only one unit actively responsible for it at any time. The Geographic Area of Interest Service is the simplest of the six: it stores the geographic areas the other services reference by identifier.
Every operation across every service is gated the same way: access "SHALL be controlled using the 'Username Token Profile 1.1'," and a service throws an access-denied exception if it does not receive sufficient credentials. AEDP-19 names no certification body, accreditation scheme or government audit against itself. The closest it comes is the self-rated compliance level described above for SPS++, and the document is explicit that a lower level than the top one can still be the right choice for a given deployment. In practice, conformance to AEDP-19 is demonstrated by interoperating: a system either exchanges the defined messages correctly with another implementation of the architecture, or it does not.
AEDP-19 sits under [STANAG 4559](/standards/stanag-4559), the agreement NATO nations ratify to commit to it. It is written to complement two sibling publications covered by the same STANAG: [AEDP-18](/standards/aedp-18), NATO Standard ISR Streaming Services, and [AEDP-17](/standards/aedp-17), NATO Standard ISR Library Interface, whose Core Interface every service in AEDP-19 inherits from. The operational procedures this architecture supports are described in [AIntP-16](/standards#q=AIntP-16) (intelligence requirements and collection management) and [AIntP-14](/standards#q=AIntP-14) (joint ISR procedures), and it relates to the doctrine set out in [AJP-2](/standards#q=AJP-2), [AJP-2.1](/standards#q=AJP-2.1) and [AJP-2.7](/standards#q=AJP-2.7). Its reference list also ties [STANAG 6524](/standards#q=STANAG%206524) to AIntP-16.
AEDP-19 is a technical interoperability specification, not a compliance framework, and evidencing it is engineering work: building the interfaces, running the interoperability tests, and keeping the records that show which compliance level a service was built to. ComplyTrain does not implement web-service interfaces or replicate ISR data - that work happens in the systems built to this architecture, not in a compliance tool. Where ComplyTrain fits is in the paperwork a programme building to AEDP-19 still has to produce and keep current: interface-control and design documentation, training records for the engineers who implement and test it, and an audit trail showing those decisions were reviewed as the system changed.
Which standards and compliance tier actually apply to a given ISR programme is set by the contract and the customer's quality clause, not by us. The standards explorer shows what else sits alongside AEDP-19 in the catalogue, including STANAG 4559 and its other covered publications. If your programme is working out what documentation a STANAG 4559-based ISR system needs to carry, talk to us.
Tell us how you need to work with AEDP-19 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.
Not by itself. AEDP-19 is the technical content covered by STANAG 4559, and it is STANAG 4559 that NATO nations ratify. A supplier has to build to AEDP-19 only when a national ISR programme or a NATO acquisition contract names conformance to it as a requirement.
Allied Engineering Documentation Publication. It is NATO's term for a technical annex that carries the detailed requirements under a covering STANAG, as distinct from the STANAG itself, which is the agreement nations ratify.
No. AEDP-19 names no certification body, accreditation scheme or government audit against itself. The closest it defines is a self-rated compliance level for one of its services, which a provider declares rather than has assessed by anyone else.
All three are covered by STANAG 4559 and are meant to be used together. AEDP-17 defines the ISR library interface and the Core Interface the other two build on, AEDP-18 defines streaming services, and AEDP-19 defines the workflow services covered here: organization, requirement, priority, tasking, request and geographic area of interest.
Simple Persistence as a Service, the storage interface every other service in AEDP-19 persists through. It stores versioned business entities, replicates them between distributed nodes, and resolves the conflicts that distributed replication produces.
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.