S1000D Issue 7:
what changed.

What is S1000D Issue 7?

Issue 7 is the newest issue of S1000D, the international specification for technical publications. The S1000D Steering Committee released it in 2026, under the S1000D Council. Its data dictionary is dated 16 July 2026, and like every issue it can be downloaded free of charge.

The name follows the numbering the Steering Committee set out in 2022: public issues no longer carry minor numbers. Issue 6 was followed by Issue 7, not 6.1, and a patch gets a letter, such as 6.A.

What changed in Issue 7?

The official announcement sums up the changes in one paragraph. In plain words:

• Updates to the standard numbering system, the breakdown of a product into systems, subsystems and units that every data module code carries.
• Updates to the XML schemas, which define what a valid data module of each type is. Issue 7 modules point to schemas under S1000D_7.
• Updates to the data dictionary, the list of every element and attribute with its meaning.
• Updates to the default BREX, the business rules every project inherits.
• Corrections for business rules and for the process data module.
• Changes for common information repositories, the modules that hold parts, tools, supplies and warnings once for a whole project.
• Enhancements to the metadata file of information control numbers, the codes that identify every illustration and multimedia object.
• Some editorial changes.

That is all the announcement says. The details are in the specification itself. One part of them can be checked line by line without it: the default BREX.

What the default BREX shows

Every issue comes with a default BREX, the data module with the business rules that apply to every project. For Issue 7 it is DMC-S1000D-J-04-10-0301-00A-022A-D, dated 16 July 2026. We compared it rule by rule with the default BREX of Issue 6, using the copies bundled with the open-source s1kd-tools. It holds 274 structure rules, five more than Issue 6, and it names the six change proposals behind its changes:

The last row is the most instructive. Rule BREX-S1-00032 says that a published module with change marks must be flagged as changed. In the default BREX of Issues 4.1, 4.2, 5.0 and 6, its path looked for an attribute called inwork. The attribute is inWork, and XPath is case-sensitive, so the rule never matched anything and never reported an error. Issue 7 corrects the spelling. What that teaches about business rules is in what the BREX checks, and what it cannot.

Who supports Issue 7 so far?

A new issue is only usable once the tools can read, check and publish it and the customer accepts it. This is what the public pages of tools and customers said in October 2026:

Some vendors do not name issues at all. RWS, for example, describes its Contenta S1000D CSDB as supporting “multiple S1000D Issues simultaneously”. Ask your vendor which issues, in which version and from when.

Why most programmes will not move yet

• The contract fixes the issue, usually for the life of the programme. NAVSEA’s acquisition guide advises confirming that the government’s and the vendors’ tools can support an issue before choosing it.
• Customers move slowly. The Bundeswehr approves Issues 1.9 and 2.3, Sweden’s FMV requires 4.1, and civil aviation’s business rules stop at Issue 6.
• The tools come first. The CSDB, the editor, the checker, the publisher and the viewer all have to support an issue before a module can pass through them.
• The rules have to move too. Every BREX in the chain, from the customer’s to the project’s, is written against the schemas and the default BREX of one issue.
• Moving thousands of modules is a project of its own, with its own checks and its own budget.

Should you move to Issue 7?

Seven questions decide it:

1. Does the contract ask for Issue 7, or allow it?
2. Do your CSDB, editor, checker, publisher and viewer support it, in which version and from when?
3. Is your customer’s BREX available for Issue 7, and the national or organisational one above it?
4. Do your suppliers and partners exchange data with you in the same issue?
5. In civil aviation: does Spec 1000BR cover Issue 7 yet?
6. Does anything in Issue 7 solve a problem you have today, with checklists or with illustrations that trace a flow, for example?
7. What would it cost to move the modules you have, and is it cheaper to leave them on their issue?

For a running programme, the answer is usually to stay. For a new programme whose customer leaves the choice open, ask for the newest issue that your tools and your customer’s tools can handle.

How to move a project to a new issue

1. Freeze a baseline: the last set of modules that passed every check on the old issue.
2. Rewrite the business rules and the project BREX for the new issue, starting from its default BREX.
3. Convert the modules: the schema references, then every element, attribute and value that changed. Much of it can be scripted, with XSLT for example.
4. Validate every module against the new schemas and the new BREX, and fix what fails.
5. Check the output: the publications, the interactive publication and the viewer.
6. Agree with the customer how modules on the old issue are delivered while the change runs.

What is not public yet

Some things we looked for and did not find: an exact release date, the number of change proposals in Issue 7, a list of changes at the level of elements and attributes outside the specification itself, and official guidance for moving from Issue 6. We will update this article as more becomes public.

Where Tracium fits

Whatever issue a contract names, the work stays the same: supplier manuals have to become data modules that pass the project’s rules. Tracium reads the manuals, drafts the modules, checks them against S1000D and your business rules and links every step to the page it came from, on your own servers.