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.1.9 data-acquisition documentation 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 explicitly allows empty entries when data was not captured for a file. That is a useful reminder to test missing information rather than assume every export is complete. The format described 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.