ADMP-02 in-service dependability guidance

What it is

ADMP-02, Guidance for Dependability In-Service, is a NATO Allied Dependability Management Publication. It covers the period after a piece of defence materiel has entered service: how an organisation keeps track of its reliability, maintainability, availability, testability, maintenance and safety performance (together, its "dependability"), and what it does when that performance starts to slip. Edition C, Version 1 was promulgated in June 2025 and supersedes Edition B, Version 1.

It does not set dependability requirements. Those are established earlier in an item's life, and ADMP-02 assumes they already exist - the companion document ADMP-01 covers how they are developed. What ADMP-02 adds is the discipline for checking, once an item is fielded, whether the dependability it was designed to have is the dependability it is actually showing, and for deciding what to do about the gap.

Who it addresses and how it takes effect

The document applies to "dependability activities of all items procured for military use within NATO Nations when in-service", and is written for "all members of projects and in-service organizations, including the various NATO Agencies, who are responsible for dependability" (clause 1.3). That is project offices, in-service support organisations, and the NATO Agencies that oversee them, not a design authority and not a certifying body.

It takes effect through recommendation, not agreement. STANREC 4174 records NATO nations' recommendation to use ADMP-02; there is no separate ratification step. In practice a supplier or an in-service support contractor meets it because a nation's support arrangement, or a contract written against NATO dependability guidance, requires it - the same route by which most Allied Publications reach industry.

The monitoring and data collection cycle

The core of the document is a repeating cycle: monitor performance, collect data, analyse it, and act on the result. Monitoring is meant to catch "areas of concern or potentially detrimental trends" early, generating exception reports rather than a flood of raw numbers. The objectives it lists include quantifying achieved dependability, demonstrating compliance with the requirements set earlier in the item's life, validating the Life Profile assumptions those requirements were based on, and assessing an item's remaining useful life.

Underneath that sits data collection, split into three types, each with its own expected content:

• Usage data - operating time, availability status (up, standby, or down and why), events such as failures and overhauls, environmental conditions, configuration changes, and unique identification.
• Failure event data - a description, the identity of the failed system, the time of occurrence, the conditions prevailing at the time, how the failure was detected, its effects, the root cause (including "no fault found" outcomes), and the recovery action taken.
• Maintenance action data - what task was done and why, how long it took, labour and parts consumed, and any problems with maintenance resources encountered along the way.

The document is unambiguous about quality over volume: "Data quality is more important than data quantity", collection should avoid duplicate entry wherever the same transaction can serve two purposes, and the collection process itself should be "routinely audited to assess data quality" by the organisation running it.

Turning data into decisions

Once data has been analysed, using methods the document names from simple (Pareto analysis, stratification, control charting) to structured (Root Cause Analysis, Reliability Centered Maintenance, Condition Based Maintenance, with the classification method itself covered in ADMP-03), a defined set of options follows: improve the maintenance programme, modify or upgrade the item, extend its life through overhaul, replace it, or - where none of those is viable - formally live with the problem while managing its consequences.

Replacement decisions in particular turn on named life-limiting factors: wearout (an inevitable, gradual process), overstress (demanding more of an item than it was designed for), defects discovered after fielding, and obsolescence, which the document is careful to note "is as much of a problem for software as for hardware." These are weighed through optimisation, acceptability and obsolescence criteria to time a replacement before performance actually breaches an unacceptable threshold, rather than after.

Failure analysis and FRACAS

A closed-loop Failure Reporting, Analysis and Corrective Action System (FRACAS) is expected to continue once an item is in-service, using the existing maintenance management information system rather than a separate tool. The failure investigation sequence is fixed: confirm the item genuinely failed, run a physical failure analysis, review technical data in parallel, and use both as inputs to a root cause analysis. Root causes, the document notes, typically trace back to one of six sources: design, components and materials, manufacturing, overstress, maintenance, or wearout.

What an assessor looks for, and what is out of scope

ADMP-02 does not create a certification, accreditation or audit scheme, and NATO does not assess an organisation's conformance to it. The closest it comes to external check is through a performance-based support contract, where an acquirer oversees agreed performance criteria such as availability, reliability, cost per unit usage, and logistics response time - a customer-audit arrangement written into that specific contract, not conformance to ADMP-02 itself. Internally, the document calls for the data collection process to be routinely audited for quality, and for a maintenance review after any safety failure to check whether the maintenance strategy remains adequate.

Two things are explicitly out of scope: ADMP-02 does not set the dependability requirements it monitors against (ADMP-01 does that), and it does not prescribe the detailed method for classifying the data it asks an organisation to collect (ADMP-03 does that). It also notes one exception worth remembering: unlike most of the factors it discusses, age-related deterioration "does not apply to software", even though software is fully exposed to obsolescence.

Standards it references

• ADMP-01Background
• ADMP-03Background
• ADMP-04Background
• AAP-20Background
• AAP-48Background
• ALP-10Background
• ALCCP-01Background