An Acceptance Witness Is Not a General Condition Guarantee

On a used-robot listing, a short "acceptance witnessed" line can read like a promise about the whole machine. In resale paperwork it should instead describe a narrow observation event: who watched, which unit was configured in which way, and which checks were deliberately not performed. Treating that note as a general condition guarantee invites disputes, because a buyer may read it as covering mechanical wear, controller history, safety functions, or long-term reliability that nobody actually tested. The safer editorial habit is to write the document so its scope is explicit, using measurement provenance ideas from the W3C PROV model and metrological-traceability language from NIST, while never implying a legal warranty.

Separate the Observation Event From the Asset Story

A witnessed acceptance record is evidence of one activity on one day, not a full biography of the robot. The PROV Model Primer explains that provenance records describe entities, activities, and agents, and that those records are metadata about how something was produced or changed. In resale terms, the entity is the specific robot configuration that was observed; the activity is the witnessed power-on or function demonstration; the agents are the people or organizations present. A document that mixes these roles tends to blur them: the seller's technician becomes "the certifier," and the demonstration becomes "full acceptance." Recommended documentation practice is to keep three blocks distinct: observed unit identity, witnessed activity, and excluded tests. The PROV view also reminds us that provenance depends on perspective. A buyer may care who attended; a service historian may care what prior entities—earlier controllers, replaced arms, earlier software builds—contributed to the current configuration. Recording provenance is not the same as approving every descendant part.

Write Setup Identity Before Any Result Language

Setup identity prevents a later reader from assuming the witnessed unit equals every stock-keeping variant of that model. A six-axis arm may have been witnessed with one end-effector, one teach-pendant language, one firmware branch, and one cell layout. NIST's discussion of metrological traceability notes that merely using an instrument calibrated at NIST is not enough; the provider must document the measurement process or system and describe the calibration chain connecting the result to a reference, with the calibrated instrument only as one link in that chain, as described in the NIST traceability FAQ and policy. For robot resale, the analogous recommended practice is "configuration provenance": list the exact serial-numbered components, the software identifiers, the fixture or payload used during observation, and the environmental conditions such as input power. If the demonstration used a temporary test pendant rather than the sale configuration, say so. NIST also states that calibration and test results apply only to the specific instrument or standard at the time of test unless clearly stated otherwise. In editorial terms, a witnessed note should carry the same time-and-unit boundary: this setup, this moment, those connected components.

Use "Traceability Support," Not "Certified Condition"

Sellers often want strong words, but the source language is more careful. NIST distinguishes assuring traceability from certifying traceability: assuring means providing support for the claim, while certifying means formally attesting that traceability has been established for a specific measurement result. Similarly, accreditation recognizes competence to carry out specific tasks and does not itself qualify a laboratory to approve any particular product. Recommended documentation practice for listings and handover memos is therefore to avoid "certified good condition," "safety guaranteed," or "fully validated" when the underlying event was only a witnessed start-up. Instead, write that the record supports a traceability claim for named checks—for example, that a gauge used to verify repeatability was part of a documented calibration chain. Do not extend that support to untested subsystems. A Jazzy-style mobile base may be observed driving in a clear hallway; that does not mean its braking performance on a ramp, its battery health after many cycles, or its obstacle-detection behavior in clutter was measured.

List Excluded Tests as a First-Class Section

The most useful resale documents state what was not done. NIST notes that Special Tests may be designated for seldom-requested calibrations, unique requests, or services still under development, which means even institutional reports can have limited statistical bases or incomplete quality-control documentation. In buying-and-selling paperwork, an "excluded tests" section should name the areas beyond the witnessed scope: payload capacity beyond the demo load, duty-cycle endurance over weeks, collision-force behavior, safety-stop validation, network-security configuration review, and controller-error-log history reconstruction. Recommended practice is to phrase exclusions plainly rather than silently. "Not observed" is better than no sentence, because absence of a line can be read as inclusion. For a hypothetical example, suppose a listing says "acceptance witnessed: robot powered, homed, and moved three axes under no load." The excluded-tests block should add that no lifting, no cycle-life testing, and no repeatability measurement were performed. That hypothetical note does not weaken the sale; it defines the document's edge.

Keep Provenance of the Document Itself

The record about the robot should also be traceable as a document. PROV describes how an activity may use earlier entities and generate new ones, and how an agent may act on behalf of an organization, allowing chains of responsibility to be expressed. A recommended checklist for resale paperwork is to capture the document's own provenance: who wrote the witness note, on what date, using which prior inspection photos or service extracts, and on whose behalf the observer attended. If a third-party inspector wrote it, name that agent and its relationship to seller or buyer. This matters because later readers often cannot tell whether a note came from the owner, a marketplace photographer, or an independent witness. Storing the original file hash, capture time, and source photo IDs alongside the note helps future buyers distinguish a fresh observation from a recycled one copied across listings.

A Practical Recordkeeping Checklist for Listings

A short checklist keeps the language disciplined. Recommended documentation practice for robot buying-and-selling platforms is to include: unit serial numbers and configuration identifiers; date, time, and location of the witnessed activity; names and roles of attending agents; the exact functions observed; the fixtures, payloads, and software present; whether any measuring device had a documented calibration chain as NIST describes; the excluded tests; and the document's own author and source files. Linking to technical guides that explain repeatability terms can help buyers read the note correctly, while industry updates may show why a particular model had known configuration variations. The goal is narrow, honest metadata: enough provenance to trust what was seen, and enough exclusion language to stop the note from becoming a general condition guarantee.