Platform
Modules
By sector
By sector
By standard
Blog
News
Events
AEDP-7023
Engineers designing or building the collection and exploitation systems on either end of a NATO reconnaissance imagery interface
AEDP-7023 is the NATO data format and transport architecture that lets a reconnaissance collection system hand off imagery and mission data to an exploitation system for analysis.
AEDP-7023, the Air Reconnaissance Primary Imagery Data Standard, is a NATO Allied Engineering Documentation Publication. It fixes, field by field, how reconnaissance imagery and its supporting data move from a collection system, typically a sensor suite mounted in an aircraft, to an exploitation system, the ground station or unit that turns the imagery into intelligence. Where a management system standard tells an organisation what to document, AEDP-7023 tells an engineer exactly which bytes to send: the size, encoding and default value of every field in every header, data file, packet, segment and record a compliant system produces or reads.
The standard did not start life as a separate document. Early editions of this format sat directly inside the STANAG 7023 text; today STANAG 7023 is the short agreement, and AEDP-7023 carries the detail that used to live there. Edition A, published in July 2022, also absorbs implementation guidance that used to be a separate document, AEDP-9, until a planned AEDP-7023.1 takes over that role.
The document is written for "the system designer", the phrase it uses whenever it leaves a choice open: whether to use gimbals tables, which sensor modelling method, which compression scheme. That is a useful signal for who this page is for: engineers building either end of the interface, the collection-side sensor and platform integration, or the exploitation-side decoding and display software, not a compliance or quality function.
AEDP-7023 does not bind anyone by existing. Nations ratify STANAG 7023, and a specific programme meets AEDP-7023 because a tender, contract or interface control document for a reconnaissance system calls it up. That makes the honest moment to start designing against it the point a programme's system requirements name STANAG 7023 or AEDP-7023, not the point a sensor is already built and someone asks whether it interoperates. Retrofitting a data interface after two systems already exist and disagree about it is a design change, not an edit.
Every AEDP-7023 data file is preceded by a fixed 32-byte Header carrying the edition number, flags, segment number, source and file address, file size, a generation counter and a mandatory CRC. A packet on the wire or on a storage medium is a 10-byte synchronisation pattern, that Header, then the data file itself, up to 4 GB. Fields inside a file are marked mandatory, conditional or optional, and even an unused optional field carries a defined default rather than being left out, so a decoder never has to guess whether a field is missing or genuinely absent.
Above the packet level, a record is built from segments. The first segment, number zero, is always the preamble, and its contents have to carry enough auxiliary data on their own for a receiving system to interpret everything that follows. A postamble, if used, repeats some of that data after a segment so a corrupted preamble does not sink the whole record. Multi-record handling is explicitly out of scope for this edition: the standard states plainly that it will be addressed in a future one.
Auxiliary data is the standard's largest section by volume (Annex A runs past a hundred pages) and it is organised by source: format description, mission data (the tasking order, requesters, targets), platform data (position, attitude and velocity of the aircraft), segment and event indexing, and sensor parametric data. Sensor parametric data in turn splits into general sensor identification and calibration, and sensor-type-specific tables for passive (electro-optical and infrared) sensors and radar, including synthetic aperture radar modes, ISAR tracking and ground moving target data.
Compression is optional but tightly scoped: if a sensor's image data is compressed, it is either JPEG (to ISO/IEC 10918-1) or JPEG 2000 (to ISO/IEC 15444-1), using only the markers AEDP-7023 lists, and every compliant collection and exploitation system has to pre-load two fixed default quantisation tables and two fixed default Huffman tables before any custom ones are ever sent. A system that supports JPEG compression but has not pre-loaded those defaults cannot correctly decode a stream that relies on them.
Chapter 7 works through how a system chains platform, gimbals and sensor position and attitude vectors, so that the position and look direction of the sensor can be calculated for any given image sample and used to work out where on the ground a target actually is. This is the part of the standard that turns pixels into a usable location, and it is also where the document is candid about its own limits: the model it presents is a first-order model that does not take first- or second-order derivatives into account.
AEDP-7023 says outright that it is "not a communications protocol", and it leaves the actual transport medium to other NATO standards named alongside it: STANAGs 7085, 4575, 4559 and 3377, plus two it defers to for entire data tables. The 4607 GMTI Data Table and the 4609 Motion Imagery Data Table both simply point elsewhere for their format, the first with the line "See STANAG 4607 for the format of this data", the second with the equivalent line for STANAG 4609. Its JPEG 2000 usage "differs slightly from that in" STANAG 4545, while still conforming to the BIIF Profile for JPEG 2000. And the whole standard sits under STANAG 7023 itself, the NATO agreement, ratified by nations, that this document's detail now belongs to.
AEDP-7023 does not define the physical or logical communications link that carries its packets, does not define how multiple records relate to each other, and describes no assessment, audit or certification scheme for compliance. It is a data format, not a management system and not a contract; what standard a given collection or exploitation system has to meet, and to what tier, is set by that programme's own contract and interface control document.
AEDP-7023 is an engineering interface specification. Meeting it is systems engineering work: interface control documents that fix exactly which tables and fields a system sends, sensor and ground-station design records, interoperability test reports that prove two real systems actually decode each other's output, and version control across a programme as sensors, ground stations and editions change over time.
That documentation and record-keeping work is what ComplyTrain supports: controlled versions of an interface control document, a place to hold interoperability test evidence and design review packages, and training records for the engineers producing them, in one auditable trail rather than scattered across email and shared drives.
ComplyTrain does not decode, generate or validate an AEDP-7023 bitstream, and it does not run the interoperability testing that proves two systems interoperate; that is the day-to-day work of a contractor's systems and software engineers, and it stays theirs. If you are working to STANAG 7023 or AEDP-7023 on a reconnaissance programme, the standards explorer shows the other NATO standards that sit alongside it, and we are glad to talk through how you would evidence the engineering work around it.
Tell us how you need to work with AEDP-7023 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. NATO nations ratify STANAG 7023, the agreement that this data format sits under; a specific collection or exploitation system only has to meet AEDP-7023 when a programme's contract, tender or interface control document calls it up.
STANAG 7023 is now the short agreement by which nations commit to use the format; AEDP-7023 carries the detail that used to be published directly inside the STANAG itself. The document states this change plainly: the move "was simply an editorial change."
No. The document describes no accredited body, notified body or NATO-run scheme for certifying a system against AEDP-7023. Conformance in practice is shown by interoperability: whether a specific collection system's output actually decodes on a specific exploitation system.
AEDP-9 used to carry the separate implementation guidance for this standard. It is expected to be replaced by AEDP-7023.1 when that document is published; until then, AEDP-9 remains the current implementation guidance.
Directly from NATO. It is free of charge and retrieved from the NATO Standardization Document Database, never as a paid or third-party copy.
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.