Explainer
The S1000D Data Module Types, Toured
The Cast
Content Types Authors Live In
The working types map to what technical content actually does. Descriptive modules explain what a system is and how it works. Procedural modules carry tasks — and their schema is opinionated: preliminary requirements, the steps themselves, warnings and cautions in their proper positions, close-out requirements. You cannot write a procedure loosely, which is exactly the point. Fault isolation modules encode diagnostic logic from symptom toward cause. Crew/operator modules address operation rather than maintenance. And illustrated parts data modules carry the structured parts information behind the IPC — fed, on a well-run program, from the provisioning world of S2000M.
The most modern member is the process data module: branching logic a viewer executes— ask, answer, route — turning troubleshooting from a printed tree into a guided session. It's the clearest case of content with no faithful paper form, built for the IETP world.
The Crew Behind the Curtain
Infrastructure Modules
Behind the content types sit the modules no reader opens: the applicability tables (ACT, CCT, PCT) that make configuration filtering possible; the BREX, carrying the project's business rules as data; and common information repositories— CIRs — which centralize shared definitions of parts, tools, warnings, and terms so a thousand procedures reference one source. The CIR is S1000D's answer to the same problem enterprise publishing meets as definitions management: say it once, govern it once, reference it everywhere.
The payoff for all this typing discipline is the assembly model: a publication is a selection — modules chosen and ordered by their codes into a manual, an IPC, a troubleshooting set — all from one pool, all sharing the same repositories and rules. Programs that grasp the types build the infrastructure modules first and let the content flow into a prepared structure. Programs that don't, write eight hundred procedures and then discover what a CIR was for.
FAQ
Questions We Hear
What are the main content-carrying data module types?
The types authors live in daily: descriptive modules (what a system is and how it works), procedural modules (how to perform a task, with the preliminary requirements, steps, warnings, and close-out the schema structures explicitly), fault isolation modules (diagnostic logic from symptom to cause), crew/operator modules (operation rather than maintenance), and illustrated parts data modules (the structured parts information behind the IPC). Each has its own schema, so a procedure cannot be written loosely as a description with numbered paragraphs — the type carries obligations.
What is a process data module?
The interactive one: a module containing branching logic — questions, conditions, and next steps — that a viewer executes rather than displays. It's what turns diagnostic content from a printed logic tree into a guided session where the technician answers a question and is routed accordingly. Process modules are the clearest example of content that has no faithful paper rendition; they exist for the IETP world.
Which types are infrastructure rather than content?
The modules readers never see but programs depend on: the applicability cross-reference tables (ACT, CCT, PCT) that ground configuration filtering; the BREX module carrying the project's business rules; and common information repositories (CIRs), which centralize shared definitions — parts, tools, warnings, terms — so a thousand procedures reference one source instead of duplicating it. Weak programs treat these as afterthoughts; strong ones author them first, because everything else is built on them.
How does a real publication mix the types?
A publication module (not itself a data module) selects and orders modules from the pool by their codes: descriptions for the front matter of a system chapter, procedures for the maintenance sections, fault isolation for troubleshooting, IPD for parts — all drawing on the same CIRs and governed by the same applicability tables. That assembly-from-pool model is the whole reason the types exist: content typed precisely enough that publications become queries.
Get In Touch
Building the Pool Right?
The programs that succeed author their infrastructure modules first — BREX, applicability, CIRs — and let content flow into a prepared structure. We help you start in that order.