Platform
Modules
By sector
By sector
By standard
Blog
News
Events
AEDP-17
Engineers building or integrating a STANAG 4559 ISR product library server or client application
AEDP-17 defines NSILI, the interface NATO STANAG 4559 ISR product library servers and their clients use to publish, search, retrieve and synchronize ISR products across a coalition network.
AEDP-17 is the Allied Publication that specifies the NATO Standard ISR Library Interface (NSILI): the interface an ISR product library server and the client applications that use it implement to publish, search, retrieve and keep in step with each other's holdings of intelligence, surveillance and reconnaissance (ISR) products. The document calls the server side of this a CSD-Server. It reads like a protocol or API specification rather than a management-system standard, and it names no certification against itself. AEDP-17 does not bind anyone by itself: its own Letter of Promulgation records that "the agreement of nations to use this publication is recorded in STANAG 4559," and a STANAG is what NATO nations ratify. For a supplier, that reaches them only once a national ISR programme or a NATO acquisition names STANAG 4559 / NSILI conformance as a contract requirement. It is written, in the document's own words, "to be used by application designers and software engineers," and a further audience sits above the builders: "members of the JISR community may use the CSD-Server to initialize national system JISR libraries and complement their internal information from other coalition members' systems," describing the national operators who run these systems once fielded.
The interface comes in two families. The CORBA interface "is a mandatory NSIL interface," while "all NSIL Web Service Interfaces... are optional" (clause 2.3). A server has to support CORBA; the web-service interfaces are additional, and server-to-server synchronization uses the CORBA interface only. Which family (or both) a given deployment builds is a design decision driven by what it needs to interoperate with, not a choice the document makes for it.
A CSD-Server has to retain catalogue metadata at a defined precision and present one persisted state that stays consistent no matter which of its interfaces a client uses. If it lets its own metadata model be extended, that has to be configurable when the system is deployed, and newly added attributes can be marked as not searchable. Across every interface, an invalid request "MUST" be rejected in full, leaving anything already stored unchanged, and a valid one has to be carried out completely; the server also has to prevent two conflicting changes from landing on the same catalogue entry at once. Where a server offers the operations to publish, update or retire an entry, those calls cannot be sent blank, an update has to supply the complete set of metadata being changed (including a handful of attributes the server itself assigns and controls), and a call that does not follow the rules is rejected outright rather than partially applied. A compliant server always has to be able to supply any metadata attribute marked "Mandatory" on request, and a client ingesting a new entry always has to supply every one of them. A related, always-available mechanism lets a client retrieve the files linked to an entry, even where those files are also reachable through the entry's own metadata.
Every web-service operation "SHALL be protected from access" using a security mechanism the document describes as "agreed to be mandatory for all SOAP operations in all interfaces," and a service has to refuse a call that lacks sufficient credentials. Authentication overall is optional and, the document notes informatively, only practical on the web-service interfaces, because the CORBA and file-transfer interfaces carry forward an earlier edition's unauthenticated design. Where a server offers search, it has to cap how many results it returns per request to a maximum it declares itself and reject a request outside that range, keep results sorted consistently across repeated paged requests against the same catalogue version, return an empty result rather than an error for a query that matches nothing, and reject a malformed or oversized query.
A defined mechanism lets a deployment add new elements to its own metadata model without breaking interoperability with servers that lack them, with a recommended order for applying such changes. A small number of attributes the server itself assigns can never be extended, and extending anything security-related is technically possible but "strongly discouraged... because of potentially serious side-effects" (clause H-4). Handling catalogue entries that go beyond a server's own metadata model - forward compatibility - is mandatory; handling older model versions - backward compatibility - is optional, and where a server offers it, that is done through a separate set of transformation rules rather than built into the core interface.
Taking on the role of a synchronizing server is itself optional: the document is explicit that this Annex "only enforces requirements on synchronizing servers," and a local, non-synchronizing server on the same network is out of scope of them (clause K-3). A server that does take on that role has to support the entire STANAG 4559 data model, act as a proxy so a client only ever reaches its own local server rather than a remote one, cache what it pulls from remote servers and serialize concurrent requests for the same file, filter so it can synchronize only part of a remote server's holdings, join an existing network of peers and catch up on their history, detect a peer going unreachable on its own and keep retrying the connection, and assign network-unique identifiers to what it originates. Where it also brokers products living on other servers, it has to collect them into a single delivery, coordinate simultaneous requests for the same product into one remote order, prefer ordering a reduced version from the remote server over fetching the whole item locally, and abort an entire order rather than deliver it partially if part of it cannot be retrieved.
AEDP-17 sits under STANAG 4559, the agreement NATO nations ratify, and the document text treats it as binding throughout - a synchronizing server, for instance, has to support the entire STANAG 4559 data model. It is written alongside two sibling publications covered by the same STANAG, AEDP-18 and AEDP-19, which share a base web-service interface with AEDP-17, and AEDP-05, named as source material for this edition. Several STANAGs govern the format of specific product types the interface catalogues, cited binding for that purpose: STANAG 4545 for an overview-image format, STANAG 4607 for ground moving-target-indicator files, STANAG 4609 for motion-imagery files, and STANAG 5516 for tactical-data-link products. ATP-45 and STANAG 2103 are cited together, binding, for how CBRN messages and reports are defined. STANAG 1059 is cited, background, as the source of country codes several attributes use, and STANAG 2433 for how the interface represents a small set of general entity types.
AEDP-17 is an interface specification, not a management-system standard, and evidencing it is software engineering work: building a CSD-Server or client to the interface, running its own conformance test suite against that build, and keeping records of which optional parts were implemented and why. ComplyTrain does not implement or test ISR library interfaces, and it does not replicate, hold or exchange ISR product data - that is the systems' own job, not a compliance platform's. Where ComplyTrain fits is the paperwork around that engineering work: the design and interface documentation recording what was built and against which edition, the training records for the engineers who build and test it, and the audit trail showing those decisions were reviewed as the system changed.
Which parts of STANAG 4559 and AEDP-17 actually apply to a given ISR programme, and to what depth, is set by the contract and the customer's quality clause, not by us. The standards explorer shows what else sits alongside AEDP-17 in the catalogue, including STANAG 4559 and its sibling 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-17 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-17 is the technical content covered by STANAG 4559, and it is STANAG 4559 that NATO nations ratify. A supplier has to build to AEDP-17 only when a national ISR programme or a NATO acquisition contract names STANAG 4559 / NSILI conformance as a requirement.
No. AEDP-17 names no certification body, accreditation scheme or government audit against itself. It defines its own abstract conformance test suite, which an implementer runs against its own build to show it meets the interface; nothing in the document names anyone who administers, witnesses or attests that testing, so it demonstrates interoperability rather than certifying anything.
No. The CORBA interface is mandatory; the web-service interfaces are optional additions. Only server-to-server synchronization is restricted to the CORBA interface.
An optional role a CSD-Server can take on to exchange metadata and files with other library servers on the same network, acting as a proxy so its own clients only ever talk to it directly. A server that does not synchronize is unaffected by those rules; they apply only to servers that take on the role.
All three are covered by STANAG 4559 and share a base web-service interface. AEDP-17 defines the ISR library interface covered here; AEDP-18 and AEDP-19 are the sibling publications that build on the same foundation for streaming and workflow services respectively.
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.