ADMP-03 guidance for classification and analysis of dependability events

What it is

ADMP-03 is the NATO Allied Dependability Management Publication that gives a standardised way to review and classify events reported during trials, testing and in-service use of a military item, and then analyse the resulting data to support conclusions about its dependability - its reliability, maintainability, availability, testability and safety. It does not set the requirements those conclusions are checked against: that is ADMP-01's job. It does not explain how the underlying test, operational and maintenance data gets collected in the first place: that is ADMP-02's job. ADMP-03 sits between the two, turning a stream of deficiency reports into a classified data set an analyst can actually use.

Edition B, Version 1 was promulgated on 5 June 2025 and is effective on receipt, superseding Edition A, Version 1, which nations are to destroy under their own local procedures. It reaches a programme through STANREC 4174: the recommendation of nations to use it is recorded there, and a STANREC is a NATO recommendation rather than a STANAG, so nations are invited to apply it rather than committed to it by ratification. The document itself sets no obligation on a named party and uses no "shall" language directed at a supplier - it describes a shared method, applied by whoever on a programme is doing the classifying, not a requirement imposed on one side of a contract.

Who does the classifying

ADMP-03 does not define fixed roles. It says event classification "should be established with all stakeholders: design authority, procurement agency, safety officer, and users (maintenance & operations)," and that those stakeholders may take different views, which is worked to "a consensus view" rather than settled by one party's sign-off. Applicability is written broadly too: the document covers dependability activities on all items procured for military use within NATO Nations, at any phase of the life cycle, and "item" itself is defined to include "systems, equipment, be it hardware or software based, and services" - so this is not limited to hardware, or to any one product type.

Three questions for every event

Chapter 2 sets out a repeatable process, applied to every reported deficiency in turn.

Is it relevant? The first question is whether an event belongs in the assessment at all. A tree blown down in front of a vehicle during a reliability trial, damaging the front end, would normally be excluded: the cause sits outside the trial's scope. But if the vehicle's speed and distance from the tree meant its brakes should have prevented the impact, or the specification required it to survive that level of impact, the event belongs in after all. Events caused by outside influences such as lightning strikes, power fluctuations or third-party accidents are recorded against a non-relevant category rather than folded into the count.

How severe was it? Relevant events get a failure level, generically Level 1 (most severe) through Level 4. The level depends on context, not just the immediate effect: the inability to fire during live-fire training could be Level 1 even though training continued in another form, because of what it would mean in combat. A fault discovered during long-term storage is assessed against its effect across the whole life profile, not just the moment it was found. Safety and environmental consequences can override an apparently minor technical effect - a minor fuel leak with no mission impact can still be Level 1 on safety or environmental grounds. Where a user can recover from an event unaided, with on-board spares and within their authority, it may be scored at a lower level than one that needs a workshop, but the document is careful that this cannot become a loophole: frequency, timing (a recoverable fault at a critical combat moment), and any functions that must never be allowed to fail, all bear on the decision.

What caused it? A failure level then gets a cause. Inherent events, where the item could not withstand the stress of normal operation, split into design (the part could not survive the intended use), production/quality (the part was not built to specification) and wear-out (wear arrived earlier, or was more severe, than anticipated). Induced events, caused by something outside the design, split further: secondary failure (damage caused by another failure elsewhere in the item), operator error, maintenance error, technical information error (correct behaviour following incorrect documentation), training, support and test equipment, and external component. Where in-depth analysis still cannot pin down a cause, ADMP-03 allows "unconfirmed" (the fault would not repeat under test) or "unestablished" (a suspect part was replaced but no single root cause could be isolated) - used only once every route of investigation is exhausted and stakeholders agree. It is explicit that recording an unresolved cause as a random failure is not recommended: all events have a deterministic cause, even where the data available cannot show what it was.

From classified events to a dependability figure

Chapter 3 covers what happens once events are classified. Different reliability metrics answer different questions: mission reliability counts only the failures that make an item non-mission-capable (often Level 1 only), while basic reliability counts every level of failure to capture total failure frequency. Operational reliability covers both inherent and induced causes, reflecting what a user actually experiences in the field; inherent reliability covers only design, manufacturing, quality and wear-out causes, and is often the figure used to measure a contractor's performance. A point estimate on its own is not enough - ADMP-03 recommends splitting the data into blocks (by time, distance, or grouping of similar items) and plotting them to look for trends, which can itself feed back into classification by surfacing a wear-out pattern or a batch-specific manufacturing defect.

Two kinds of reliability test produce different kinds of evidence. A Reliability Verification Test (an RQT or a PRAT) reaches a statistically supported accept-or-reject decision against a requirement; fixes are not usually applied mid-test, and confidence intervals are typically built from the chi-squared distribution. A Reliability Growth Test instead uses the same event data to find and fix root causes, tracked through a Fix Effectiveness Factor and one of three approaches - Test-Analyse-Fix-Test, Test-Find-Test, or a combination with delayed fixes - each pointing to different modelling techniques, with MIL-HDBK-189C and the AMSAA projection models both named. The same classification process also supports maintainability, testability, availability and safety assessments, not only reliability.

What it does not cover

ADMP-03 is explicit about its own limits. It does not specify staffing or seniority for a classification meeting, does not prescribe analysis techniques for the classified data, and does not hand over a ready-made template for a functional breakdown or a set of failure definitions - those depend too much on the specific item. Its annexes offer worked approaches, including a detailed combat-vehicle example running to sixteen pages, rather than a fill-in-the-blanks form.

Standards it references

ADMP-03 is carried by STANREC 4174, the NATO recommendation under which nations are invited to use it. It supports ADMP-01, which sets the Life Profile and failure definitions this document depends on, and ADMP-02, which supplies the usage and failure data it classifies. It also references ADMP-04, AECTP-100, AOP-15 (whose safety hazard categories appear in ADMP-03's own example severity table) and IEC 60812 on Failure Mode Effects Analysis. Six further references sit outside our catalogue: IEC 60300-1, IEC 60605-4, IEC 61164, IEC 62740, ISO/IEC 15288 and MIL-HDBK-189C.

Standards it references

• ADMP-01Background
• ADMP-02Background
• ADMP-04Background
• AECTP-100Background
• AOP-15Background
• IEC 60812Background