Reading Robot Listings: Separating Published Facts from Buyer Inference

When a robot appears on a marketplace listing, the description mixes several kinds of statements together. Some sentences report a published fact with a date, a scope and a source. Other sentences are the seller's or the marketplace's reading of what that fact means for a buyer. On robotbuysell.net, where buyers compare used and new units across categories such as industrial robot arms, autonomous mobile robots and collaborative robots, keeping those two layers apart prevents expensive misreadings. The discipline matters because a robot is not only a mechanical asset; it is also a bundle of software, updates, access credentials and service records whose history is easy to summarize and easy to oversimplify.

What counts as a published fact

A published fact on a listing should carry four visible attributes: the content of the fact, the date on which it was published or recorded, the scope it covers, and the source that published it. For software-related claims, the United States National Institute of Standards and Technology publishes guidance on evaluating the security of software and the practices of developers and suppliers under Executive Order 14028. That guidance, created in November 2021 and updated in May 2022, sets out criteria to evaluate software security and supplier practices rather than certifying any single product. See the official resource at NIST software supply chain security guidance. If a robot listing says a controller "meets EO 14028 guidance," the published fact is only that the guidance exists; whether the specific unit conforms is an inference that needs separate evidence such as a supplier attestation or a test report.

Separating date and scope from the claim itself

The NIST page carries a creation date of November 9, 2021, and an update date of May 5, 2022. Those dates tell a buyer when the guidance version was current, not when a particular robot was built, patched or inspected. Scope is equally narrow: the guidance addresses software supply chain security for federal and critical-infrastructure contexts and the practices of developers and suppliers, not the mechanical wear of a gearbox or the cycle count of a gripper. A listing that quotes the guidance to imply "this unit's firmware is verified" moves beyond the published scope into editorial inference. The buyer's job is to note the quote, note its date and scope, and then ask the seller for unit-level records that stand on their own.

Provenance as a model for listing history

The W3C's PROV model primer offers a vocabulary for describing how a thing came to be. Published as a Working Group Note on April 30, 2013, it explains entities, activities, agents, usage and generation, and how responsibility is assigned to people or organizations. The primer itself does not describe robots, but its structure gives buyers a way to ask better questions: which agent performed the maintenance activity, at what time, using which plan, producing which revision of the robot's software state. The official primer is available at W3C PROV Model Primer. Treating a maintenance log as a provenance record means asking for the agent, the activity and the timestamp rather than accepting a summary such as "well maintained."

Applying PROV concepts to a used robot file

In PROV terms, the robot itself is an entity; a firmware flash, a battery replacement or a safety-scanner recalibration are activities that used or generated other entities such as a file, a part or a configuration. An agent is the service technician or integrator who carried out the activity, and responsibility attaches to that agent through the record. Derivation and revision describe how a later configuration came from an earlier one. A buyer looking at a mobile robot battery history can therefore separate the published fact "cell pack replaced by agent X on date Y" from the inference "remaining life is therefore long." The first is a provenance statement with date, agent and scope; the second depends on usage profiles the record may not contain.

Why inference grows in the gap between records

Sellers and marketplaces fill gaps with reasonable-sounding conclusions because complete unit-level histories are rare. A gap is not wrongdoing; it is simply missing provenance. Suppose a listing states that a controller follows secure practices "consistent with current guidance." The word "consistent" is inference: no date, no scope, no named source for that specific claim. A hypothetical example: a warehouse offers a unit whose software bills of materials were never retained by the previous owner. The absence of that document does not prove insecure practice, and the presence of a general NIST reference does not prove secure practice. The buyer records what exists, dates it, sources it, and treats the rest as open questions.

Practical steps for the buyer's own notes

Keep two columns when reviewing any listing on robotbuysell.net. In the first, write the published fact with its date, scope and source exactly as given; link to the official page rather than paraphrasing it. In the second, write the inference the text suggests, and label it as inference. When the same robot is cross-listed under arm-type classifications or collaborative categories, compare whether the fact column stays identical across listings while the inference column changes. Differences in inference often reveal where sellers are guessing. This habit does not eliminate uncertainty about a used machine, but it makes the boundary between what was published and what was concluded impossible to overlook.