Skip to content

Field service and maintenance work order datasets for AI training

A maintenance work order dataset is a record of real repair and upkeep jobs on equipment: the reported symptom, the technician's diagnosis, the parts used, the fix and whether it held, usually with technician notes, photos and the asset's service history. SourceX sources these records from field service companies, equipment dealers and asset-intensive operators running maintenance and field service systems such as IBM Maximo or ServiceTitan. Each dataset is licensed for an agreed permitted use, with customer sites and technicians pseudonymized.

Dataset manifest

Sourced to your spec
What it is
Work orders tracing symptom, diagnosis, parts and fix, with asset histories and photos
Typical systems
IBM Maximo, SAP Plant Maintenance, ServiceTitan, Salesforce Field Service, IFS, eMaint
Typical history
Operations logs spanning years; varies by partner
Modality
Structured work orders and parts records, technician notes and job photos
Delivery formats
Agreed per order; Parquet or JSONL work orders linked to assets, photos separate
Preparation
Customers, sites, technicians and serial numbers pseudonymized; photos reviewed for faces and addresses
Licensing
Permitted use agreed per order; third-party manuals and customer data restricted
Availability
Sourced to your spec from service companies and operators; not guaranteed

What a delivery contains

Fields vary by source system and are fixed per order. A typical delivery includes:

FieldTypeWhat it holds
work_order_idstringPseudonymous work order key, linking visits, notes, parts, photos and the asset.
assetobjectEquipment class, manufacturer and model family, age band, operating context and a pseudonymous serial, linked to its full service history.
requestobjectHow the job arrived — customer call, sensor alarm, inspection finding or preventive maintenance schedule — with the symptom as first reported.
classificationobjectPriority, work type such as corrective, preventive, emergency or warranty, and the problem code assigned at intake.
visitsarrayEach technician visit with skill level, travel and on-site time, and whether the problem was fixed on that visit.
diagnosisobjectReadings and tests taken, the failure mode found and the cause and remedy codes the technician closed out with.
tech_notesarrayFree-text notes written during and after each visit, de-identified.
partsarrayParts used and returned, with a pseudonymous part number, category, quantity and whether each was a warranty claim.
photosarrayBefore and after images, nameplates and failed components, with a caption, the visit and what was redacted.
checklistsarrayInspection or preventive maintenance checklist items with recorded values and pass or fail results.
resolutionobjectCompletion status, fix confirmation and any customer sign-off details that survive de-identification.
follow_upobjectCallbacks or repeat failures on the same asset within an agreed window, linked to the work orders that followed.
referencesarrayManual sections, service bulletins or internal knowledge articles cited on the job, as references rather than the documents themselves.

Example record

{
  "work_order_id": "wo_5d2e81",
  "asset": { "id": "ast_07c3", "class": "packaged_rooftop_unit", "manufacturer": "[OEM_A]",
             "model_family": "rtu_5t_gas_electric_1ph", "age_band": "8-12y", "site_type": "retail" },
  "request": { "t": "2024-07-15T14:22:00-05:00", "channel": "customer_call",
               "reported_symptom": "Store is warm, unit running but not cooling." },
  "classification": { "priority": "high", "work_type": "corrective", "intake_problem_code": "no_cooling" },
  "visits": [
    { "visit": 1, "tech": "tech_31", "skill": "journeyman", "arrived": "2024-07-15T17:05:00-05:00",
      "on_site_min": 95, "outcome": "temporary_repair" },
    { "visit": 2, "tech": "tech_31", "skill": "journeyman", "arrived": "2024-07-16T08:10:00-05:00",
      "on_site_min": 140, "outcome": "fixed" }
  ],
  "tech_notes": [
    { "visit": 1, "text": "Comp not running. Contactor pitted, coil reads OK. Dual run cap 45/5 reads 31 uF on herm side. Swapped cap from van stock, comp starts, amps high. Ordered contactor. Advised store." },
    { "visit": 2, "text": "Replaced contactor. Amps normal. Cleaned condenser coil, heavy cottonwood. Suction 118 psig, SH 11. Unit cooling, store at 74F." }
  ],
  "diagnosis": { "failure_mode": "failed_run_capacitor", "secondary": ["pitted_contactor", "dirty_condenser_coil"],
                 "cause_code": "component_wear", "remedy_code": "replace_components_clean_coil",
                 "readings": { "cap_rated_uf": 45, "cap_measured_uf": 31, "suction_psig": 118, "superheat_f": 11 } },
  "parts": [
    { "part": "pn_tok_a71", "category": "run_capacitor", "qty": 1, "source": "van_stock" },
    { "part": "pn_tok_c09", "category": "contactor", "qty": 1, "source": "supplier_pickup" }
  ],
  "photos": [
    { "id": "img_412", "visit": 1, "caption": "unit nameplate", "redacted": ["serial_number"] },
    { "id": "img_413", "visit": 1, "caption": "pitted contactor", "redacted": [] },
    { "id": "img_418", "visit": 2, "caption": "condenser coil after cleaning", "redacted": ["storefront_signage"] }
  ],
  "resolution": { "status": "completed", "first_time_fix": false, "customer_signoff": "[REDACTED]" },
  "follow_up": { "window_days": 30, "callback": false },
  "references": ["oem_manual_ref:wiring_diagram", "internal_kb:rtu_no_cool_flow_v4"]
}

