Before Accepting a Substitute Robot, Recheck the Original Commitments

"An equivalent model is available sooner." That sentence is a synthetic example used here to illustrate the kind of message a buyer may receive, not a real quotation from any supplier or a customer record. Substitute the sentence into a live order and the real question appears at once: which committed configuration in the order does the change touch? A substitution is not one decision but three actions performed in order: mark the changes against the ordered configuration, decide which earlier conclusions survive, and close the approval record before shipment.

Mark the changes against the ordered configuration

The first action is to name the object of the change precisely. "Equivalent" and "upgrade" are not change objects; the mechanical body, the controller, the end tool, the software, the interfaces and the document revisions are. Lock the purchased baseline version and record each item separately. Unknown values are written as "not provided," never as "same."

Use synthetic configuration codes only for the illustrations in this article. In an actual substitution review, record the exact ordered and proposed model, controller, tool, software and document versions, together with the applicable technical values. Mark genuinely missing information as not provided rather than replacing it with a fictitious code or treating it as unchanged.

Hardware, mounting and working envelope

Check the mounting interface, the outer dimensions, and the working envelope against the ordered configuration. A change to any of these can touch the reach and fixture conclusions that were settled earlier, so the two version drawings plus the corresponding tooling and motion coverage are the evidence to pull.

Controller, software, interfaces and licenses

A controller or firmware change can alter interfaces, functions and the ability to reuse the existing configuration. A change of controller does not follow from the body staying the same. Record the exact version, any compatibility statement, and the scope of the earlier interface verification.

The documents and tests attached to the original configuration

Note which documents and tests were attached to the original configuration, because their scope defines how far the earlier conclusions can travel. Do not carry a test result to a changed tool combination without checking whether the documented test scope and the change assessment cover it.

Decide which earlier conclusions survive the substitution

An earlier conclusion can only carry forward within unchanged evidence scope. A shared rated payload or a matching certification mark is not sufficient material for full-configuration equivalence. Recheck only what the change touches, and do not overturn unaffected conclusions.

Carry forward a conclusion only within unchanged evidence scope

If the change is limited to a document revision, and the maker can traceably confirm that neither the technical configuration nor the scope of the original evidence changed, the earlier conclusion may be proposed to carry forward. The approval record still stays in place.

Retest the task or interface affected by the change

If the controller changed and the earlier interface verification covered only the old version, the mechanical conclusions are not necessarily void, but the affected interfaces need a targeted recheck. "Upgrade" does not automatically release them.

Decline an unproven change to a critical commitment

If a critical function of the original order has no applicable delivery evidence in the substitute configuration, the change stays unapproved. Close rated-parameter similarity does not cover that gap.

Three worked examples show how the decision is written. They are logic illustrations; they point to no real model and are not a legal opinion or an automatic approval.

• A. Document revision only. The maker traceably confirms the technical configuration and the original evidence scope are unchanged. Propose to carry the earlier conclusion forward, and still leave the approval record.
• B. Controller change with narrow interface verification. The earlier interface verification covered only the old version. The mechanical conclusions are not all void, but the affected interfaces need a targeted recheck; do not release them as an "upgrade."
• C. Critical function without applicable evidence. The original order's critical function has no applicable delivery evidence in the substitute configuration. Keep the change unapproved; rated-parameter proximity does not cover this gap.

Configuration baselines and version control across a fleet are their own discipline, and configuration baselines and version control holds that detail. When the reader does not yet have a comparable purchase baseline, requirement-to-evidence comparison is a conditional background link rather than a second scoring table.

Close the substitution record before shipment

The technical judgment has to reconnect to approval and delivery control. Keep the original and proposed configurations and versions, the differences, the evidence, the open items, the customer's authorized approver, and the final delivery list. The formal contract change, where needed, follows formal project change control.

Update downstream documentation and service assumptions

A configuration change ripples into spare parts, service assumptions and document versions. Record the downstream impact and its owner so the substitution does not silently break a maintenance commitment.

Record who approved which configuration

The record names who approved which configuration. A new shipping date is not approval evidence, and schedule pressure is not a reason to skip the approval step. This article does not make the final acceptance decision for the buyer.

When a substitution notice arrives, provide the ordered baseline and proposed configuration for robot selection support. Mark the commitments that change and the manufacturer evidence already available. Keep the decision to accept, retest or decline with the customer's authorized approver and the final delivery configuration.