S1000D
in plain words.

What is S1000D?

S1000D is an international specification for technical publications. It sets out how the documentation for a complex product is written, managed and published, whether the product is an aircraft, a vehicle, a ship or a single piece of equipment on board.

It started in the early 1980s in the European aerospace industry, whose association is now ASD, and its first issue followed in 1989. Today ASD, the Aerospace Industries Association of America and the ATA e-Business Program produce it together. Military aircraft came first. Since Issue 2 it has covered land and sea as well. The newest issue is Issue 7, released in 2026, and like every issue before it, it can be downloaded free of charge.

The idea behind it fits in one line from the specification’s own site: a move “from a book paradigm to an information one”. How it differs from DITA, iSpec 2200 and Shipdex is in one table.

Which issue of S1000D is current?

Issue 7 is the current issue. The S1000D Steering Committee released it in 2026 with updates to the standard numbering system, the XML schemas, the data dictionary and the default BREX. What changed in detail, and which tools support it yet, is in S1000D Issue 7: what changed. The specification’s own data dictionary dates each issue:

The issue that counts on a project is the one in the contract, and contracts lag behind. The Bundeswehr, for example, still approves only Issues 1.9 and 2.3 for new contracts.

What is a data module?

A traditional manual is a book. S1000D breaks it up into data modules: stand-alone units of information, each about one thing. One module describes the seawater pump. Another says how to remove it. A third lists its parts.

Every data module has two parts. The identification and status section says what the module is, which issue it is at and who may see it. The content section holds the description, the procedure or the parts list itself.

The specification defines a schema for each kind of content, so a procedure is always structured as a procedure and a parts list as a parts list. Among them are descriptions, procedures, fault isolation, illustrated parts data, maintenance planning, crew information and wiring data.

How does a data module code work?

Each module is named by its data module code, the DMC. The code is built from parts that each answer one question: which product, which part of it, what kind of information, and where the work is done.

Anyone who knows the scheme can tell what a module is from its code alone. A description of the same pump would carry information code 040, its parts list 941.

What is a CSDB?

Data modules live in a common source database, the CSDB. Publications are assembled from them by publication modules: the maintenance manual, the operator’s manual, the training material. A module that appears in five publications is written once and kept once. When it changes, every publication that uses it changes with it.

The same modules can be published as PDF, as a printed book or as an interactive electronic technical publication, an IETP, that a technician uses on a tablet or a laptop on board.

What are business rules and the BREX?

The specification runs to thousands of pages and still leaves choices open. So every project adds its own business rules: which elements to use, which codes are allowed, how a warning is worded.

The rules that a machine can check travel as a data module of their own, the business rules exchange module or BREX, with information code 022. A project’s BREX builds on the rules above it: an organisation’s or a navy’s, then the default BREX of the specification. Tools check every module against the BREX before it is released. What that check catches, and what it misses, is in what the BREX checks, and what it cannot. Which rules a navy sets, and which issue it contracts, is the subject of S1000D in naval shipbuilding.

Why is S1000D still so much work?

S1000D describes the result. It does not produce it. The information still comes from the equipment suppliers, in their own manuals: PDF, Word and Excel files, sometimes scanned paper. A single ship can come with hundreds of them.

For every module, a writer finds the right pages, pulls out the steps, warnings and values, rewrites them in the structure the standard and the project rules ask for, gives the module its code and checks it. When a supplier revises a manual, someone has to find every module the change touches. How that work is organised step by step is in how to convert legacy manuals to S1000D, and what it costs in what S1000D really costs.

Where Tracium fits

Tracium does the reading and the first draft. It reads the supplier manuals, drafts the data modules, checks them against S1000D and the project’s business rules and links every step to the page it came from, so that every step has a source. Anything unclear goes to a person, and an expert approves every module before it is published. All of it runs on your own servers.