Equipment-Specific vs Transferable Maintenance Skills

The scoping decision

A maintenance dataset can be wide, covering many tasks across many machines with few examples each, or deep, covering one machine family exhaustively. Neither is right by default. The choice depends on where the robot will work, how often equipment changes, and whether the deploying site can supply machine-specific documents at install time.

Teams often describe the goal as "general maintenance." That phrase hides three separate requirements, and mixing them leads to purchases that cover the easy layer thoroughly and miss the one that causes failures. The sections below separate them so a specification can state which layer each data package is meant to serve.

Three layers of maintenance skill

The third layer is mostly documents, and a deploying site can often provide it. The first layer is mostly physical, so it needs robot-relevant capture. The middle layer is where scoping mistakes cluster.

Using a task vocabulary to separate layers

A shared task vocabulary makes the split auditable. O*NET publishes task statements and Detailed Work Activities (DWAs), with a file that maps task statements to DWAs, and it retains task statements only when their relevance rating is 25% or higher (O*NET Resource Center). Check how coarse the DWA level is for your purposes: it can serve as a rough label for activities that recur across jobs, while individual task statements are more specific to one occupation.

A buyer can use this as a labeling scaffold: tag each planned recording with a DWA-level activity and a machine class. The DWA gives a cross-occupation handle, and the machine class shows how concentrated the data is. O*NET is an occupational description database, not a robotics taxonomy or a measure of what a robot can do, so treat the mapping as a convention for reporting, not a guarantee of transfer. The same idea underlies prioritizing maintenance tasks for collection.

What published cross-platform work implies

Open X-Embodiment pooled robot data from 22 embodiments covering 527 skills across 21 institutions, and reports positive transfer across robot platforms for its RT-X models (Open X-Embodiment Collaboration, 2023). The finding concerns robot embodiments and skills in lab-style settings; it does not show that maintenance skills transfer across machines. It does give a reasonable basis for treating diversity as an input to generalization, and for asking suppliers about it explicitly. The amount of diversity a given architecture needs is not something the study answers.

Decision criteria

Use these questions to place a requirement on the breadth-depth spectrum:

• How often does the target equipment change? A fixed line suggests depth; a mixed facility suggests breadth.
• Can the site provide documents for its own machines? If yes, shift budget from layer three to layers one and two.
• How contact-rich is the task? Force-sensitive work in the middle layer often needs instrumented recording, not video; see hand tool use demonstrations and instrumented tools.
• What is the evaluation claim? "Works on unseen models of a known class" requires holding out machine models; "works on unseen classes" requires holding out classes. Never mix these held-out sets back into training.
• Is the equipment class itself well defined? Industrial machinery maintenance and facility maintenance tasks illustrate how different classes behave.

Illustrative scoping sheet

# Illustrative only - values are synthetic
scope_id: maint_scope_v0
layers:
  primitives:
    activities: [fasten, unfasten, inspect_visually, read_gauge, wipe_clean]
    machine_classes: 6
    goal: variety of tools, hands and workspaces
  class_knowledge:
    classes: [centrifugal_pump, belt_conveyor]
    models_per_class: "buyer-set, at least enough to hold out one model per class"
    goal: recurring structure across models
  specific_detail:
    models: [model_A12, model_B07]
    source: site-supplied manuals and parts lists
evaluation:
  holdout: one model per class; one site; one operator

Limitations and what this framework does not settle

The three layers are a planning aid, not a measured property of any model. A skill that looks transferable to a person, such as removing a cover, can depend on gripper geometry and access space for a robot. The layers also interact: a generic fastener primitive can fail on a recessed, corroded or cross-threaded screw.

Nor does the framework fix quantity. How many examples per layer a given policy needs depends on architecture, embodiment and task, and no published figure here replaces your own pilot. Run small pilots that vary one layer at a time.

Finally, existing business records rarely arrive layered. A supplier's work orders are class- and model-specific by default, so breadth may need new recording.

Worked example: two deployments

Consider two buyers with the same goal, a humanoid that performs preventive maintenance.

Buyer A targets a single plant with a fixed, known set of machine models, all known in advance. Layer three is largely documented and available from the plant, so Buyer A spends less on equipment-specific recordings and more on layer two: several examples per machine class, with models held out, to see whether the robot handles an unseen model of a familiar class. The primitives layer is bought as general tool-use and gauge-reading data.

Buyer B targets a rental fleet where machines arrive without warning and from many makers. Layer three cannot be pre-collected, so the data budget moves to layers one and two, and the product needs a robust way to ingest manuals at the point of use. Here the risk is a model that appears competent on known machines and fails silently on new ones, so the evaluation should include machine classes absent from training and should score the robot's ability to say it does not know.

Neither buyer needs a universal quantity. Each needs a specification that names which layer a package serves and how it will be held out.

Some knowledge transfers across machines without any motion data; tool selection knowledge is an example of a layer you can scope separately.

Questions to ask suppliers

1. How many distinct machine models and classes appear in the data, and in what proportions?
2. Are the same tasks recorded on more than one model, so that you can measure within-class variation?
3. What portion of the data comes from a single site or technician?
4. Are task labels assigned using a shared vocabulary, and which one?
5. Does the supplier hold model-specific documents that can be licensed with the recordings?
6. Can you receive per-model counts, so you can create held-out splits?
7. Were tools and fasteners varied, or did the same kit appear throughout?
8. Can the supplier record additional models on request, and what site access does that need?

Discuss your requirements

If you are deciding how wide or deep a maintenance dataset should be, describe the equipment classes and tasks to SourceX. SourceX reviews the requirement and follows up about potential sources among US businesses; a request does not guarantee a match. To structure the request, use the requirements specification template, and for context see the maintenance data hub, the humanoid training data guide, and the catalog's robotics and embodied AI use case.

Discuss your humanoid training-data requirements with SourceX

Sources

• ONET Database (ONET 29.1 per search snapshot): Task Statements and Detailed Work Activities — task statements, DWAs and their mapping.
• Open X-Embodiment: Robotic Learning Datasets and RT-X Models — pooled multi-embodiment robot data and reported cross-platform transfer.