Short answer
Facilities that run collaborative robots already write procedures that say which steps a person performs, which the machine performs, and where they hand over or stop. Those documents can ground task allocation, handover points and hold conditions for a humanoid. They describe fixed-arm cells, carry no motion data, and do not demonstrate that a humanoid would be safe in the same workflow.
What is unusual about these documents
Most SOPs assume a human does every step. A shared-workflow procedure breaks that assumption: each step has an owner, and the document must say what the other party does while it happens. Where a screwdriving cobot tightens fasteners while a technician loads the next fixture, the procedure encodes parallelism, handovers, interlocks and who may enter the zone. That is the kind of content a humanoid planner may need if it is placed into a mixed line.
Few corpora contain it. Allocation of steps between people and machines is a design decision usually made once per cell and recorded in work instructions, risk assessments and integrator documentation. If a facility has already done that work for a cobot, the artifact may be reusable as a pattern. For the general limits of procedure text, start with what SOPs can and cannot teach a humanoid.
The standards behind the wording
Two ISO documents shape how collaborative cells are described. ISO/TS 15066 is a technical specification, first published in 2016, covering collaborative industrial robot systems and their work environment, and it supplements the ISO 10218 series (ISO, 2016). ISO 10218-1 is the safety standard for industrial robots as partly completed machinery; its third edition appeared in February 2025 and replaced the 2011 edition, covering inherently safe design, risk reduction and information for use (ISO, 2025).
Documents in a supplier's archive may cite either, or an older edition, so ask which one governed the cell when the procedure was written. Also check the current status of any specification; the ISO page for the 2016 document carries a note that it is to be revised. These standards are written for industrial robots, and nothing in this page implies they cover a humanoid in a workspace with people. Whether and how safety requirements apply to a humanoid is a question for the buyer's safety engineers and counsel, not something SOP text can answer.
Where to find them
The documents sit in different places depending on who built the cell. A facility that integrated a cobot itself keeps work instructions with its operations team; one that used an integrator may hold only the final operator manual while the integrator keeps the design files. Operating instructions for the machine itself, covered in equipment operating procedures, are a related but narrower document: they describe how to run the robot, not how a person and robot divide a task.
Training records for the people who work beside the cell can also reveal the allocation, since a course may walk through each step and who does it.
What to look for in a shared-workflow procedure
| Content | Why it helps a planner | Where it usually sits |
|---|---|---|
| Step owner (person, robot, either) | Learn allocation patterns and what stays human | Work instruction table |
| Handover points | Where object custody changes hands | Step notes, figures |
| Hold and release conditions | When a step may start or must stop | Interlock descriptions |
| Zone and access rules | Who may be where during a step | Risk assessment, floor markings |
| Recovery from faults | What a person does when the robot stops | Exception procedures |
| Changeover instructions | How the cell is reset between products | Setup sheets |
Because exceptions are central, pair this material with exception and emergency procedures and the labeling approach in safety-critical steps in procedures.
Illustrative allocation record
The record is Illustrative; the values are synthetic and do not describe any real cell.
# Illustrative: one step of a shared-workflow procedure
procedure_id: SOP-site_040-0212
step: "6"
description: "Fasten housing screws"
owner: robot
parallel_human_step: "7 (load next fixture)"
precondition: "fixture clamped; zone sensor clear"
handover_in: "technician places housing, step 5"
handover_out: null
hold_condition: "technician enters zone_2 -> robot pauses"
resume_condition: "zone clear + start confirmation by technician"
fault_branch: "SOP-site_040-0212/F3"
standard_cited: ["ISO/TS 15066"] # as written in the document
Notice the standard_cited field copies the document's own reference. It records what the supplier wrote, not whether the cell met it.
Use alongside task analysis
A procedure with step owners becomes more useful once structured. Hierarchical task analyses and task graphs from procedures describe how to extract subgoals and dependencies. For shared workflows, add an owner attribute at every node and mark nodes that require a person to confirm before the machine proceeds. The result is an allocation graph a planner can be evaluated against.
Cells that run on production lines also fall within the wider manufacturing and assembly data cluster, where equipment records and quality data may complement the procedures.
What this data cannot support
These procedures cannot train a humanoid to move. They contain no joint states, end-effector paths or contact information; a cobot's trajectory is programmed in a controller, not described in a work instruction. A humanoid's control policy still needs robot or teleoperation data. Procedures and footage alone cannot supply it.
Other limits to state plainly:
- Embodiment mismatch. Allocation that suits a fixed arm with a defined reach may not transfer to a mobile, bipedal platform with different failure modes.
- Safety evidence. A procedure that says the robot pauses when a person enters a zone does not show that a different robot will, or that the rule is adequate. Safety validation belongs to engineering and certification processes, and this page draws no safety-compliance conclusion.
- Paper versus practice. Actual practice can drift from the written procedure, including around interlocks. See procedural drift for how to look for evidence.
- Sparse supply. Documents of this kind are unevenly distributed and often held by integrators, not the facility.
Permissions and provenance
Shared-workflow procedures disclose cell design, throughput assumptions, safety zones and sometimes the robot vendor's guidance. Integrators may own parts of the documentation. Safety assessments may be confidential for good reason. Redaction choices are described in redacting SOPs, but removing names does not settle who may license the content.
Questions to ask suppliers
- Which documents assign steps to people and to machines, and who wrote them?
- Which edition of ISO 10218 or ISO/TS 15066, if any, did the cell design cite?
- Were the documents written by the facility, by an integrator or by the robot vendor?
- Do procedures cover fault recovery and restart, or only the normal cycle?
- Are risk assessments included, separate from the work instructions?
- Which robot type does each procedure assume, and is the cell fixed-arm, mobile or mixed?
- Can step ownership and hold conditions be shared without cell layouts and vendor part numbers?
- Have the procedures been revised since commissioning, and are earlier versions kept?
Discuss your requirements
If shared-workflow procedures belong in your data plan, describe the industry, robot types, document kinds and rights you need through a buyer request. SourceX reviews the requirement and follows up about potential sources; a request does not guarantee a match. See also the procedures hub and the humanoid training-data section.
Explore sourcing and licensing options with SourceX.
Sources
- ISO/TS 15066:2016 Robots and robotic devices — Collaborative robots — collaborative robot systems; supplements ISO 10218; flagged for revision.
- ISO 10218-1:2025 Robotics — Safety requirements — Part 1: Industrial robots — third edition (February 2025) for industrial robots.