Short answer
A role-based procedure assigns each step to a named role and records handoffs between them, as in a RACI table, a swimlane process or a two-person checklist. Such documents can support planning for collaborative tasks and dialogue-based coordination. They do not show how roles physically hand over objects, and they contain no robot action data.
The buyer's problem
Most single-agent robot benchmarks assume one actor and one goal. Real workplaces rarely work that way. A hospital room turnover involves a cleaner, a nurse and sometimes a transporter. A restaurant line has stations that pass plates to each other. A machine changeover needs an operator and a technician, and the order they act in matters.
If a humanoid is expected to take one of those roles, or to work next to people who hold the others, the training and evaluation material needs to say who does what, when, and what each party waits for. Role information is often present in procedures but buried in prose: "the second person confirms" or "once QA releases the lot". This page covers how to source documents where it is explicit.
What counts as a role-based procedure
- RACI or responsibility matrices that mark who is responsible, accountable, consulted and informed for each step.
- Swimlane process maps where each lane is a role and arrows show handoffs.
- Two-person or witnessed checklists, such as verifying a lockout or counting a drawer.
- Shift handover procedures that list what the outgoing role must tell the incoming one.
- Escalation paths that state who takes over when a step fails.
- Multi-role SOPs where numbered steps are prefixed with a role name.
A related academic setting is the TEACh benchmark: more than 3,000 human-human dialogues in which a Commander guides a Follower through household tasks in simulation, with the Follower able to ask questions (Padmakumar et al., 2022). It is a research dataset, not workplace material, but it shows the kind of coordination language a role-based corpus can ground: who knows the plan, who acts, and what gets asked.
What this data can support and what it cannot
Role-based procedures can support:
- Task decomposition into per-role subtasks for planners.
- Language models that decide which role they are being asked to take.
- Evaluation of handoff understanding: does a system wait for the right signal before proceeding?
- Allocation-of-function studies. Hierarchical task analysis, the long-standing ergonomics method, lists allocation of function and job aid design among its applications (Stanton, 2006).
- Designing shared human-robot workflows.
They cannot support:
- The physical handoff. Passing a tray, steadying a ladder or lifting together involves timing, force and contact that text does not record. Control training needs robot, teleoperation or instrumented-demonstration data, not SOPs alone.
- Tacit coordination. Experienced teams use glances, nods and shorthand that the written role split omits.
- Real division of labor. Written roles often differ from who actually does the work on a short-staffed shift.
- Safety assurance. A role table does not demonstrate that the robot is safe near people.
Where the role information lives
| Where it appears | Role information | Common problem |
|---|---|---|
| RACI matrix in a procedure | Explicit, per step | Roles are job titles, not individuals |
| Swimlane diagram (image or PDF) | Explicit but visual | Needs diagram parsing to get structure |
| Numbered SOP steps | Implicit in verbs or prefixes | "Ensure" and "verify" hide the actor |
| Training course material | Described in narrative | Mixed with learning objectives |
| Completed checklists | Signatures show who actually did it | Contains names; restricted use |
Illustrative role-annotated step record
The record below is Illustrative. All identifiers and values are synthetic.
# Illustrative only - not an available dataset
procedure_id: proc_0412
title: "Bed turnover, handoff section"
roles:
- id: role_env_services
- id: role_charge_nurse
steps:
- step: 6
text: "Notify the charge nurse that the room is ready for inspection."
actor: role_env_services
handoff_to: role_charge_nurse
trigger: step 5 complete
completion_signal: "verbal confirmation or board update"
- step: 7
text: "Inspect surfaces and release the room."
actor: role_charge_nurse
precondition: step 6 received
on_fail: "return to role_env_services at step 4"
The fields to insist on are actor, handoff_to, trigger and completion_signal. Without them, role information has to be re-inferred from prose, which the buyer should plan to validate.
Acceptance criteria you can set
- Role coverage. What share of steps in a sample carry an explicit actor? Set your own threshold.
- Handoff completeness. Does every transfer name a trigger and a receiving role?
- Role vocabulary. Are roles defined in a glossary, or only mentioned in passing?
- Exceptions. Are failure paths and escalations assigned to roles as well?
- Consistency. Do two documents covering the same task assign the same roles?
Questions to ask suppliers
- Which procedures involve more than one role, and how are roles marked?
- Are roles job titles, departments or named individuals?
- Do swimlane diagrams exist as editable files or only as images?
- Are handoff signals, such as a call, a scan or a signature, written down?
- Do completed records identify individuals, and can those fields be removed before delivery?
- Who reviewed role assignments against actual practice, and when?
- Do the same roles exist across sites, or does each site split work differently?
- Is any content owned by a customer, a union agreement or a third-party standard?
Pitfalls when mining roles from existing documents
Three mistakes recur. The first is treating job titles as roles: "Lead Hand" at one site and "Senior Associate" at another may do the same steps, and a dataset that keeps both labels fragments the same role. Map titles to a small role vocabulary and keep the original title as a field.
The second is losing the concurrency. Steps assigned to two roles may run in parallel, in strict sequence or with one role waiting. Numbered lists flatten that into a single line. Insist on explicit trigger and wait fields, or expect to rebuild them with annotators.
The third is assuming a robot fills one role cleanly. In practice a humanoid may take part of a role, such as fetching and carrying, while a person keeps the judgment steps. Whether that split is acceptable is a safety and operations decision, not something the document can settle.
Permissions and provenance
Role tables can reveal staffing levels, reporting lines and named employees. Ask the supplier whether the documents mention individuals, and whether any employment or union terms limit sharing. Pseudonymizing names is a preparation step, not a substitute for checking who can license the material.
Next steps in the procedures cluster
Role data is most useful once steps are structured, so pair it with the procedure step schema and branching procedures and decision points. Return to the procedures hub or the humanoid training data guide for the full map.
Related reading: task graphs from procedures for representing parallel role lanes, natural worker instructions for how people actually phrase handoffs, and competency assessments and signoffs for which roles are authorized to perform or approve a step.
Discuss your requirements
If your project needs procedures that split work across roles, describe the task family, roles and permitted uses to SourceX. SourceX reviews the requirement and looks for US businesses that may hold suitable documents, checks the data and the supplier's licensing permissions, and follows up about potential sources. A request does not guarantee a match. The catalog category for workflow task histories is the nearest existing listing type.
Discuss your humanoid training-data requirements with SourceX
Sources
- TEACh: Task-driven Embodied Agents that Chat — Commander and Follower dialogues as a coordination benchmark.
- Hierarchical task analysis: Developments, applications, and extensions — allocation of function and job aid design among HTA applications.