Synthetic record for illustration. Field names, structure and format are agreed per order.

What AI teams use it for

Train diagnostic and troubleshooting assistants

Symptom, readings and confirmed failure mode across many jobs on the same equipment class teach a model which checks narrow a fault down, and which causes are common for a given model family and age.

Improve first-time fix and parts planning

Parts records and second-visit flags show which repairs needed parts the technician did not carry, so a model can suggest what to bring before the truck rolls.

Structure technician notes into fault codes

Shorthand notes paired with the cause and remedy codes closed on the same job provide labeled training data for extraction and auto-coding, and expose where the codes and the notes disagree.

Ground maintenance models in asset histories

Years of work orders on individual assets, including repeat failures, give event histories for failure prediction and maintenance scheduling models, alongside sensor data where a partner holds it.

Define task lists for embodied AI

Work orders describe what technicians actually do on site, step by step and with outcomes, which helps choose tasks for robot learning or first-person video collection.

Use-case guides: Robotics and embodied AI, Enterprise and computer-use agents

What makes this data valuable

Confirmed fixes

A callback window shows whether the repair held, not just that the job was closed.

Asset continuity

A stable asset ID ties every visit on a machine together, so repeat failures become visible.

Measured readings

Pressures, voltages, temperatures and test results give a diagnosis evidence beyond the note.

Parts as ground truth

The part actually replaced is a harder label than the problem code picked at intake.

Notes and photos together

Images of nameplates and failed components anchor the technician's written account.

Equipment breadth

Several manufacturers, model families and equipment ages separate general failure patterns from one fleet's quirks.

What manuals and sensor benchmarks leave out

Public maintenance data is mostly sensor benchmarks from test rigs or simulations, and equipment manuals that describe how a machine should behave. Neither shows how equipment fails in service or how technicians actually find the fault. Manuals list possible causes. Work orders show which causes turned up, on which model families and at what age, how often the first diagnosis was wrong and what the technician checked before getting it right.

The unit that carries this knowledge is the asset history rather than the single job. A compressor replaced twice in three years, a unit that needs a callback every summer, a fleet model whose same component keeps failing: these patterns exist only when years of work orders stay linked to the same piece of equipment. They are what separates a model that repeats the manual from one that reasons like an experienced technician.

Reading work orders correctly

  • Preventive work swamps corrective work. Scheduled inspections can make up much of the volume and mostly record that nothing was wrong. Filter by work type, or a diagnostic model will learn mainly that equipment is fine.
  • Notes are written fast and in shorthand. Abbreviations, trade slang, units without labels and misspelled part names are normal, and conventions differ by trade and region. Ask for the partner's abbreviation conventions where they exist, and expect normalization work.
  • Codes are filled in after the fact. Cause and remedy codes are often chosen at close-out or by office staff, and can disagree with the note. Treat parts and readings as the primary evidence.
  • One visit is not one fix. Jobs that span several visits, return trips for parts and warranty recalls show up as separate records in some systems and as one in others. Agree how visits roll up to a repair event.
  • Fleets age together. A single operator's equipment tends to share manufacturers, ages and operating conditions. Combining partners exposes failure modes one fleet never shows.

