S1000D — Aerospace & Defense Technical Publications Standard

The unit of content in S1000D is the data module: a self-contained piece of information — a maintenance task, a description, a fault isolation procedure, a parts listing — valid on its own and stored once in the Common Source Database. Each is identified by a Data Module Code, a structured identifier that encodes what the module is about (the product and its breakdown), and what kind of information it carries. Content is addressed by that code rather than by the document it appears in, which is what makes reuse across publications real instead of aspirational.

Publications are then assemblies: a publication module lists the data modules a deliverable draws in, and the same source modules feed a page-based manual, an interactive publication, or a portal without being copied into any of them.

The specification is deliberately permissive: it offers options in data module coding, applicability handling, information sets, and exchange, and expects each program — or each industry — to settle them. Those settled choices are the business rules, and they are where most of the real definition work on an S1000D program lives. Layers exist above the specification for exactly this reason: ATA Spec 1000BR settles the choices for civil aviation, MIL-STD-3031 settles them for the U.S. Army, and MIL-STD-3048 for the U.S. Air Force.

BREX — the Business Rules Exchange — is the part programs most often underuse. It is a data module that states the rules in machine-readable form, so conformance can be checked at authoring time rather than discovered at delivery review. Business rules written only as a document are guidance; a BREX enforced in the authoring environment is configuration.

S1000D is published in numbered issues: Issue 4.1 (2012) and 4.2 (2016) remain widely contracted, Issue 5.0 arrived in 2019, Issue 6 followed in 2024 — and Issue 7, a new major revision, was released in 2026 and is now the newest issue available from the official downloads site. Programs do not simply adopt the latest: the issue in force is set by contract and by the business rules layer, which is why Issue 4.x libraries remain in active production. The U.S. Army's MIL-STD-3031 business rules, for example, currently align to Issue 4.2.

Moving between issues is a project, not an upgrade — schema versions, applicability handling, and default exchange behavior all shift — so the issue decision belongs at program start, made once, with the supply chain in the room. We are tracking what Issue 7 changes in a dedicated briefing as the details are digested.

The work has an order, and programs that respect it spend less. First, pin the contracted issue and the business rules — everything downstream is configured by those two decisions. Second, agree the Standard Numbering System: the product breakdown that every Data Module Code will encode, which has to be settled once, with engineering in the room, before anyone authors against it. Third, build the Data Module Requirements List — the DMRL, the planned inventory of every data module a deliverable owes. The DMRL is the scoping instrument and the progress tracker in one: until it exists, an S1000D estimate is a guess, and once it exists, completion is a count, not an opinion.

Only then does production begin: stand up the CSDB and its workflow, enforce the business rules in the authoring environment through BREX, and bring legacy content across against a sampled conversion plan rather than an optimistic one. Publish early from the real pipeline — the first PDF or IETP built from actual data modules surfaces the integration problems while they are still cheap. Teams that buy tools first and make these decisions later meet them all again, at delivery review prices.