Test inspection-data handover before you accept the robot

The useful result is outside the demo

An inspection robot can complete a route and produce a convincing dashboard while leaving the maintenance team with an unfinished workflow. Someone still has to identify the asset, understand the measurement, retrieve the supporting capture and decide what happens next. Before agreeing a rollout, make that handover a testable part of the solution—not a future integration discussion.

Start with one receiving team and one inspection type. Ask that team to take a representative result from the robot platform into the system it will actually use. A successful download is only the first step. The receiving person should be able to interpret the result without reconstructing its meaning from a sales presentation. This article proposes a buyer acceptance method; it does not assess or certify any manufacturer's implementation.

Know which layer you are exporting

Keep three layers separate: the original capture, its operational context and the interpreted result. A picture of a thermal display is not necessarily the underlying temperature measurement. An alarm may be useful for triage while still needing the original observation for diagnosis. Write down which layers your maintenance workflow needs and which can reasonably be excluded.

Boston Dynamics' Spot 5.2.0 data-acquisition documentation, checked on 4 October 2026, provides a concrete example of this distinction. It describes downloads containing captured files and associated JSON metadata; position CSVs are optional when that information was captured. Its CSV description allows empty entries when data was not captured for a file. Test missing information rather than assume every export is complete. The format is product-specific, not a universal robotics interface.

Define the receiving contract

For each inspection type, agree the destination, expected file or record format, identifiers, units, timestamps and access role. Specify which identifier connects the reading to your asset register. Include a time zone or another explicit time convention so separate systems do not silently disagree about event order. Where location matters, record the agreed reference system and mapping responsibility rather than treating an unexplained coordinate as sufficient context.

Then give the provider a small representative sample set to demonstrate. Include a normal observation, an exception and an incomplete capture. Ask the receiving team to distinguish those cases. A blank value must not become a normal reading merely because an import routine accepted the row. Keep the acceptance evidence alongside the field mapping so later configuration changes can be checked against the same example.

An API is a route, not a finished workflow

Boston Dynamics publishes an Orbit example that authenticates a client and exports archives from recently completed missions. This demonstrates an available integration path, not proof that a customer's maintenance application has been configured or tested. Its production guidance recommends certificate verification. Do not copy a local-development shortcut into a production integration without reviewing the deployment requirements.

ANYbotics describes Data Navigator as a central inspection-data platform with on-premise, cloud and air-gapped deployment options. Those are vendor-described choices. The buyer still needs to establish which option is being quoted, who operates it and how the chosen receiving system accesses results. Neither an API label nor a hosting option answers the complete handover question.

Test interruption, retrieval and service exit

Agree a controlled transfer-interruption test with the delivery team. Record how unsent captures become visible, who receives an alert and how the transfer is resumed. Reconcile the source and destination totals, including duplicate and rejected records. Do not interrupt a live operational service merely to populate a checklist; use the agreed test environment and procedure.

Retention is also an operating requirement. Specify the period, what starts the clock, where the authoritative copy lives, who can retrieve it and who approves deletion. There is no single retention period suitable for every inspection or customer. Have the appropriate records, security and legal owners determine the applicable requirements. A storage-capacity estimate is not a retention policy.

Before handover, retrieve an older sample using an ordinary authorised customer role. Record any dependency on a subscription, privileged vendor account or proprietary viewer. Ask what happens to existing records and export access when the service ends. These are scope questions for the actual agreement, not assumptions to be inferred from a product page.

Make the result useful to both sides

Use six acceptance areas: original captures; asset and time context; destination and transfer; retention and retrieval; interrupted transfer; service exit and access. Give each a responsible role and a test reference. A provider statement can be recorded as supported, but it should remain distinct from a test your receiving team has completed. Where an item is unnecessary, document the agreed exclusion rather than marking a test as passed.

The free RobotAtom inspection-data handover checklist turns those decisions into a downloadable record and highlights unresolved areas. It stores entries only in the current page and does not upload operational files. Adopters gain a clearer definition of usable inspection evidence. Providers gain bounded integration responsibilities and observable acceptance criteria. RobotAtom uses that shared specification to shape a complete robotics solution for the real operating environment, while the responsible specialists validate its implementation.

Run a receiving-team decision test after transfer

