Start a free trial
Menu

APP-06

APP-06 NATO joint military symbology

Vendors building or maintaining the symbology in command-and-control, mission-planning and map-display systems

APP-06 is NATO's Allied Publication for building, coding and displaying joint military symbols, so a symbol looks and encodes the same way on every system that uses it.

Edition
E
Published
2025-10

What it is

APP-06 is NATO's Allied Publication for joint military symbology: the rules for building, colouring and coding every graphical symbol a military system displays, from a single land unit icon to a cyberspace end point. It binds NATO forces directly - the document states it "shall be used by all NATO forces involved in operations, system development, and training" - and it extends its own reach further: "any nation that wishes to achieve Symbology interoperability with NATO is required to use the same standard." For a vendor, that means anyone building a command-and-control, mission-planning or map-display product that has to speak the same symbol language as a NATO system, whether that system is NATO's own or belongs to a nation seeking interoperability with it.

How a symbol is built

Every symbol is built from the same small set of parts: a frame, a main icon, and modifiers and amplifiers placed around it. Icons "are to be framed", with three named exceptions where a frame is optional - land equipment, dismounted individual, and sea surface civilian vessel. Frame line style carries two meanings at once: it marks identity certainty (solid for Friend, Hostile, Neutral and Unknown; a dotted line for Assumed Friend, Suspect or Pending), and separately it marks status ("the symbol frame shall be a solid line when indicating a status of Present or Confirmed", and dashed for Anticipated, Planned or Suspected). Colour is tied to Standard Identity the same way, through a defined table this page does not reproduce. Modifiers sit in one of two fixed positions around the icon, and only one may occupy a position at a time - "multiple modifiers in the same position are prohibited due to legibility concerns", a rule every symbol set in the publication cites back to the same clause. On top of frame and icon, the publication defines a further layer of amplifiers and indicators: headquarters staff and offset-location indicators, a direction-of-movement indicator and speed leader, a task force indicator, a feint/dummy indicator, an echelon indicator, a reinforced/reduced indicator, a mobility indicator, an engagement amplifier, and an area-of-uncertainty indicator. A system meeting something the catalogue does not cover is told to stay inside it rather than invent: "automated systems may have difficulty in passing non-standard symbols."

The symbol sets, by domain

Beyond the general construction rules, the publication builds a separate symbol set for each domain, chapter by chapter. Land symbols cover units, civilian organisations, equipment and installations. Dismounted Individual symbols give a Friend/Assumed Friend soldier a distinct frame, and mark every other identity with the ordinary Land Unit frame plus a modifier showing it is a person rather than a unit. Maritime symbols split into sea surface and sea subsurface sets, each with their own icons, modifiers and rules for a manually tracked contact. Space symbols follow the same general composition pattern. Stability and Civil Support Activities symbols form their own chapter, built the same way as the others. Control Measures and Planning symbols are the largest set by far, and are explicitly built differently: they follow "the draw rules specified in the symbol tables" rather than the icon-based rules above, across sections covering boundaries, points, lines, areas, areas of operations, command and control measures, manoeuvre, airspace, maritime, deception, fire support coordination, targets, target acquisition, force protection, sustainment, intelligence, cultural property protection, and space hazards. Finally, Cyberspace symbols are a deliberate exception: they are "displayed computer aided on the maps of terrain in cyberspace and never drawn by hand", built from six elements - cyberspace units, agents and applications, data, end points, terrain, and paths and actions.

Annex A: the Symbol Identification Code

For a system that has to exchange symbol data, not just draw it, Annex A is the part that matters most. It defines the Symbol Identification Code (SIDC): "a 30-position code that uniquely identifies the core elements needed to build a joint military compliant symbol", to be "used for machine-to-machine processing." Every position is restricted to the hexadecimal range 0-9 and A-F, arranged as three sets of ten positions covering thirteen elements of information.

The first two digits are a version number that "shall increment by one" every time the standard is promulgated. The rest of the first set carries the symbol's context and Standard Identity, which symbol set (domain) it belongs to, its status, and its headquarters, task force and dummy indicators. The second set of ten identifies the entity itself - entity, entity type and subtype. The third set carries the sector 1 and sector 2 modifiers, including a table of modifiers shared across every symbol set.

Who controls that code space is stated plainly: "values within the SIDC given to establish a symbol are provided only by the JSP" - the Joint Symbology Panel - and any value the standard has not explicitly assigned "shall be considered reserved and shall only be assigned by the JSP." A rendering or interchange engine can be built once against the published elements, but it cannot safely invent a code for something the publication does not yet cover. The annex also marks where its own scope ends: the list of geographic-entity codes a SIDC position can carry is, in its own words, "not part of this standard."

Annex B: proposing a change

