S1000D in naval
shipbuilding.

Do navies require S1000D?

Many do, but not through one rule. There is no single requirement that makes S1000D compulsory for every navy. Each navy, and in the end each contract, decides whether S1000D applies, which issue of it, which business rules and which breakdown of the ship. A yard that builds for two navies can end up writing to two different versions of the same standard.

So the first question on a naval programme is not whether S1000D, but which S1000D. The answer is in the contract and its annexes, and it is often older than you would expect.

What do the US, Sweden, Germany and Australia ask for?

Four countries, four answers. The US leaves the choice to programmes, Sweden sets a floor, Germany a ceiling, and Australia hands out its rules as a file.

Which issue will your contract ask for?

The newest issue of S1000D is Issue 7, released by the S1000D Steering Committee in 2026. Issue 6 followed in 2024, Issue 5.0 in 2019. Contracts lag well behind. A programme keeps the issue it started with, often for many years, because moving thousands of modules to a new issue is a project of its own.

The French yard Naval Group, for example, runs around 80,000 data modules on Issue 2.3, according to a case study by its software supplier 4D Concept. For a yard, that means tools and people that can work in several issues at once: 2.3 for one customer, 4.1 or later for another, and the current issue for a new programme.

How do the business rules stack up?

Every navy adds its own business rules to the specification, and every project adds more. Sweden spells out the order in its instruction for S1000D procurement: project rules first, then FMV’s general rules, then the rules of the Defense Interest Group, then the specification itself. A lower rule must always stay within the limits of the rule above it.

The rules that a machine can check arrive as a BREX data module. Where the customer provides a BREX, the yard’s modules are validated against it, so the BREX belongs on the list of things to get before the first module is written, not after.

What makes ships different

• Volume. A ship is assembled from the equipment of hundreds of suppliers, each with its own manuals. By our estimate, one ship type comes with around 200 of them.
• Breakdown. A ship needs its own breakdown into systems, the standard numbering system of the project. Navies often bring their own, as Sweden does with MIMI.
• Variants. Ships of one class differ from hull to hull and change at every refit, so applicability matters from the start.
• Lifetime. A warship serves for decades. The documentation has to follow every replacement and every revision of a supplier manual for that long.
• Control. Much of the content is controlled technology, which limits where it may be stored and processed.

What about commercial ships?

For merchant shipping there is Shipdex, which describes itself as “the customization for the shipping community of the international S1000D specification”. It is an open protocol for exchanging technical data between equipment makers, yards and shipowners. Equipment makers have joined it over the years, among them the engine designer WinGD in 2017. A yard that builds both naval and commercial ships may meet S1000D on one side of the yard and Shipdex on the other. How the two differ is in our comparison of the four standards.

A contract checklist for yards

Before the first module, get a written answer to each of these:

1. Which issue of S1000D applies, and may it change during the programme?
2. Whose BREX applies, and in which order do the business rules stack?
3. Which breakdown of the ship is the standard numbering system based on?
4. Which types of information are in scope: descriptions, procedures, fault isolation, parts data, maintenance planning, crew information?
5. How is applicability expressed across hulls and configurations?
6. In which form must suppliers deliver their data, and who converts it if they do not?
7. What is delivered: a CSDB export, publication modules, an interactive electronic publication?
8. Which security classification and export rules apply to the content, and where may it be processed?
9. How is a module accepted: which checks, which reviewers, which records?

Where Tracium fits

Tracium reads the supplier manuals, drafts the data modules to the business rules of your project, checks every module against those rules and links every step to the page it came from. It runs on your own servers, so controlled documentation never leaves the yard.