Short answer
Diagnostic reasoning traces record how a technician moves from a symptom to a fault: what was observed, which hypotheses were considered, which checks were run and what each result changed. Existing records capture only fragments of this. A full trace usually requires a commissioned think-aloud recording, then consent checks, redaction of customer premises and step-level labeling before it can train or evaluate a model.
Why recorded reasoning is a different asset from a fault tree
A published fault tree says what a manufacturer expects a technician to do. A reasoning trace shows what a particular technician did: the first look at the machine, the guess that turned out wrong, the check that was skipped because of experience, and the point at which the plan changed. That difference matters for robots that must decide what to inspect next rather than follow a script. For the documentation side, see troubleshooting guides and fault trees.
Buyers rarely get this material ready-made. Most of it exists as scattered traces in work orders, chat threads, phone calls and in the heads of senior technicians. This guide covers where recorded reasoning lives, how to ask for it and what you will have to build around it. It sits inside the wider maintenance data cluster and the humanoid data guide.
Where diagnostic reasoning is actually recorded
| Source | What reasoning it holds | Typical weakness |
|---|---|---|
| Work-order notes | Symptom, cause and fix in a few lines; sometimes the checks run | Final answer only; intermediate hypotheses dropped |
| Ticket or chat threads between technician and dispatcher | Questions asked, readings reported, advice given | Unstructured, informal, mixed with scheduling |
| Remote-assistance sessions | Spoken explanation while a camera shows the equipment | Framing varies; audio may include customer speech |
| Escalation and post-repair reviews | Why a first attempt failed | Rare, written after the fact |
| First-person repair footage with expert narration | Observations and decisions tied to what the hands do | Inconsistent framing, incomplete steps, no force data |
| Technician interviews and think-aloud sessions | Explicit hypotheses and rationale | Must be commissioned; narration can differ from real behavior |
Field service organizations are the usual holders. Their strongest material is usually text, and any video tends to be incidental. Footage from technician body cameras can carry narration, but it was recorded to document a job, not to expose reasoning.
What published text resources show
Two published resources show the text end of this asset. TechQA assembled technical-support questions from IBM forums, each with an accepted answer drawn from a company technote, and released 600 training, 310 development and 490 evaluation question-answer pairs alongside a corpus of 801,998 technotes (Castelli et al., 2019). It is software support rather than physical repair, but it shows the shape: a described problem, a long document collection and a vetted resolution.
MaintNet provides logbook data from aviation, automotive and facilities domains, together with abbreviation lists, termbanks and pre-processing tools (Akhbardeh et al., 2020). Its value here is a reminder that technician text is compressed and jargon-heavy, and needs normalization before reasoning can be read out of it. See work-order histories for the symptom, diagnosis, parts and fix structure.
Neither resource contains multi-step reasoning with observations from a physical machine. That gap is what a buyer must fill.
What this data cannot support
- Physical skill. A trace of reasoning says what to check, not how a hand reaches a fuse panel or how hard to press a probe.
- Control data. There are no joint states, actions or forces. A humanoid needs robot-specific observations to act on a diagnosis.
- Honest hypotheses. Technicians who know they are recorded tend to narrate tidy logic. Think-aloud commentary can differ from the shortcuts used on a real call.
- Coverage of rare faults. Common faults dominate any archive. Difficult cases are scarce; see difficult and failed repairs.
- Transfer across equipment. Reasoning for one model of equipment may not hold for another; check how much of it is equipment-specific.
Text and narrated video can support diagnosis planning, question answering, next-check prediction, step segmentation and evaluation. They should not be presented as training material for physical control.
Illustrative trace schema
# Illustrative only - synthetic values, not an available dataset
trace_id: trace_0042
equipment: {class: packaging_line_conveyor, model_ref: model_B7, asset_id: asset_0193}
reported_symptom: "belt stops after 2 minutes, no alarm"
steps:
- step: 1
observation: "motor warm, drive display blank"
hypothesis: "loss of control power"
action: "check upstream breaker label and position"
result: "breaker closed"
hypothesis_status: not_resolved
- step: 2
observation: "24V supply LED off"
hypothesis: "failed supply module"
action: "measure supply output"
result: "0 V"
hypothesis_status: confirmed
resolution: {fix_code: replace_psu, first_time_fix: true}
evidence: {video_segment: seg_0042_a, narration: true, transcript_ref: tr_0042}
labeler: {annotator_id: ann_07, review: second_pass}
Use fields like these as a starting point and adapt them to your architecture. A planning model may need only observation, hypothesis and next check. A multimodal model that grounds each step in video needs time stamps, camera metadata and a stable segmentation scheme.
Existing records or commissioned recording
Existing records are cheaper and show real jobs, but rarely include intermediate reasoning. Commissioned think-aloud sessions can be designed to expose every step, at the cost of time, technician availability and a recording that is slightly artificial. Many buyers combine the two: mine work-order text for fault frequency and phrasing, then commission a narrow set of narrated diagnoses for the faults that matter. The choice of sourcing route is easier once you know which fault classes you need.
Preparation a buyer should budget for
- Consent. Technicians and customer staff may appear or be heard. Treat consent as a design question, not a blur filter; see worker consent and identifiable people.
- Customer premises. Names, addresses, screens, badges and floor plans can sit in frame or in notes. Redaction is a step to plan, and it does not on its own settle whether the customer permitted the use.
- Segmentation and labeling. Someone must mark each observation, hypothesis, action and result, and a second reviewer should check agreement.
- Held-out evaluation. Keep a set of traces for evaluation, separated by site or technician; see troubleshooting evaluation sets.
Acceptance checks for a trace set
Buyers set the thresholds; these are the checks worth writing into an acceptance test.
- Step completeness. Sample traces and confirm each has an observation, an action and a result for every step, not only a closing cause.
- Consistency of labels. Have two reviewers label the same sample and compare agreement on hypothesis status.
- Dead ends retained. Check whether abandoned hypotheses survive in the data or were edited out as noise. Models that plan next checks need the dead ends.
- Outcome linkage. Confirm that each trace links to a repair outcome and, where available, a repeat-visit flag, so good reasoning can be told from lucky guesses.
- Provenance per trace. Each trace should name its origin (work order, call, narrated session) so you can weigh it differently.
Questions to ask suppliers
- Which fields in your records hold intermediate hypotheses or checks, as opposed to the final cause only?
- Is any footage narrated, and was the narration spoken during the job or added afterward?
- How many distinct equipment classes and fault types are covered, and how skewed is the distribution?
- How many different technicians contributed, and what experience levels do they represent?
- Do customer contracts or service agreements restrict use of notes, photos or recordings for model training?
- Who can authorize licensing of material recorded on customer premises?
- Can reasoning steps be tied to asset IDs and outcome codes, such as repeat visits?
- What redaction has been applied, and does it affect labels, readings or screens needed to follow the logic?
- Could a small set of narrated diagnoses be recorded for named fault classes, and under what consent process?
Discuss your requirements
If your project needs diagnosis data, describe the equipment classes, fault types and modalities 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. Where no existing asset fits, SourceX can scope a commissioned collection of new recordings; it can also arrange annotation and engage specialist capture partners, scoped case by case. A request does not guarantee a match, and nothing is contracted until a supplier agrees. The catalog entry for field service and maintenance records describes the related record type.
Discuss your humanoid training-data requirements with SourceX
Sources
- The TechQA Dataset — Published technical-support QA set pairing questions with accepted answers, an example of problem-to-resolution text.
- MaintNet: A Collaborative Open-Source Library for Predictive Maintenance Language Resources — Published maintenance logbook language resource showing the abbreviation-heavy shape of technician text.