Short answer
Documentation teams that author in DITA or another component content system already hold procedures as typed XML: task topics that typically separate prerequisites, numbered steps, expected results and conditions. An export reduces parsing work because steps are explicit elements, not paragraphs. It still gives only task structure and language, needs rights review for reused and third-party content, and carries no motion, force or perception data.
The buyer's problem
Turning PDFs and Word files into ordered steps costs effort and introduces errors: a step number is mistaken for a quantity, a note is attached to the wrong action, a table breaks across pages. Buyers building procedure corpora for planning or evaluation ask whether any suppliers already hold the structure.
Technical documentation groups do. Many author in a structured, topic-based format and store content as components in a component content management system (CCMS). The published PDF is a build product; the source is typed content. For the broader decision between sources, see procedure step schema, which defines the target, and the SOPs and procedural data hub for the cluster.
What a DITA export contains
The OASIS DITA Technical Committee defines and maintains DITA, which provides topic-oriented document types and specialization mechanisms; the task topic is specialized from the generic topic, with general and strict task variants (OASIS DITA TC). In practice a task topic holds procedure content in named elements. As examples to confirm against the current DITA specification, rather than as cited facts, task markup in common use includes elements for a short description, prerequisites, context, a list of steps in which each step carries a command, optional information and a step result, then an overall result and a post-requirement. Exact element sets depend on the DITA version and on the organization's specialization, so verify against the current specification and the supplier's DTD or schema before costing a mapping.
Around the topics sit:
- Maps. Files that assemble topics into a manual, define order and nest sections.
- Conditional attributes. Tags that filter content by product, audience, region or release.
- Reuse references. Elements that pull in shared steps, warnings or phrases from other components.
- Metadata. Authors, review states, versions, keys that resolve product names and part numbers.
- Media references. Links to images, which may be held as separate assets.
- Localization units. Translated variants of the same component, which matter for multilingual SOP corpora.
Other structured standards serve regulated sectors. S1000D, for instance, defines data modules as stand-alone units of descriptive, procedural or operational data stored in a common source database and identified by a unique data module code (S1000D). The mapping approach is similar: a typed element per concept, a stable identifier per unit.
What this data can support, and what it cannot
Structured exports can support:
- Procedure corpora with explicit steps. No layout parsing is needed, which avoids the extraction errors that document-layout benchmarks exist to address.
- Typed fields. Prerequisites, results and warnings arrive as separate elements, easing precondition and postcondition modeling.
- Variant-aware evaluation. Conditional attributes enable questions such as "how does this step differ for model B".
- Controlled language. Technical authors often follow style rules, which suits controlled-language procedures.
- Change tracking. Component versions provide a revision trail, related to SOP revision histories.
They cannot support:
- Physical control or perception. An XML step element contains words and perhaps a figure reference.
- Proof of practice. Documentation describes the intended method; field staff may do otherwise.
- Unconditioned reading. Resolving conditional text and reuse requires the build rules. A raw export may contain content for every variant at once, with no indication which applies.
- Completeness of the task. Product documentation covers the designed method, usually the happy path, with limited recovery coverage.
Raw source versus resolved output
Buyers should specify which form they want. The two differ materially.
| Form | What it contains | Advantage | Risk |
|---|---|---|---|
| Source topics and maps | Typed XML with conditions and reuse links | Full structure, stable IDs | Needs the build chain to be readable |
| Resolved output (conditions applied, reuse expanded) | One variant's text | Directly usable | Loses variant information; one export per variant |
| Rendered PDF or HTML | Presentation | Easy to inspect | Loses the structure that justified the export |
| Both source and resolved | Pair per variant | Best traceability | More volume and rights scope |
Asking for source plus one resolved output per variant is a common compromise. Request the schema and build configuration so you can reproduce the resolution.
Illustrative export manifest
# Illustrative - synthetic identifiers
export: doc_export_v0
format: DITA_XML
version_note: "supplier to state DITA version and specialization"
content:
topics: {task: "n_task", concept: "n_concept", reference: "n_ref"}
maps: "n_maps"
media: {images: "n_images", licensed_with_text: true}
languages: [en, de]
conditions:
attributes: [product, audience, release]
resolved_variants_included: [product_A, product_B]
reuse:
shared_components: true
resolution_rules_delivered: true
metadata:
topic_ids_stable: true
revision_history: last_5_versions
rights:
authored_by: in_house_writers
third_party_inclusions: [vendor_warnings]
excluded: [customer_specific_topics]
redaction:
removed: [personal_names, unreleased_product_codes]
Quality checks before licensing
- Well-formedness and validation. Do files validate against the declared schema? Broken exports waste preparation time.
- Step integrity. Sample tasks and check that each step's command element (as named in the supplier's schema) contains one action, or document how multi-action steps appear.
- Reuse resolution. Pick a step that is reused and confirm every instance can be traced.
- Condition coverage. For a product with variants, check that the resolved outputs differ where they should.
- Figure linkage. Check that image references resolve to delivered files; broken links are common in exports.
- Duplicate and boilerplate rate. Heavily reused text inflates apparent volume; count unique steps, not topics.
Limitations and additional preparation
- Documentation of products, not operations. Many CCMS holdings are product manuals rather than a site's own SOPs; see product user guides as instruction data.
- Tooling needed. Reading DITA with conditions and keys needs processing software; budget for a build step.
- Granularity. Writers split steps for readability, not for robot execution; steps may still need rewriting, covered by rewriting human procedures for robots.
- Illustrations. Figures may be line art with callouts; illustrated assembly manuals discusses what such images can teach.
- Small topic counts. A strong documentation team can still hold a modest number of procedures relevant to physical tasks.
- Platform lock-in. Some CCMS vendors restrict bulk export; terms matter.
Permissions and provenance
Documentation is rarely wholly original. It reuses vendor warnings, standards text and licensed illustrations. The publisher may own the manual but not every paragraph in it. Ask who holds copyright in each component, whether translations were done under separate contracts, and whether the CCMS terms permit bulk export for licensing. For how copyright questions arise at different stages of AI development, see the Copyright Office's Part 3 report on generative AI training; it is background, not a ruling on your case. This is not legal advice.
Questions to ask documentation teams
- Which DITA version or other standard, and which specializations, are in use?
- Can you export source topics, maps, and resolved outputs per variant?
- Are conditional attributes and keys documented and exportable?
- What share of topics is reused, and how is reuse resolved in delivery?
- Are images included, and under what license?
- Which content comes from third parties, vendors or customers?
- Do translations have separate rights?
- How are superseded versions retained?
- Does your CCMS agreement allow bulk export for licensing?
Discuss your requirements
If you are looking for procedures that are already structured, describe the task domain, format 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. Begin with the humanoid training data guide for the full map, or read about the catalog category for internal documentation. A parallel route, with execution data, is covered in connected-worker platform exports.
Discuss your humanoid training-data requirements with SourceX
Sources
- DITA (Darwin Information Typing Architecture) - OASIS DITA Technical Committee — DITA topic types, specialization, and task topic variants (partial verification).
- S1000D International specification for technical publications using a common source database — data modules in a common source database.
- DocLayNet: A Large Human-Annotated Dataset for Document-Layout Analysis — layout parsing as a distinct step.
- Copyright and Artificial Intelligence, Part 3: Generative AI Training (pre-publication version) — background on copyright at stages of AI development.