Robot inspection coverage needs an asset-condition matrix

Start with the condition, not the route

An inspection robot can complete a route while leaving an important maintenance question unanswered. Reaching a pump does not establish that the configured sensor can observe the condition of interest, from the available viewpoint, under the operating conditions that matter. Before comparing robots, define what each inspection must tell the asset owner.

RobotAtom recommends an asset-condition matrix: one row for each required observation, with the method, access limits, revisit window and acceptance evidence recorded alongside it. This is a planning method, not a certification or an estimate of detection accuracy. It gives operators and providers the same testable scope instead of asking either side to interpret an open-ended request to inspect the site.

Separate mobility, measurement and maintenance decisions

Boston Dynamics describes visual, thermal and acoustic inspection options for Spot, including gauge capture and optional thermal sensing. These are different observation methods; the manufacturer page does not establish that any one configuration covers every condition at a particular plant.

ANYbotics describes inspection-point data contextualised by time, location and viewpoint, as well as connections to asset-management systems. That distinction is useful: an observation needs an identity and context before it can support comparison or follow-up. These remain manufacturer capability descriptions, not RobotAtom-validated site performance.

Ask three separate questions. Can the robot reach an approved observation position? Can the installed measurement method produce usable evidence there? Does a responsible person or existing maintenance process know how to interpret and act on that evidence? A demonstration of the first is not an answer to the other two.

Build one row for each asset-condition pair

A single asset may need several rows because different conditions need different observations. Do not hide that distinction by giving the entire asset one green status. Equally, do not count extra images of the same condition as extra required coverage unless the inspection method needs those viewpoints.

• Asset and zone: identify the component and the specific area to observe, not just a room name.
• Condition: state the change or defect class the inspection is intended to reveal. Avoid catch-all descriptions such as check everything.
• Method and viewpoint: name the sensor configuration, observation position and reference needed for comparison.
• Access and operating limits: identify obstructions, visibility, site permissions and machine operating states that limit the measurement.
• Revisit window: have the responsible asset specialist define when the observation must recur and when missing it needs escalation.
• Acceptance evidence and owner: specify what is retained, how it is compared with a suitable reference and who decides whether it is usable.

An illustrative pump requirement

Suppose the proposed task is repeatable temperature observation at a pump bearing. A draft row could name the bearing, a marked thermal observation point, a normal-load operating condition, a site-defined revisit interval and comparison readings reviewed by maintenance. That is an example of a brief—not a recommendation that thermal inspection alone can diagnose the pump.

If the observation point is obscured during normal production, the row remains unresolved. Options might include a different approved viewpoint, an agreed operating window, a different sensing approach or retaining a separate inspection method. The provider should state which option its proposed configuration supports; the asset owner should approve the resulting scope and exclusions.

Keep missing observations in the denominator

For a representative test, agree the required asset-condition observations before the run. Record which produced accepted evidence, which were attempted but unusable and which were not attempted. Show exclusions separately rather than deleting difficult requirements after the demonstration.

For example, if ten required observations are agreed and eight produce accepted evidence, report eight of ten under the stated test conditions, alongside the two unresolved observations. Do not present that result as 80% defect-detection sensitivity: the test has measured completion of the agreed observation set, not the probability of finding every real defect.

Track route completion, usable-observation completion and maintenance disposition separately. This prevents a navigation success, a file upload and a confirmed asset-health conclusion from being reported as the same outcome.

Test the gaps before expanding the route

Start with a bounded set that includes representative difficult observations, not only the easiest accessible assets. Agree the comparison method and acceptance rule before seeing the robot results. Preserve configuration, operating state, timestamps, viewpoint and failure notes so a later change can be assessed against the original test.

Include a missed observation in the workflow test: can maintenance distinguish an absent reading from a normal reading, assign the follow-up and retain the reason? Define who handles obstructed access, failed capture and an overdue revisit. These are proposed acceptance questions; their answers depend on the actual robot, software, integration and site procedures.

Match the observation to the revision under review — added 14 October 2026

An inspection requirement can keep the same asset label after a component is replaced or its configuration changes. Before comparing a new reading with an earlier one, ask which physical component and recorded revision each observation describes. A route location or familiar filename cannot answer that question on its own.

ANYbotics’ undated capabilities page, checked 14 October 2026, describes inspection data with time, location and viewpoint context, plus connections to maintenance systems. It is a useful example of contextual data, but the page does not establish automatic matching to a buyer’s engineering revisions. That mapping needs evidence from the actual asset records and integration.

W3C’s PROV-O Recommendation, published 30 April 2013, distinguishes an entity, a relationship to an earlier revision and the time an entity was generated. This is a provenance vocabulary, not a physical-identity check. A report generated today does not prove that the asset configuration it names became effective today. RobotAtom’s comparison below is a planning method, not a PROV implementation or W3C-endorsed process.

Start with the controlled record that defines the review baseline. Keep its asset identifier, revision reference and observation-point identifier alongside those retained with the observation. Preserve the capture timestamp, time zone and original evidence elsewhere in the inspection record. Where revision applicability depends on an effective period or replacement event, ask the asset owner for the supporting change record; do not infer it from the file date.

Consider a hypothetical pump whose bearing is replaced while the plant keeps the label P-01. A capture labelled revision R1 and a review baseline labelled R2 may refer to different components or arrangements. Keep the mismatch visible and have the responsible specialist establish whether comparison is meaningful, needs a documented mapping or requires a new observation. The mismatch itself is not evidence of a defect.

The linked planner now compares one observation’s typed asset, revision and observation-point references with a review baseline. A blank reference withholds comparison; a difference is retained by field. Surrounding spaces are ignored, but case and other characters remain significant. Equal entries mean only that the supplied references match. They do not verify the physical identity, revision applicability, sensing conditions or quality of the measurement.

Download both sets of references and the unresolved result before leaving the page. Do not overwrite an old observation’s label to make it fit the current baseline. Record any approved mapping separately with its owner and supporting reference, then return to the existing inspection-quality and handoff checks. A reference match is no permission to operate, maintain or accept the asset.

A clearer scope benefits both sides

Operators receive a visible boundary around what the proposed solution will and will not inspect. Providers receive a concrete configuration and acceptance discussion rather than an invitation to promise whole-site coverage. Remaining manual work, specialist review, integration and support can then be included explicitly in the deployment scope.

Use the free RobotAtom inspection-coverage planner to create and download a working matrix. RobotAtom can use that brief to shape a custom inspection solution and a measurable deployment plan. Site-specific engineering, inspection-method approval and safety responsibilities remain with the accountable specialists; this article and worksheet do not replace them.