Annex B is a blank template: the NATO Symbology Change Proposal (NSCP) form, in three parts - a Decision Cover Sheet, a Definition of the proposed change, and an Applicability section. A nation or organisation proposing to add or alter a symbol completes this template and routes it through the Joint Symbology Panel and the Information Exchange Requirements Harmonisation Working Group; "guidance for completion of an NSCP should be sought from the APP-06 custodian." An approved change does not wait for the next printed edition - it is "available immediately for implementation at risk by the Nations" - which matters to anyone tracking symbol-set changes between editions.

How you are evaluated

APP-06 names no certification scheme, no notified body, and no accredited or government body that assesses a system's symbology against it. The NSCP process in Annex B is a change-control route for the standard itself, not a conformity check on a product or an organisation. Correctness in practice is a matter of engineering discipline against the construction rules and Annex A's coding rules, checked by whichever programme office or prime contractor wrote the interface control document and runs the system's own acceptance testing.

Standards it references

APP-06 acquires its force through STANAG 2019, the instrument recording nations' agreement to use it - a cover, not a technical dependency. Two references are invoked in binding terms for construction detail: the codes used in its Sea Surface icons are drawn "in accordance with" APP-20 (printed in its own references as "STANAG 1166 APP-20 Standard Ship Designator System", also held in our catalogue as STANAG 1166), and a target-number field is used "in accordance with STANAG 2484" (outside our catalogue). Its own Appendix A to Chapter 8 states that its mission-task-verb symbols support STANAG 2287.

Several lexicon terms carry their own source citation, all background rather than binding: definitions including "faker", "joker", "pending" and "suspect" are drawn from STANAG 1241, and a footnote on echelon terminology points to STANAG 2651 and ATP-3.2.2.1 for more. Outside our catalogue, it names STANAG 2961 as the source of comparison charts for supply classes, and its own Record of Changes describes an approved proposal to harmonise its cyberspace symbology with MIL-STD-2525, the equivalent United States standard for the same subject. Its reference list additionally names a further set of Allied Joint Publications and STANAGs, offered as related doctrine rather than as sources this specification draws construction rules from: AJP-01, AJP-2, AJP-2.1, AJP-3, AJP-3.1, AJP-3.2, AJP-3.3, AJP-3.3.5, AJP-3.9, AJP-3.19, AJP-3.24, AJP-4, AJP-10, AArtyP-01, AIntP-13, AIntP-17 and STANAG 2433.

How we help

APP-06 is not a management-system standard, and there is nothing here for ComplyTrain to map itself onto. Meeting it is engineering work: a rendering engine built and tested against the frame, colour, modifier and amplifier rules, and a Symbol Identification Code implementation that only uses assigned values and defers anything else to the Joint Symbology Panel. ComplyTrain does not do that work.

What a supplier still has to hold, alongside it, is the paperwork a prime contractor or a customer's interface control review will ask for: a controlled record of which edition and which approved change proposals a given software release was built against, the design and test evidence that a symbol library was validated against the publication's own rules, and a document-controlled trail of decisions taken where a rule left a judgement call. That is the kind of record ComplyTrain holds generally - version-controlled procedures, training records for the engineers and testers who build and check a symbology implementation, and an audit trail of when it was last reviewed and against which edition.

Where the fit ends: ComplyTrain does not build, render or test a symbology library, does not maintain a symbol catalogue, and does not check whether a system's actual output matches APP-06's construction rules or Symbol Identification Codes. That validation stays with the engineering team; ComplyTrain holds the record that it happened. Which of the standards above actually apply to a given programme is set by the contract and the customer's own quality clause, not by this page - the standards explorer shows what else sits alongside APP-06 in our catalogue, and we're glad to talk through what your programme needs to evidence.

Standards it references

Questions

Is APP-06 mandatory for a supplier?

Only through a contract. Nations agree to use APP-06 via STANAG 2019, but that agreement reaches a supplier when a customer's tender, contract or interface control document requires it, not automatically.

Can a company be certified against APP-06?

No. The document names no certification scheme, no notified body and no accredited certification body. It is a symbol construction and coding specification, not a management-system standard, and no organisation holds a certificate against it.

What is a Symbol Identification Code?

A 30-position hexadecimal code that Annex A defines to identify every element needed to build a compliant symbol, intended for machine-to-machine exchange between systems rather than manual drawing.

How does APP-06 relate to MIL-STD-2525?

They are companion standards covering the same subject - APP-06 published by NATO, MIL-STD-2525 the equivalent used by the United States. APP-06's own change record notes an approved proposal to harmonise the two specifically for cyberspace symbology.

Who approves changes to APP-06?

The Joint Symbology Panel, working through NATO's Information Exchange Requirements Harmonisation Working Group, using the NATO Symbology Change Proposal process in Annex B. An approved proposal can be implemented at risk by nations before the next printed edition appears.