Technical manuals
S1000D data module codes, explained
The parts of an S1000D data module code, from model identification code to item location code, with their lengths in the Issue 7 schema, what public Navy, Air Force and Swedish rules say about each, and a worked example.
Oct 22, 20265 min read6 sources
Why it matters
Every S1000D data module is filed and retrieved by its code, and the Issue 7 schema makes eleven parts of that code mandatory.
The short version
- 1The Issue 7 dmCode element has eleven required attributes, from modelIdentCode to itemLocationCode, plus two optional learning codes.
- 2Item location codes are A on the product, B on a removed major assembly, C on the bench, D all three, and T training only.
- 3Air Force rules let the disassembly code split one long descriptive module only when every other part of the code is identical.
A data module code (DMC) is the identifier each S1000D data module carries: a string that names the product, the part of the product, the kind of information, and where the work is done. The S1000D Issue 7 schema defines the code as an element with eleven required attributes and two optional ones. A 2011 Naval Sea Systems Command (NAVSEA) acquisition guide from the Naval Surface Warfare Center, Carderock Division, says the DMC uniquely identifies a data module, ties it to components of the product, and guards against duplicate data.
The parts, in schema order
The S1000D site's data dictionary page links an online dictionary for each issue from 4.0 to 7, with the Issue 7 dictionary dated August 27, 2026. The Issue 7 schema files carry an issue date of July 16, 2026. The Issue 7 simple types set what each part may hold. The length patterns allow only capital letters and digits.
| Part | Issue 7 attribute | Allowed length or values |
|---|---|---|
| Model identification code | modelIdentCode | 2 to 14 characters |
| System difference code | systemDiffCode | 1 to 4 |
| System | systemCode | 2 or 3 |
| Subsystem | subSystemCode | 1 |
| Sub-subsystem | subSubSystemCode | 1 |
| Assembly | assyCode | 2 or 4 |
| Disassembly code | disassyCode | 2 |
| Disassembly code variant | disassyCodeVariant | 1 to 3 |
| Information code | infoCode | 3 |
| Information code variant | infoCodeVariant | 1 |
| Item location code | itemLocationCode | A, B, C, D, or T |
The two optional parts are a learn code, three characters beginning with T or H, and a learn event code, A through E. The NAVSEA guide says learn codes may help projects producing training data.
Model, system difference, and standard numbering system
The model identification code names the product and prefixes every DMC in a project. The registrar's name differs by source and date. The 2011 NAVSEA guide sends projects to the North Atlantic Treaty Organization (NATO) Maintenance and Supply Agency (NAMSA). MIL-STD-3048A, the Air Force business rules dated April 29, 2016, names the NATO Support Agency and sets "USAFGP" as the code for general purpose modules. The 2016 naval business rules of Sweden's Defence Materiel Administration (FMV) name the NATO Support and Procurement Agency.
The FMV rules explain the system difference code: it marks different versions of a system, such as alternative engines in a ship. The main system is always A, alternatives continue with B, and the code can grow to four characters.
The standard numbering system (SNS) follows. MIL-STD-3048A defines it as three groups of characters for arranging or addressing the product, and the FMV rules write it as system, then subsystem and sub-subsystem, then unit or assembly. Under NAVSEA rules, a project uses a maintained SNS from the specification, the Expanded Ship Work Breakdown Structure, or a project SNS registered with the NAVSEA S1000D configuration control board, in that order of preference.
Disassembly, information, and item location codes
The NAVSEA guide says the disassembly code identifies the breakdown condition of an assembly and also numbers illustrated parts data modules in sequence. MIL-STD-3048A adds another, narrower use. A long descriptive module may be split by disassembly code, counting from "01," only when model, system difference, SNS, and information code are all identical, and never for content under the equivalent of 30 printed pages.
The information code is a numeric code for the type of content. The NAVSEA guide gives the 400s for fault reporting and isolation and the 500s for disconnect, remove, and disassemble procedures; the FMV rules give 040 for a general description. MIL-STD-3048A requires the Joint Service information codes and bars projects from using unassigned ones.
The item location code says where the task happens. The NAVSEA guide lists A for items installed on the product, B for items on a major assembly removed from it, C for items on the bench, D for all three, and T for training-only modules, the same five values the Issue 7 schema allows. The FMV rules describe it more loosely, as where maintenance is performed, with A-level and C-level as examples.
A worked example
This breakdown is an illustration. MIL-STD-3048A uses DMC-RADIOXYZ-001-001-23-4750-01000-012J-A as a sample cross-reference to a "Radio XYZ" safety summary. Read against the Issue 7 lengths, the hyphenated groups split this way:
- RADIOXYZ: model identification code.
- 001: system difference code.
- 001-23-4750: system 001, subsystem 2, sub-subsystem 3, assembly 4750.
- 01000: disassembly code 01, variant 000.
- 012J: information code 012, variant J.
- A: item location, on the product.
Each group fits its Issue 7 pattern: 4750 uses the four-character form of the assembly code, and 000 the longest disassembly code variant allowed. The split is a reading of the schema lengths, not a statement from the Air Force standard, which gives the string only to show how a hyperlink to another module should look.
What to check
- Which issue's schema does the code validate against? Issue 7 allows 2 to 14 characters for the model identification code.
- Is the model identification code registered, and do the project business rules record it?
- Do the project business rules document the SNS and why it was chosen, as MIL-STD-3048A requires?
- Is the information code a Joint Service code rather than an unassigned one?
- Does the item location code match where the task is done: product, removed assembly, bench, all three, or training?
- Where a disassembly code splits a module, are all other parts of the code identical and the content descriptive?
Azcuna's TRACE is one offline viewer for S1000D, MIL-STD-3001 XML, and PDF technical manuals. It keeps the source location and the markings of everything it shows and never modifies the source. It was proposed to NAVAIR under Navy SBIR Phase I topic DON26BZ05-NV078, and the proposal was submitted on September 23, 2026.
Sources
- 1S1000D Issue 7 XML schema, complexTypes.xsd · ASD, AIA and ATA e-Business Program, S1000D online data dictionary, issue date July 16, 2026
- 2S1000D Issue 7 XML schema, simpleTypes.xsd · ASD, AIA and ATA e-Business Program, S1000D online data dictionary, issue date July 16, 2026
- 3Data Dictionaries · S1000D Council and Steering Committee (s1000d.org)
- 4NSWCCD-20-TR-2011/06, Procedures for the Acquisition and Development of NAVSEA TMs/IETMs in Accordance with International Specification S1000D · Naval Surface Warfare Center, Carderock Division, October 2011
- 5MIL-STD-3048A, Air Force Business Rules for the Implementation of S1000D · Department of the Air Force, April 29, 2016, via EverySpec
- 6S1000D Business Rules för Sjöstridsmateriel, utgåva 1 · Swedish Defence Materiel Administration (FMV), March 9, 2016
Where this shows up in our work
- TRACE, the offline S1000D and IETM viewer opens S1000D, MIL-STD-3001 and PDF technical manuals on a tablet with every marking intact.
- ELLMENT, the offline LLM for E-2D crews answers a crew's question from the aircraft's own manuals and cites the page, with no network.
