A Due Diligence Log Method for Used Robot Listings

On a robot marketplace, a listing often tells you what a machine is supposed to be, not what was actually done to it. A practical way to close that gap is to keep a reproducible step-by-step record every time you inspect a used industrial robot: inputs you were given, observations you made, exceptions you hit, and the single owner responsible for the log. This method borrows ideas from provenance modelling and catalog description without turning your inspection into a software project. You can read more about the underlying provenance concepts in the PROV Model Primer and about describing datasets and services in a standard way in the Data Catalog Vocabulary (DCAT) Version 3. The point is not to adopt their full formalisms, but to use their habit of recording who, what, when and how so another person could repeat your check.

Why a Written Inspection Log Matters

A buyer looking at a used articulated arm or a gantry loader usually receives photos, a model number, hour counts or cycle counts, and a short seller description. Those are inputs. If you only write down “looks fine,” nobody later can tell whether you checked the controller, the harness, the brakes or the storage crate. A log turns opinion into an auditable artefact. In provenance terms your inspection activity uses certain entities — the listing data, the robot itself, the test rig — and generates new entities: your notes, photos and verdict. Agents such as the inspector and the seller carry responsibility through their roles. When the log names an owner, usually the person who performed and signed the check, later disputes about operating hours and cycle counts become easier to resolve because the basis for the reading is recorded.

Step One: Capture the Inputs Before You Touch the Machine

Begin the record before physical contact. Write down the listing identifier, the stated robot type, the declared serial, the advertised controller family, claimed hours or cycles, power specification, and any stated refurbishment scope. If the seller supplied a maintenance file, note the file name and date only if it is real; do not invent a document you did not receive. Also record environmental context such as where the machine was stored, since storage history affects seals and grease. A useful internal reference for related buying questions is what to ask about storage history, which complements the input list. Treat each input as an entity that your activity will use, following the simple usage pattern described in the provenance primer: something was used by your inspection to produce a result.

Step Two: Define the Observation Protocol

Your observation section should state what you actually did. For a six-axis arm, a reproducible protocol might include a visual check of castings and covers, a controller boot test, a manual jog of each axis within limits, and a check that the teach pendant buttons respond. Record the sequence so a colleague could repeat it. Note the time and place of the activity, because provenance modelling stresses that activities happen over time and generate entities. Do not merely write “tested OK”; write “Axis 3 jogged through 20 percent of range, no abnormal noise observed at 10:14 in the supplier workshop.” If you could not perform a step, say so in the exceptions rather than omitting it. This protocol becomes the plan behind the activity, similar to how a described plan guides a process in a provenance record.

Step Three: Separate Verified Facts From Unverified Claims

Many listings mix fact and assertion. The cycle count on a pendant is a reading you can observe; the claim “lightly used in a lab” is seller narrative unless tied to a document. In your log keep two columns: observed values and claimed values. Where a claimed hour count matches the pendant, mark it consistent. Where the controller was replaced and the counter reset, write the exception clearly: the displayed count may not represent the arm’s full mechanical life. This distinction is central to marketplace diligence because a spare parts enquiry later depends on knowing which arm and controller revision you truly have. Facts and claims are different kinds of entities in your record, and confusing them creates downstream errors when quoting parts or valuing the machine.

Step Four: Log Exceptions Instead of Hiding Them

An exception is any break in the expected flow: a missing cover, a dead battery causing a controller fault, a label that does not match the invoice, an axis that sticks, or a test you could not run because the cell lacked air supply. Each exception should have a short description, the time noticed, and the person who saw it. Exceptions are not failures of your method; they are the most valuable part of the log because they warn the next reader. If the seller said the robot was refurbished but you observe original worn cables, write that deviation. If a hypothetical example helps: suppose a listing claims a full controller upgrade but the cabinet shows a legacy board revision — that gap between claim and observation must appear as a named exception, labelled as such, rather than as a vague note.

Step Five: Assign Roles and a Single Owner

Provenance records are clearer when agents and their roles are explicit. In your log name the inspector, the seller representative present, and any third-party technician. Say who was responsible for each step: “Owner of log: J. Alvarez, independent inspector, performed visual and boot test on 2026-10-28.” If the seller’s engineer ran the jog test while you observed, record that split of responsibility. A single owner for the whole inspection record prevents the common problem of nobody accountable when two people each assumed the other checked the brakes. The owner also decides when the log version is final and locks it, which mirrors how a described resource can have versions in a catalog vocabulary; your locked log becomes the reference for later queries.

Step Six: Store the Log With the Listing and Reuse It

After the check, attach the log to your internal deal file and keep a short summary in the marketplace message thread if the platform allows. The record should include the inputs, the protocol, the observations, the exceptions and the owner, in that order, with timestamps. Later, when another unit of the same model appears, you can reuse the protocol rather than rebuilding it. Over several inspections the accumulated logs let you compare sellers and notice recurring issues with particular controller families or storage practices. This reusable, standardised way of describing what you have is close to why catalog vocabularies exist: they let different parties exchange descriptions without losing the structure of who did what. By keeping your inspection reproducible, you turn a one-off opinion into evidence that supports valuation, parts identification and negotiation on a robot marketplace.