What to check before licensing

  • Establish who owns the records. A service contractor working in a customer's facility may keep work orders in its own system or in the customer's maintenance system, and service contracts, especially for government, defense, healthcare and critical-infrastructure sites, can restrict how service data is used.
  • Identify third-party intellectual property in the files. Manufacturer service manuals, wiring diagrams, schematics and bulletins are usually the manufacturer's copyright, so the data should reference them rather than include them, unless the manufacturer allows it.
  • Ask whether manufacturer diagnostic software or connected-equipment portals supplied any fault codes or readings, and whether their terms allow those outputs to be licensed.
  • Review photo redaction on a sample, including technicians' and occupants' faces, street addresses, signage, license plates, serial-number plates, screens and paperwork in frame.
  • Treat technician pseudonymization as essential. Repeat-visit and first-time-fix data reflect on individual workers, and in some jurisdictions employee notice or works council consultation may be needed before such data is shared.
  • [object Object]
  • Confirm that asset IDs survived system migrations and equipment replacements, or repeat-failure and asset-life labels will be broken.
  • Compare the mix of equipment classes, manufacturers, work types and customer sectors with the distribution you are targeting.

How licensing works through SourceX

  1. 1

    Define

    Send the domain, modality, volume, format, timeline and permitted use you need.

  2. 2

    Source

    SourceX identifies businesses that hold matching data and are open to licensing it.

  3. 3

    Qualify

    Fit, rights and quality are checked, and you review samples before committing.

  4. 4

    License

    Scope, permitted use, exclusivity, price and obligations are agreed in writing.

  5. 5

    Deliver

    Approved data is prepared, de-identified where required and transferred securely.

Questions buyers ask

Can I license real maintenance work orders for AI training?

Usually, yes. Service contractors, equipment dealers and operators of large asset fleets keep years of work orders in their maintenance and field service systems, and can license them when their customer contracts allow it. SourceX reviews who owns the records and what those contracts say, then pseudonymizes sites, customers and technicians before delivery. Coverage of particular equipment types depends on which partners agree to license.

Which kinds of equipment do these datasets cover?

Coverage follows what partners maintain, most often heating, ventilation and air conditioning, refrigeration, elevators and escalators, commercial kitchen equipment, generators and electrical systems, industrial machinery, fleet vehicles, and medical or laboratory equipment. Utilities and facilities teams add pumps, valves and building systems. Name the equipment classes, manufacturers and work types you need, because coverage varies widely between partners.

Are manufacturer service manuals included?

Usually not. Service manuals, wiring diagrams, parts catalogs and service bulletins are typically the manufacturer's copyright, and the service company holds them under its own dealer or subscription terms, not a right to relicense them. Work orders that cite a manual section can be included as references, and a manufacturer can authorize its documentation separately where it agrees. Internal procedures the service company wrote itself are a different matter and can often be licensed.

Do work orders include sensor or telemetry data?

Sometimes. Operators running condition monitoring, building management systems or connected equipment may hold alarms and readings that triggered or accompanied a work order, and those can be linked by asset and time. Many repair histories contain only readings the technician recorded by hand. If continuous sensor data matters, request it explicitly, since it narrows which partners can supply and may involve manufacturer platform terms.

How are technicians and customer sites protected?

Technician names become consistent pseudonyms, so skill and repeat-visit patterns stay visible without identifying anyone. Customer names, site addresses and contact details are replaced or generalized to site type and region, and serial numbers are tokenized. Photos are reviewed for faces, addresses, signage and paperwork in frame. Notes are scrubbed for names and phone numbers, and the result is checked on the sample.

How good are problem and cause codes as labels?

Often weaker than buyers expect. Codes are picked from long menus at the end of a job, so generic choices such as "other" or "adjusted" are common, and code lists change between systems. Parts actually replaced, recorded readings and whether the same asset failed again are usually stronger labels. Measure how specific the codes are on the sample, and plan to use notes to recover what the codes miss.

Can I license work order photos for vision models?

Often, after review. Job photos show failed components, nameplates, installations and before-and-after states, which suits training for component recognition and visual inspection. Many photos also capture faces, home interiors, addresses or customer equipment the customer considers confidential, so images go through redaction and some are excluded. Photo quality and consistency vary by technician, so check a sample before relying on them.

Evaluating this data for procurement?

Diligence packets are prepared per dataset. Rights, privacy processing and quality differ between datasets.

Request dataset diligence

Tell us what your models need

Send your spec — domain, volume, format, timeline and permitted use — and SourceX will match it against partner data and come back with what can be licensed.

Updated 3 October 2026. Own data like this? See how companies license it to AI developers.

See if you qualify