The buyer task and decision boundary
A handover should allow the receiving engineer to reconstruct the decision and continue the task. Preserve identities, revisions, permitted combinations, changed parameters, original observations and open conditions. Separate an item delivered from a task verified. The buyer should be able to see who confirms each relationship, what the actual observation covered and which questions remain for the manufacturer, service party or operator.
Technical context: Prepare a shipment and service handover record
The handover should include the robot identity, original and proposed part numbers, revisions, drawing references, configuration backup scope, packaging instructions from the responsible party, and the inspection expected on receipt. Add the approved return or disposal arrangement for the removed item. Keep commercial terms and technical confirmation distinct: a quotation does not establish compatibility or remaining life. For a gearbox, preserve the exact measurement definition rather than relabelling a loaded torsion number as backlash. The manufacturer catalogue supports that terminology distinction only within its stated families. [S1]
A second condition to preserve: Close the enquiry at the level actually supported
A closure record should separately state the observed symptom, the change made, the task used for verification and the remaining uncertainty. Name the responsible roles and the documents needed to resolve open items. Do not invent a supplier authorisation, an inspection result or a warranty that has not been supplied. This site provides original sourcing and documentation guidance, not a live stock catalogue or a report of repairs performed. The worked arithmetic and hypothetical exercises illustrate reasoning; neither creates a performance specification for a product offered by this site. In this handover, identify the exact artefact and receiving role for every unresolved item.
Deliver the chain behind the conclusion
For a received part, separate identity inspection, installed configuration and task observation. The useful handover is the connection from identity and input to action, observation, interpretation and decision. Give every artefact a stable reference and preserve the originals. A summary may be convenient, but it should point to the material needed to inspect it. Separate a proposed plan from work actually performed, and separate a delivered item from a verified task. This prevents a polished report from concealing an incomplete evidence chain.
Reconcile expected and actual results
For a received part, separate identity inspection, installed configuration and task observation. For every agreed output, show the expected basis, the actual artefact, any discrepancy and the responsible role. Include failed, interrupted and not-covered conditions. A complete folder is not automatically a technically accepted result. Where a conclusion is provisional, state the exact condition and next action. Acceptance should remain connected to the task and configuration rather than being reduced to a single signature that appears to cover every technical question.
Make future changes reviewable
For a received part, separate identity inspection, installed configuration and task observation. Preserve current and previous revisions with the reason for change. Explain which assumptions and results are affected, and which remain applicable. An updated source or replacement component should not silently rewrite the record of an earlier task. If data, programs or credentials need authorised transfer, identify the scope and recipient without exposing secrets in public documents. The receiver should know how to continue safely within the actual responsibilities.
Use the three working sheets as one handover route
For a received part, separate identity inspection, installed configuration and task observation. The requirements sheet captures inputs and unknowns, the comparison sheet records alternative scopes and tradeoffs, and the acceptance sheet links expected and actual evidence. Example rows teach the format; they are not product specifications or observations. Add the real project information only when it is available. The next enquiry can then name a specific task, attach its evidence and request a written scope, rather than restarting with an ambiguous demand for a complete solution.
Apply the worksheet to this domain
Use the acceptance sheet to reconcile robot serial identity, parameter backup scope, verification task and handover responsibility. Each output needs an expected basis, an actual artefact, a discrepancy state and a responsible role. Point to original files instead of relying on a final slide or summary. Keep failed and not-covered conditions visible. Reconcile the package against the written scope before signing for it, and identify which open conditions are accepted for later work. The receiver should understand how to continue without treating a complete folder as proof of every technical conclusion.
Four routes and their tradeoffs
The handover for exact part-number replacement should include evidence for suffix, revision, provenance and permitted parameter handling. State its applicable scope: The installed identity and replacement basis are already known. Keep the receiver aware that a narrow scope still needs receipt and installed-task checks.
The handover for documented alternative should include evidence for mechanical, electrical, feedback and controller support separately. State its applicable scope: An applicable maker or responsible party has confirmed the relationship. Keep the receiver aware that more sourcing flexibility creates additional evidence to review.
The handover for diagnosis before purchase should include evidence for original logs, triggering task and authorised diagnostic route. State its applicable scope: The symptom has not established the failed assembly. Keep the receiver aware that upfront investigation can reduce unnecessary component buying.
The handover for interface and handover review should include evidence for drawings, configuration, receiver inspection and unresolved conditions. State its applicable scope: A proposed component exists but its evidence pack is incomplete. Keep the receiver aware that a review clarifies scope but is not a supply or repair commitment.
Prepare the next review with original evidence
For the next handover review, reconcile the written scope with the delivered artefacts and open conditions. Ask the receiver to follow one conclusion back to its original input and process record. Confirm responsibilities for corrections, later changes and missing evidence. The references below support interpretation, while the delivery remains tied to its actual task and configuration. Acceptance should leave a package that another person can inspect and continue, including an honest account of what was not covered.
[S1] Harmonic Drive Engineering Data; [S2] UR-Series Service Manual.
Primary-source reading
Harmonic Drive Engineering Data
https://www.harmonicdrive.net/_hd/content/documents1/FBB_DifferentialGear.pdf
UR-Series Service Manual
https://www.universal-robots.com/manuals/EN/PDF/Shared/service-manual_ur-series/Service_Manual_UR-Series_en.pdf