Separating Recorded Facts from Inference in a Robot Repair Intake

A repair intake for an industrial robot is not merely a list of symptoms. When a unit arrives at a service facility after a protective stop, a controller fault, or a suspected software irregularity, the intake record has to preserve what was actually observed, when it was observed, and where the observation came from. Everything layered on top of that—likely root cause, probable component failure, estimated repair path—is inference. Keeping those two layers apart is what makes a later service handover, a loaner-unit assignment, or an audit defensible. The practice matters even more when robot behavior may be tied to software components whose origins, updates, and supplier practices are themselves part of the question.

What the intake must capture before anyone interprets it

The first duty of a robot repair intake is to fix the boundary around observed fact. A technician should write down the exact stop code displayed, the timestamp of the stop as logged by the controller, the cell identifier, and the firmware version reported by the unit at power-up. If a safety relay triggered, the intake should note the relay model and the input channel that changed state, not the assumption that the relay is faulty. If an operator reports intermittent behavior, the intake should separate the operator’s words from the technician’s verification of those words. On a site such as robothospital.net, where intake is the entry point for repair rather than a sales description, the record should say who observed what and by which readout. Internal service categories such as those described in protective stop documentation, controller change records, and backup and restoration notes give the intake a structured place to file those observations without collapsing them into a guess.

Published guidance on software supply chain facts

When the repair involves software, firmware, or an update package, the intake benefits from a disciplined view of what a supplier has actually published. NIST’s Software Supply Chain Security Guidance, created November 9, 2021 and updated May 5, 2022 under Executive Order 14028, identifies existing or develops new standards, tools, best practices, and guidelines to enhance software supply chain security. The guidance’s scope includes criteria to evaluate software security, criteria to evaluate the security practices of developers and suppliers, and innovative tools or methods to demonstrate conformance with secure practices, produced after more than 150 responses to a call for position papers, multiple workshops, and draft feedback. A repair intake can cite that published fact: the guidance exists, has that date and scope, and is issued by NIST. The intake cannot, without separate evidence, assert that a specific robot’s software conforms to or violates those criteria. The fact and the inference stay separate.

Using provenance vocabulary for repair records

A second official reference helps define how to model the record itself. The PROV Model Primer, a W3C Working Group Note dated 30 April 2013, introduces the PROV data model for provenance interchange on the web. PROV defines a core data model for provenance for building representations of the entities, people and processes involved in producing a piece of data or thing. Its primer explains fundamental concepts such as entities, activities, usage and generation, agents and responsibility, roles, derivation and revision, plans, and time. In a repair context, the robot unit is an entity, the diagnostic activity is an activity, the technician is an agent, and the test result is generated by that activity using inputs from the unit. The primer’s published date and its status as a W3C Working Group Note are facts; applying its vocabulary to a particular intake record is an editorial and engineering choice made by the repair organization, not something the primer itself commands for robots.

Date, scope and source kept visible

The discipline required by the column is to keep a published fact, its date, its scope and its source distinct from what editors or technicians conclude. The NIST guidance was updated May 5, 2022 and covers software supply chain security under EO 14028; it does not cover mechanical gearbox wear or encoder calibration. The PROV primer was published April 30, 2013 and specifies a provenance data model; it does not certify any repair shop’s process. An intake note might say: “Controller log shows fault 0x2A1 at 2026-10-21 14:03 local; source: cell 7 HMI export.” That is a fact with a timestamp and a source. A later sentence might say: “Fault pattern resembles a prior case where a firmware update altered safety timing.” That is inference, and should be labelled as such. The reader can then re-check the fact and weigh the inference independently.

Why inference still has a place in the record

Separating fact from inference does not mean the inference is forbidden. A repair workflow is useless if no one is allowed to form a hypothesis. The value lies in marking the hypothesis. A hypothetical example may clarify this: suppose a robot arm stops repeatedly and the intake records that the stop occurs only after a third-party vision package loads its configuration file. The observed fact is the timing correlation and the package identity. The inference is that the vision package’s load sequence interferes with a safety handshake. If the repair team labels the second sentence as a hypothesis and preserves the first as the logged event, a later reviewer with different data can confirm or discard the hypothesis without accusing the original technician of fabricating a root cause. The internal pages for protective stop records, pre-controller-change documentation, and backup records before service each assume that the reader can tell which lines are observed and which are suspected.

Operating the intake so later stages inherit clean data

The consequence of clean separation appears in the stages after intake. A loaner unit issued while the original is in repair inherits only the observed serial, the observed fault code and the agreed temporary configuration; it does not inherit a guessed diagnosis that might mislead the next site. A service handover after the cell stops can list the verified stop conditions and then, separately, the hypotheses the team intends to test. When a controller change is planned, the record of what was backed up before the change stays factual—file hashes, timestamps, source paths—while the expectation that restoring those files will return the cell to a prior state remains an inference until tested. By using provenance concepts from the W3C primer to name entities and activities, and by citing NIST’s published supply chain guidance as external fact rather than as a verdict on a specific unit, the repair intake becomes a document that later stages can trust without inheriting unlabelled speculation.