Short answer
S1000D publications are XML-structured maintenance documents split into identified data modules; aviation publications described as ATA-style follow conventions the supplier should name and document. Both can give a machine-readable record of procedures, warnings, parts references and applicability, which suits task-structure and retrieval work for maintenance robots. They hold no motion, force or perception data, and rights often sit with the product manufacturer and its customers.
The buyer's problem
Many maintenance documents a buyer can find are PDFs: scanned pages, flattened tables, diagrams without labels. Parsing them is half the project. Structured technical publications are used in sectors such as aerospace and defense to manage documentation across product variants, and structure that helps authors can also help models.
If your humanoid is meant to work around aircraft, vehicles or other long-lived equipment, structured publications can be among the most precise written descriptions of the maintenance task available. The questions are what the format actually gives you, who may license it, and what still has to come from somewhere else. For the general document picture, see service manuals for embodied AI.
What the formats are
S1000D is an XML-based specification for producing and managing technical publications. Its content is organized into data modules, which are stand-alone units of descriptive, procedural or operational data held in a common source database (CSDB) and identified by a unique data module code. It is used for civil and military products and belongs to the S-Series family of integrated logistics support specifications (S1000D Steering Committee, ASD).
"ATA-style" is used here for aviation maintenance publications that a supplier describes as following ATA conventions or data specifications. This page does not rely on a verified source for the content of those specifications, so it makes no claim about their structure. Ask each supplier which specification and issue their data follows, and request the documentation that defines it, rather than assuming.
In S1000D, data modules hold descriptive, procedural or operational content, so a delivery can separate system descriptions from task steps; check on a sample which other content types, such as fault-isolation or parts data, the supplier's extract includes. Airline task cards are a related document type; see aviation MRO task cards.
What structured publications can and cannot support
| Use | Fit | Why |
|---|---|---|
| Procedure step extraction | Strong, if tagged | Check on a sample that steps, warnings and cautions are tagged elements, not prose |
| Retrieval over maintenance knowledge | Strong | S1000D's unique data module codes can serve as stable citations |
| Applicability reasoning (this unit, this configuration) | Medium to strong | Only if the supplier's data records applicability and retains it in the extract |
| Linking steps to parts and tools | Medium | Needs the parts and tools data modules, plus catalog IDs |
| Reading diagrams | Weak without work | Illustrations are separate graphics; see schematics and wiring diagrams |
| Physical control, grasp, force | None | Text and graphics only |
The distinction in what SOPs can and cannot teach a humanoid holds here without change: structure improves what a model can read, not what it can do.
Who holds the data and the rights
Rights are the sharpest feature of this data. Typical holders are:
- The manufacturer (OEM), which typically authors the publication and may assert copyright over it.
- Operators and maintenance organizations, who receive publications under customer agreements that may limit use to maintaining the product.
- Authorized dealers and service centers, whose access is governed by dealer agreements.
- Documentation service providers, who may hold authoring tools and templates but not the content.
A document that an operator can read is not necessarily one the operator can license for model training. Customer agreements and export-control markings on defense-related material can limit onward use. These are diligence questions for each supplier, not conclusions; this is not legal advice. For routes that start at the manufacturer, see OEM service documentation access.
Illustrative package: a structured procedure extract
# Illustrative only - identifiers and values are synthetic, not an available dataset
package: structured_pubs_extract_v0
source: one documentation team, one product family, extract of procedural modules
files:
modules: XML, one file per data module
graphics: SVG or raster, referenced by module
metadata: [module_code, issue_number, applicability, language, effective_date]
derived_fields:
steps: [step_id, action, object, warning_ref, tool_ref]
parts_refs: catalog part numbers per step
warnings: [warning_id, severity_class, text]
excluded: export-controlled modules, customer-specific modules, any media of technicians
rights: license for training and evaluation, scope limited to named modules, no redistribution
Ask whether the extract includes the schema or business rules used to author it. Without them, validation of delivered files is harder.
Limitations and additional preparation
Structured does not mean clean. A delivery may include older issues kept for older configurations, so a model trained on the whole set can learn procedures that no longer apply; ask how superseded content is marked. Modules can reference other modules by code, so a single step may require resolving several files. Illustrations and tables may be embedded as images.
Expect to build a parser for the supplier's specification issue, resolve cross-references, convert graphics, and decide how to treat superseded issues. Hold out evaluation material by product, issue and supplier so that you test transfer rather than memory. A buyer needing manipulation behavior must pair this text with robot, teleoperation or instrumented capture, such as hand tool use demonstrations.
Dataset documentation practice helps here: ask the supplier for something like a datasheet describing composition, collection process and recommended uses, as proposed in Datasheets for Datasets.
Quality and acceptance criteria
Because the format is formal, quality can be tested mechanically. Request a sample and run these checks before agreeing to a full delivery.
- Schema validity. Every file validates against the specification issue the supplier names. Files that fail validation point to ad hoc edits or mixed issues.
- Reference resolution. Cross-references between modules resolve inside the delivered set. A high share of dangling references means the extract was cut out of a larger database without its dependencies.
- Applicability coverage. Each procedure states which configurations it applies to, and your sample includes at least two variants of one product so that you can see how applicability changes steps.
- Warning integrity. Warnings and cautions remain attached to the steps they govern. When extraction flattens them into a separate list, the safety link is lost.
- Graphic linkage. Each referenced illustration exists and opens, and callouts in the graphic match the identifiers in the text.
- Language and terminology. Controlled vocabulary is consistent, which helps retrieval, or the supplier documents known deviations.
Hold the evaluation material back by product and by issue, and keep a record of which modules appeared in which split.
For the parts side of the same publications, see exploded views and parts catalogs.
Questions to ask suppliers
- Which specification and issue does the data follow, and was it exported from a CSDB?
- Which product families and variants are covered, and over what date range?
- Does the extract include applicability data and superseded issues?
- Who authored the content, and does any of it come from third-party suppliers or subcontractors?
- Which contract terms with the manufacturer or customer govern use of the publications?
- Are any modules export-controlled, proprietary to a customer, or marked with distribution limits?
- Can graphics be delivered in an editable or vector form with their identifiers?
- Can the supplier provide the module-code scheme and cross-reference map?
- Which team can approve a license, and is the manufacturer's consent required?
Discuss your requirements
If you are evaluating structured technical publications as procedure data, describe the product families, formats and permitted uses to SourceX. SourceX looks for US businesses that hold suitable material, checks the data and the supplier's licensing permissions, and coordinates the license and delivery. A request does not guarantee a match; SourceX follows up about potential sources. For orientation, read the maintenance data hub or the humanoid training data guide, and see the catalog entry for internal documentation.
Explore sourcing and licensing options with SourceX
Sources
- S1000D International specification for technical publications using a common source database — XML specification, data modules and CSDB.
- Datasheets for Datasets — dataset documentation practice.