Short answer
Troubleshooting guides and fault trees record diagnostic logic: a symptom, the checks to run, the branches those checks open, the probable causes and the remedy for each. Service organizations, plant maintenance teams and equipment makers hold them as flowcharts, symptom-cause tables and support articles. They help a humanoid program with diagnostic reasoning and next-check planning, but they never show how a check is physically performed, and equipment makers often control the rights.
Why diagnosis is a separate asset from repair
A repair procedure says how to replace a run capacitor. A troubleshooting guide says whether to touch the capacitor at all: which symptom, which reading, which branch. For a humanoid that maintains equipment, that is the difference between executing steps and deciding which steps to execute. The decision logic can be bought and evaluated as text and diagrams, long before any robot data exists.
Three neighbors are easy to confuse with this asset. Work order histories show what technicians actually found and did; a guide shows what the author expected them to find. Service manuals hold the repair steps a guide points to. Error codes and HMI screens are the machine's own symptom reports, usually the entry point to a guide.
One terminology trap: in reliability engineering, fault tree analysis is a top-down model of how component failures combine into a system failure. In day-to-day maintenance, "fault tree" usually means a diagnostic decision tree. Failure modes and effects analysis, which IEC 60812 describes as planned, performed, documented and maintained for hardware, software and processes (IEC, 2018), is a third kind of record, a structured analysis of how things can fail and with what effect. Ask a supplier which one it means, because each supports a different model.
Formats you will be offered
| Format | What it contains | Typical holder | Preparation needed |
|---|---|---|---|
| Decision-tree flowchart | Yes/no or reading-based branches ending in a cause and remedy | Equipment makers, service firms | Extract nodes and edges from images or PDFs |
| Symptom-cause-remedy table | Rows of symptom, ranked causes, corrective action | Manuals, field guides | Split merged cells; keep rank order |
| Support article | Problem statement, environment, resolution text | Manufacturer support sites, service desks | Separate symptom, steps and resolution |
| Error-code lookup | Code, meaning, first checks | Equipment makers | Join to the guide the code points to |
| Technician cheat sheet | Informal checks learned on the job | Service organizations, plant teams | Normalize shorthand; confirm authorship |
| Structured publication module | Troubleshooting content stored as discrete, coded units | Producers using a common source database | Export with identifiers intact |
Structured publishing helps buyers. S1000D, for example, organizes publications into data modules, each a stand-alone unit of descriptive, procedural or operational data identified by a unique code (S1000D Steering Committee); a supplier that publishes this way can often export content in units a model can index. Most guides, though, arrive as PDF flowcharts. Document-layout research shows why that costs effort: DocLayNet comprises 80,863 manually annotated pages with 11 layout classes across six document categories, manuals among them (Pfitzmann et al., 2022), a measure of how much structure has to be recovered from a page. Plan for extraction and review, and see validating LLM-extracted procedure steps before trusting an automated conversion.
What public work shows about the shape of this data
TechQA is the closest public reference. It pairs technical-support questions with answers found in a companion corpus of 801,998 support documents, and ships 600 training, 310 dev and 490 evaluation question-answer pairs, built to test domain adaptation (Castelli et al., 2019). Its questions come from developer forums, not physical-equipment service, so read it as a model of the format: a symptom-style question, a document that resolves it and a small, carefully held-out evaluation split.
Maintenance text has its own noise. MaintNet released logbook data from aviation, automotive and facilities domains together with abbreviation lists, termbanks and preprocessing tools (Akhbardeh et al., 2020), a signal that technician-written guides will also need normalization.
What troubleshooting data can and cannot support
| Can support | Cannot support |
|---|---|
| Diagnostic question answering and retrieval over equipment documentation | Performing a check: probe placement, listening, feel, access |
| Choosing the next check given what is known so far | The real frequency of each cause; guides rank causes by the author's assumptions |
| Evaluation items built from branches, held out by equipment model | Recognizing a fault visually, without images |
| Linking a symptom to the repair procedure that fixes it | Any robot motion, force or contact data |
| Structuring cause codes in work-order data | Judging safety conditions on site without hazard data |
A guide that says "measure supply voltage at terminal 4" assumes a technician who can open the panel, choose an instrument, place probes safely and read the result. Those skills sit in measuring instrument use and in video, not in the tree. Treat the tree as the planner's knowledge and the demonstrations as the executor's.
Illustrative node schema
{
"_note": "Illustrative only: synthetic excerpt; nodes n4 and n6 omitted, ids and values are examples",
"tree_id": "TS-0412",
"equipment_class": "rooftop_hvac_unit",
"model_scope": ["model_family_C", "rev >= 3"],
"authority": "service_org_authored",
"source_revision": "2024-03",
"nodes": [
{"id": "n1", "type": "symptom", "text": "Unit runs, supply air warm", "next": "n2"},
{"id": "n2", "type": "check", "text": "Compressor contactor energized?",
"method_ref": "PROC-CHK-017", "expected": {"yes": "n3", "no": "n6"}},
{"id": "n3", "type": "check", "text": "Run capacitor within rated range?",
"method_ref": "PROC-CHK-021", "expected": {"yes": "n4", "no": "n5"}},
{"id": "n5", "type": "cause", "text": "Failed run capacitor",
"remedy_ref": "PROC-REP-044", "safety_ref": "LOTO-HVAC-02"}
],
"observed_outcomes": {"linked_work_orders": "<count>", "resolved_at_leaf": {"n5": "<share>"}}
}
The last field is what separates a useful delivery from a diagram dump: leaf outcomes joined to real jobs. A supplier that can link nodes to first-time-fix and callback labels gives a model something to calibrate against.
Who holds troubleshooting content
| Supplier type | What they may hold | Watch for |
|---|---|---|
| Equipment makers and their support desks | Authoritative guides, error-code tables, support articles | They usually control rights; see OEM service documentation access |
| Field service organizations | Internal knowledge bases, escalation guides, technician notes | Text copied or adapted from maker manuals |
| In-house plant and facilities teams | Site-specific fault guides for installed equipment | Confidential process details; thin documentation |
| Fleet and MRO operations | Diagnostic trees for vehicles or aircraft systems, task-card troubleshooting | Regulatory and contractual limits |
Service organizations and in-house teams may own part of what they hold. The diligence question is how much.
Quality and acceptance criteria
- Scope. Each tree states the equipment class, model family and revision range it covers.
- Dating. Revision dates exist; superseded guides are marked.
- Executable branches. Every check names a method, an instrument where relevant and an expected result with units or thresholds.
- Closure. No dangling nodes; every leaf has a remedy and a procedure reference.
- Safety flags. Steps needing lockout or isolation reference the safety procedure, per lockout/tagout procedures as data.
- Outcome linkage. Some sample of leaves is joined to real work-order outcomes, with the sample size reported.
- Extraction check. If trees were converted from images, a double-checked sample shows node and edge accuracy.
- Evaluation split. Held-out trees are separated by equipment model, so a test does not repeat a training tree with a renamed unit. The split logic is covered in troubleshooting evaluation sets.
Limitations and additional preparation
Guides are idealized. They cover the faults the author anticipated, in the order the author expected, and field technicians may depart from them; diagnostic reasoning traces capture how they actually reason. Branches that depend on sound, smell, vibration or heat describe a sensation but carry no sensor data. Equivalent equipment from different makers may use different symptom vocabularies, so plan a shared symptom and cause code list. For decision points inside ordinary procedures, see branching procedures and decision points.
Questions to ask suppliers
- Who wrote each guide, and were any sections taken or adapted from equipment makers' manuals?
- Which equipment classes, models and revisions does the set cover, and how are superseded versions handled?
- In what format do the trees exist: images, PDFs, structured modules or a database?
- Do branch checks give methods and expected values, or only prose?
- Can leaves be linked to work orders, and how many are linked?
- Are error codes and symptom wording consistent across equipment types?
- Do the guides include safety and isolation steps, and who maintains them?
- Which parts of the set can you license, and which require the equipment maker's permission?
Permissions and provenance
Troubleshooting text is authored work. Equipment makers typically hold copyright in their guides, and service agreements or dealer terms may restrict what a repair business can do with copies. The U.S. Copyright Office's report on generative AI training identifies points in model development where copying may implicate rights and examines licensing options (U.S. Copyright Office, 2025), which is a reason to ask early rather than assume. A rewrite by a technician may still derive from the original. Ownership questions for procedures generally are covered in who owns a procedure. This is not legal advice.
Discuss your requirements
If you need diagnostic content for a particular equipment class, describe the equipment, formats and permitted uses to SourceX. SourceX looks for US businesses that hold suitable guides and records, checks the data and the supplier's licensing permissions, and coordinates the license and delivery. It reviews the requirement and follows up about potential sources; a request does not guarantee a match, and nothing is contracted until a supplier agrees.
The maintenance, repair and tool-use hub and the humanoid training data guide show how this asset fits with records and demonstrations. The catalog pages on licensing maintenance logs and knowledge base articles describe related record types.
Explore sourcing and licensing options with SourceX
Sources
- The TechQA Dataset — support question-answer pairs and a companion document corpus.
- MaintNet: A Collaborative Open-Source Library for Predictive Maintenance Language Resources — normalization resources for maintenance text.
- DocLayNet: A Large Human-Annotated Dataset for Document-Layout Analysis — layout analysis across document categories including manuals.
- S1000D International specification for technical publications using a common source database — data modules as units of technical content.
- IEC 60812:2018 Failure modes and effects analysis (FMEA and FMECA) — FMEA as a structured analysis of failure modes and effects.
- Copyright and Artificial Intelligence, Part 3: Generative AI Training (pre-publication version) — rights points and licensing options in AI training.