ISO 10218 requirements management should preserve the boundary between the supplied industrial robot and the integrated application or cell. Use separate requirement and evidence records for those scopes, then connect the supplier’s demonstrated claims and conditions to the integrator’s acceptance work. A shared reference to a standard is not enough to show that either side has understood the handoff.
This guide is for robot product leads, cell systems engineers and integration managers preparing a supplier review or commissioning handover. Its deliverable is a robot-to-cell responsibility and evidence matrix. The matrix helps a team identify which claims arrive with the robot, which depend on the application and which remain unresolved between organisations.
Understand the two public scopes
The public ISO 10218-1:2025 catalogue scope addresses inherently safe design, risk reduction measures and information for use of robots for an industrial environment. It describes the robot as an incomplete machine and points to Part 2 for integration and application requirements.
The public ISO 10218-2:2025 catalogue scope addresses integration of industrial robot applications and cells. It names design, integration, commissioning, operation, maintenance, decommissioning and disposal, together with integration of machines and components and information for use.
Those scope statements support organising the project around a meaningful supply and application boundary. They do not provide a complete allocation of duties to each contractual role. Obtain and assess the full applicable documents before assigning normative clause obligations. Manufacturer, supplier and integrator responsibilities also need to reflect what each organisation actually designs and supplies.
Check application scope early. The public descriptions include excluded uses and hazards, including mobility-related hazards in some mobile arrangements. If your system combines an industrial manipulator with a mobile platform, a single Part 1 or Part 2 reference cannot resolve every hazard or applicable source. Retain the boundary question for the responsible engineering and standards reviewers.
Record edition, adoption and authority separately
The EVS catalogue pages reviewed on 26 October 2026 identify the 2025 parts and show their ISO identifier records as valid from 5 February 2025. Their related records also distinguish regional and national adoptions. Use the actual designation in the source register rather than shortening every record to “ISO 10218”. A comparison or supplier review needs to know precisely which text was used.
Record why that text governs the project: an applicable contract, a design decision, a legal assessment or another authorised source. If different suppliers use different editions, identify the difference and obtain a decision about how to assess their evidence. Neither “latest” nor a familiar supplier template resolves that decision.
ISO publication is separate from EU harmonisation. The Commission’s machinery standards page describes Official Journal publication and withdrawal of references through implementing decisions. Check the applicable legal record, restrictions and effectivity when a presumption of conformity matters. This guide does not assert current harmonisation for either 2025 part.
Use the machinery regulation guide for the market-date and conformity-route review. Keep its release decisions connected to the source register, while this matrix concentrates on what crosses the robot-to-cell handoff.
Define the supplied and integrated configurations
Identify the supplied robot, controller, software, options and accompanying information that belong to the supplier claim. Define the integrated application separately, including its end-effector, workpiece, layout, interfaces and other consequential equipment. The exact configuration fields should follow the actual engineering dependencies.
Make supplier conditions explicit. A claim may depend on a controller option, approved parameter set, stated operating conditions or a particular interface. The receiving organisation needs to determine whether the cell meets those conditions. A document title or declaration alone does not show that the installed arrangement matches the supported scope.
Also record integration decisions that can change the validity of a robot-level claim. End-effector behaviour, payload assumptions, application modes and connections to neighbouring equipment are examples of questions to assess. Their relevance depends on the application. Do not invent a universal acceptance rule for them from a public abstract.
Build the responsibility and evidence matrix
The table below is a proposed engineering handoff method. Its rows should be populated from reviewed requirements and agreements. It is not an extracted manufacturer-versus-integrator clause matrix.
| Handoff element | Supplier-side record | Receiving application record |
|---|---|---|
| Claim and authority | Supported robot claim, exact applicable source and supplied configuration | Application requirement and the reason the supplier claim is relevant |
| Conditions and limits | Conditions under which evidence may be used, excluded scope and unresolved questions | How the installed application establishes each condition and who owns it |
| Interface responsibility | Supplied behaviour, information and interface assumptions | Receiving behaviour, allocated requirements and agreed interface ownership |
| Evidence | Result or analysis, tested configuration, method and limitations | Applicability decision and additional integration evidence needed |
| Lifecycle handoff | Information supplied for the relevant stage and identified restrictions | Commissioning, operation or maintenance work that relies on that information |
| Review disposition | Named owner and response to questions | Accepted scope, open action, receiving authority and decision context |
| Change effectivity | Changes that alter the supplied claim or its conditions | Affected application baseline and required evidence reassessment |
A useful matrix has a receiving decision for each consequential handoff. “Supplier evidence received” is an administrative state. “Evidence applicable to the installed configuration” is an engineering disposition. Keep those states separate so a document upload cannot silently close application verification.
Assign one owner to resolve each open interface question, even where several organisations contribute. Record the decision authority separately from the action owner. The person requesting an additional test may not be the person authorised to accept the resulting evidence.
Review gaps at the boundary
Look for three recurring gaps. The first is a claim with no stated conditions. The second is a condition that nobody has agreed to establish. The third is evidence whose configuration does not match the application and has no reviewed applicability argument. These are different problems and need different closure work.
Ask what new behaviour integration creates. A robot result can be relevant to a cell requirement while covering only one part of its behaviour. A workpiece-handling claim may also depend on the end-effector and process arrangement. Record the additional requirements and evidence rather than stretching the supplier report to cover them.
Keep the lifecycle stage explicit. Information sufficient for design may leave commissioning work outstanding. A maintenance procedure may require a mode or access arrangement that was not part of production-cycle testing. Select review work against the stage being approved, using the actual applicable sources.
Use the robotics hazard-to-requirement guide to develop the risk-control chain. The handoff matrix begins with the resulting scope and requirements. It does not repeat that hazard-analysis process or infer its conclusions.
Worked example: a proposed press-tending cell handoff
The following example is entirely fictional and unexecuted. Project ORBIT-6 proposes a robot for a press-tending application. Supplied robot configuration OR-R3 would be integrated into cell baseline OR-C8 with end-effector EO-12 and interface specification IF-7. The records illustrate acceptance gaps and decision logic. They are not supplier results or evidence that the cell is safe.
| Handoff | Proposed responsibility and evidence | Receiving decision still needed |
|---|---|---|
| HAND-21: robot function claim | Supplier would provide the claim, OR-R3 scope and its supporting result references. | The cell lead must review applicability to OR-C8 and record which application requirement is supported. |
| HAND-22: end-effector condition | Integrator owns EO-12 and the application evidence for retaining the workpiece during the relevant modes. | A robot-level claim cannot close the end-effector requirement without its own reviewed evidence. |
| HAND-23: press interface | Supplier and integrator would agree the robot-side signal behaviour. Press-system responsibility is a separate allocation. | Gap OR-G05 holds the integrated sequence claim until both sides of IF-7 and their acceptance work are defined. |
| HAND-24: maintenance information | Supplier provides robot information. Integrator defines the cell-specific arrangement that uses it. | Review must establish whether the planned cell procedure accounts for the integrated equipment and access conditions. |
| HAND-25: controller option change | A proposed option revision would change supplied configuration OR-R3 to OR-R4. | Change OR-CH3 identifies affected claims and evidence before the cell baseline can receive a disposition. |
The matrix makes an honest outcome possible even before testing. OR-G05 remains open because the integrated sequence has an unresolved responsibility boundary. HAND-22 requires end-effector evidence. HAND-25 requires an applicability review. No number of received robot documents substitutes for those decisions.
If the project later executes its planned work, retain the actual result configuration and receiving review. A conditional acceptance should identify its allowed scope and unresolved work. This fictional example contains no executed evidence and grants no permission to operate.
Preserve evidence through integration changes
Changes to the controller, tooling, process, layout, interfaces or approved operating modes can affect a handoff claim. Identify the changed configuration, trace it to the conditions and receiving requirements and ask each owner what evidence remains applicable. Preserve historical results with their original context.
Where evidence is retained, record the rationale and the authority that accepted its continued use. Where new evidence is needed, give the work an owner and a defined closure criterion. Avoid a single “2025 update complete” state that hides unresolved application questions.
The robotics change-impact guide provides the broader dependency review, while the configuration-evidence guide explains how to retain result context. This matrix supplies the cross-organisation handoff that those reviews need.
Manage the handoff in Arc
Arc’s public traceability capability connects requirements, interfaces, verification records and evidence, with coverage and impact views. A team can configure handoff records and ownership in the programme model, then connect each supplier claim to its receiving requirement and decision. The team maintains those relationships and applicability rules.
Attributable reviews preserve reviewer identity, decision, timestamp and reviewed context. Controlled changes preserve proposed differences and the receiving baseline. These features support review records. The programme remains responsible for clause assessment, supplied-product acceptance and cell safety decisions.
Evaluate one supplier claim and receiving requirement
Bring one supplier claim, its stated conditions, one receiving application requirement and a proposed integration change to an Arc demo. Configure the handoff row, inspect the evidence scope and trace the change to the affected records. Ask the receiving reviewer to identify one accepted dependency and one open condition.
The exercise is useful when another engineer can reconstruct who supplied the claim, why it applies and which decision remains outstanding. Agree evaluation scope and data handling before adding programme or supplier information.
Sources and method
Arc prepared this educational guide and sells requirements management and systems engineering software.
Prepared on 26 October 2026 from the EVS public catalogue scopes for both 2025 ISO parts, the Commission’s machinery standards process page and Arc’s current canonical capability-page source. The full paid standards were not obtained. No clause-level duty matrix or current harmonisation status is claimed. The ORBIT-6 example is fictional and unexecuted. Arc capability records retain their public review date of 4 September 2026.
Frequently asked questions
What is the difference between ISO 10218-1 and ISO 10218-2:2025?
The public scope for Part 1 addresses industrial robots, including robot design, risk reduction and information for use. Part 2 addresses integration of industrial robot applications and cells across their lifecycle. Use the full applicable editions to assess the requirements for your supply and application boundaries.
Can robot-level evidence close all cell requirements?
No. Review what the evidence demonstrates and which assumptions it relies on. Application integration, end-effectors, neighbouring equipment and installed interfaces may create additional claims and verification work. Record the handoff conditions and the receiving owner’s disposition.
Does ISO publication establish EU harmonisation?
No. Publication identifies the standard edition. Any EU presumption of conformity depends on the relevant legal framework and the published Official Journal reference, including applicable restrictions and dates. This guide does not establish current harmonisation status for either 2025 part.
Does this worksheet allocate the standards’ normative responsibilities?
No. It is an editorial method for managing project responsibility and evidence handoffs. The engineering team must assess the full applicable sources, contracts and supply arrangements before assigning normative obligations. The public scope does not provide a clause-by-clause responsibility matrix.
What should a robot-to-cell evidence handoff contain?
Retain the supplied configuration, source edition, supported claim, limits and assumptions, receiving requirement, evidence owner and receiving reviewer’s decision. Keep open actions visible and identify the changes that would require the handoff to be reviewed again.