A successful import answers whether data arrived. It does not answer whether the next maintainer can use it. For a bounded pilot, agree a small set of permission-safe samples and expected dispositions with the maintenance owner before seeing the result. Include a normal observation, one requiring review and one incomplete or low-quality capture; add a missing reading where that failure belongs in scope. Use the configured receiving route and an ordinary authorised role, not a guided tour of the provider dashboard.

Ask a maintainer who has not been coached on those particular samples to identify the asset and inspection point, capture time and time zone, units, operating context and original evidence. Can they tell an observation from a diagnosis? Can they distinguish 'no abnormality detected' from 'not measured' or 'not yet reviewed'? The team should record its actual disposition under site rules: routine record, re-inspection, specialist review or work-control item. Keep the owner, decision reference and path back to the original capture. For a rejected import or ambiguous observation, record the exception rather than silently treating it as a pass.

Set the acceptance rule first: required fields, allowed omissions, who judges uncertain observations, how an exception becomes visible and what evidence closes it. Compare expected and observed outcomes sample by sample. Reconcile the number of source samples against received records and decisions, including misses and duplicate attempts. A work-order entry still cannot prove that a thermal measurement or diagnosis is correct; that needs separate technical validation by qualified owners.

Why this is a decision test, not a standards certificate

ISO 55013:2024's public abstract frames asset data around the organisation's asset-management objectives. ISO 13374-4:2015 separately addresses presenting condition-monitoring health information and recommendations for technical analysis and decision support. NIST describes maintenance work orders as records used alongside equipment and sensor data. Those sources support asking whether information survives into a useful receiving workflow; none prescribes the exact RobotAtom sample test or certifies a particular robot.

IEC 62381:2024 describes agreed, project-specific integration and acceptance testing responsibilities for process-industry automation. We borrow the discipline of naming who demonstrates an interface and who accepts it, not a claim that the standard governs every inspection-robot deployment. The receiving maintenance and engineering owners set local decision, severity and safety rules. Access controls, sensor suitability, calibration and urgent escalation remain separate reviews.

The experimental handover tool now lets a team export its pre-agreed rule and each sample's expected and observed disposition, reviewer role, work reference, exception and original-capture reference. It does not inspect files, connect to a CMMS or decide whether entries pass. That is deliberate: the responsible receiving team must judge the evidence, while a provider can see the specific interface and exception cases it is being asked to demonstrate.

Assign each transfer exception before handover

A transfer problem and an inspection decision need different records. 'Missing capture' means the receiving team lacks expected evidence; it does not mean the asset is healthy or faulty. An unreadable file, duplicate import or mismatched asset identifier needs its own owner even when the rest of the batch arrived. The practical buyer question is: who investigates this specific exception, and what will the receiving owner inspect before accepting its closure?

Consider a hypothetical test with twelve source captures. The receiving system contains eleven rows, but two rows refer to the same capture: only ten unique source captures are represented. A row count alone could hide both a duplicate and two missing captures. Compare stable source identifiers against receiving references, then record each mismatch. This is an illustrative reconciliation problem, not a claim about a vendor's export behaviour or an acceptable loss threshold.

For each exception, record the affected capture or batch, observed problem, source reference and receiving reference when one exists. Name the responsible role, the agreed next action and a review date with an explicit time convention. 'Provider to investigate' is insufficient if no delivery role has accepted responsibility. Where the receiving reference is absent, keep that absence visible; do not create a placeholder that looks like a successful import. Keep credentials and operational file contents out of the planning record.

Set the closure evidence before retrying. For a missing capture, that might be a controlled retest showing the expected identifier, usable file and required context in the agreed destination. For a duplicate, it might include the authorised reconciliation record and a rerun demonstrating the agreed result. The integration owner should agree the procedure first: this checklist does not authorise deletion, production interruption or a retry that could create another work item. Retain the original exception alongside the retest so a later reviewer can follow what changed.

An agreed exclusion is different from a successful retest. Preserve the exclusion reason, scope and receiving-owner reference instead of erasing the exception. If ownership, review timing or closure evidence remains unsettled, carry the item into the handover discussion as open. The RobotAtom checklist now exports this exception log separately from inspection dispositions. Completing its fields records the team's account; it does not validate files, certify an interface, judge a diagnosis or approve deployment. Urgent alarms and safety escalation still belong in the site's established operational process.