First-Time-Fix and Callback Labels as Outcome Data

Why outcome labels matter for repair data

A repair record usually says what was done. It rarely says whether it worked. Without an outcome, a model that learns from work-order histories cannot tell a correct diagnosis from a guess that happened to be closed. A repair video that ends with the technician packing up may show a failed fix.

Field service organizations track outcome because it drives their costs: a callback means another truck roll. The label is therefore one of the few quality signals that comes out of normal operations rather than annotation. This guide covers how it is derived, how definitions differ and how to use it when sourcing. It belongs to the maintenance cluster in the humanoid data guide.

How outcome labels are produced

Each is a proxy for "repair worked". The common version is the first row: whether a repeat order shows up within a window the organization chose. The window, the way "same problem" is matched and how closures are counted are all organization-specific, so labels from two suppliers are not directly comparable.

Maintenance text is full of local shorthand, as MaintNet's abbreviation lists and termbanks for aviation, automotive and facilities logbooks show (Akhbardeh et al., 2020). The same applies to closure codes and free-text closing notes, which are often the only place an outcome is stated.

What the labels can support

• Filtering and weighting. Train on repairs that held, or weight them more, and treat callbacks as negative or ambiguous examples.
• Evaluation design. Outcome labels let an evaluation score whether a system's proposed diagnosis matches a repair that worked, as set out in troubleshooting evaluation sets.
• Contrast pairs. A failed repair and the later successful one on the same asset form a before-and-after pair. See difficult and failed repairs.
• Business framing. Callback and first-time-fix rates indicate where repair quality is a problem and which tasks are worth automating or supporting.

What the labels cannot support

• Cause of failure. A callback may stem from a wrong diagnosis, a defective part, an unreported second fault, a user error or a new, unrelated fault. The flag does not say which.
• Physical quality. It does not describe how well a fastener was seated or a seal fitted, and does not replace measurement or inspection.
• Control data. No robot action or force appears. It cannot teach manipulation.
• Causal claims. Technician skill, equipment age and customer mix all influence the rate. Do not read a label as a measure of the work in one recorded video.
• Completeness. If the customer called a different provider, the repeat is invisible.

Illustrative outcome fields

# Illustrative only - synthetic values, not an available dataset
order_id: wo_20931
asset_id: asset_0071
closed_date: 2026-03-05
outcome:
  first_time_fix: true
  rule: {window_days: 30, match: "same asset and same fault family", version: ftf_rule_v2}
  callback: {occurred: false, order_id: null}
  escalated: false
  customer_confirmed: unknown
  restore_minutes: 185
fault_family: hydraulic_pressure
fix_code: replace_filter
confidence_note: "single provider; repeats elsewhere not visible"

The rule block is the field most buyers omit and later miss. Keep the window and matching rule beside the flag, and keep the raw order dates so you can recompute with your own rule.

Acquiring the labels

The route is existing assets: a field service organization, facilities team, fleet or MRO provider exports work orders with asset IDs and closure dates. Callback and first-time-fix flags can then be taken from the supplier's reporting or recomputed from the order table. Recomputing is often better, because it lets you choose the window and the match rule.

Pair the outcome fields with the structure in asset hierarchies from CMMS exports, so repeats can be matched across a location. If you also want video of repairs, ask whether the recordings can be linked to order IDs, so that repair video demonstrations can be filtered by outcome.

Preparation a buyer should budget for

• Recompute from dates. Request closure dates and asset IDs so you can derive labels yourself.
• Handle missing follow-up. Decide how to label orders too recent to have a repeat window.
• Redact. Customer names, addresses and contact data sit in order records. Plan redaction before delivery; it does not on its own establish that the supplier may license the records.
• Hold out. Evaluation rows should be separated by site or time. Include the outcome labels used for scoring, and do not use them in training.

Reading rates responsibly

A supplier may quote a first-time-fix rate as a selling point. Treat it as a description of their operation, not of the dataset. The rate depends on the mix of work, the provider's skill and parts availability, and on how they define a repeat. A high rate does not mean every record in the data is a good example; a low rate does not mean the data is poor.

Use the labels at record level. Compare outcome by task type and equipment class, check that the label distribution is not dominated by easy work, and look at how long fixes took, using ideas from labor time standards where the supplier keeps them. Where the label is missing for recent orders, do not treat the absence of a repeat as success; mark those orders as not yet observable.

Finally, keep outcome labels out of any input the model sees at inference time, since they are only known after the visit.

Questions to ask suppliers

1. How is first-time fix defined: window length, matching rule and what counts as the same problem?
2. Can the raw closure dates and asset IDs be supplied so the label can be recomputed?
3. Are repeat orders from other sites, subcontractors or providers visible, or only your own?
4. How are partially completed, canceled and escalated orders treated in the rate?
5. Is customer confirmation captured, and for what share of orders?
6. Do cause codes distinguish a wrong diagnosis from a defective part or a new fault?
7. Over which period and how many sites do the records span, and did the rule change during that period?
8. Can outcomes be linked to any video or photos recorded during the repair?
9. Do service contracts with customers restrict use of order records for model training?

Discuss your requirements

If your evaluation or training set needs outcome labels, describe the equipment classes, outcome definitions 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, and nothing is contracted until a supplier agrees. The catalog entry for evaluation sets describes how held-out data is used.

Tell SourceX what your evaluation set needs to cover

Sources

• MaintNet: A Collaborative Open-Source Library for Predictive Maintenance Language Resources — Published maintenance logbook language resource whose compressed text illustrates why outcome fields must be defined separately.