Short answer
SOPs can teach a humanoid's planning and language layers what a task is: its steps, order, preconditions, tools, parameters, safety rules and what 'done' looks like. They cannot teach the body how to do it. A procedure contains no motion, force, contact or perception data, so SOPs feed task planners, instruction grounding and evaluation, while physical skills still come from demonstrations and robot data.
Why this matters before you buy procedures
Procedures are among the easiest workplace assets to license in volume. Most businesses keep them in document control, they are text, and they are cheap to deliver. They are also easy to overvalue: a thorough procedure reads like complete knowledge of a task, yet a robot can execute none of it without skills learned from other data.
Programs that budget around SOPs can end up with a well-specified planner and nothing that carries out its plans. This page maps what procedure text feeds and what it leaves empty, so the rest of the procedures cluster can be read with the right expectations.
Where SOP content lands in a humanoid stack
The example text below is illustrative.
| SOP element | Example text | Layer it can feed | What it still needs |
|---|---|---|---|
| Step sequence | "Remove the guard, then isolate power at the panel." | Task decomposition, task graphs, high-level plans | Skills that execute each step |
| Preconditions and checks | "Confirm the line is stopped and the tag is in place." | State checks in a planner; success questions | Perception that recognizes the state |
| Tools and materials | "10 mm socket, torque wrench, two cable ties" | Object grounding; tool selection | Recognition data and grasps for those objects |
| Parameters and tolerances | "Torque to the value on the card"; "hold at temperature" | Targets and constraints for a controller | Sensing that measures the quantity |
| Safety rules | "Never reach past the light curtain." | Constraint layer; safety test cases | Enforcement and testing on the robot |
| Acceptance criteria | "Label level and inside the marked area" | Success labels; evaluation rubrics | Images or measurements to judge against |
| Roles and handoffs | "Quality signs off before release." | Human-robot workflow plans | Interaction data and policies |
Every row in the right-hand column is data a document does not contain.
What published work shows procedure-like text can do
Task knowledge, if skills exist. SayCan pairs a language model's task knowledge with pretrained robot skills that act as its "hands and eyes"; the skills' affordances filter the model's proposals to actions that are feasible in context, and this grounding roughly halves errors compared with non-grounded baselines (Ichter et al., 2022). The language side can come from procedures. The skills cannot.
Programs over existing APIs. Code as Policies has a language model write policy code that calls perception and control APIs (Liang et al., 2022). ProgPrompt generates plans against an explicit list of the robot's available actions and objects (Singh et al., 2022). Both show that a procedure must be translated into the robot's own action vocabulary; see rewriting human procedures for robots.
Checks that become questions. Inner Monologue plans and replans using closed-loop language feedback, including success detection and scene description (Huang et al., 2022). An SOP's acceptance criteria are a natural source of those success questions, but answering them needs a perception model trained on images of the states.
Instruction following needs paired demonstrations. The ALFRED benchmark maps natural-language instructions and egocentric vision to action sequences, and supplies expert demonstrations paired with those instructions as the training signal (Shridhar et al., 2019). The instructions are useful because demonstrations sit next to them.
Where published work improves the visual side of manipulation, it draws on video rather than procedure text. R3M pretrained a visual representation on human video, using language only to shape that representation, and still needed robot demonstrations to learn tasks (Nair et al., 2022). For the full picture of video's role, see what human demonstration video can and cannot do for robot learning.
What SOPs cannot teach
- Motion. Approach direction, posture, two-handed coordination and timing are absent.
- Force and compliance. "Hand-tight", "firmly" and "until it clicks" describe thresholds a worker feels; no text encodes them.
- Perceived states. "Until smooth" and "when the color changes" need images or sensor readings of each state.
- Tacit skill. Experienced workers rely on tricks the document never mentions; tacit knowledge gaps in SOPs covers where these hide.
- Recovery. Most procedures describe the normal path; exceptions are covered thinly or in separate documents.
- Actual practice. Documents and floor practice drift apart, so a procedure can describe work no one does that way anymore.
Illustrative: one step, two sources
# Illustrative only — one procedure step and where each part of it must come from
step: "Thread the fitting by hand until snug, then tighten a quarter turn with the wrench. Check for leaks at startup."
from_the_text:
sequence: hand-thread -> wrench quarter turn -> leak check
tool: open-end wrench (size given on the card)
parameter: quarter turn after snug
success_criterion: no leak at startup
language: verbs and object names for grounding
must_come_from_elsewhere:
fitting_and_thread_state: images of seated vs cross-threaded fittings # perception data
hand_threading_motion: demonstrations with hand pose; robot or teleoperation data # control data
what_snug_feels_like: force/torque or tactile signal # in no document
wrench_grasp_and_placement: tool grasp data; demonstrations # object + control data
leak_check: images or sensor readings of wet vs dry joints # perception data
Everything in the second list has to come from perception, demonstration, robot or force data, not from the SOP.
What this means for buying
| Intended use | Can SOPs alone serve it? | What to add |
|---|---|---|
| Task planning with a language-model planner | Largely | A skill library and the robot's action vocabulary |
| Task taxonomies and coverage planning | Largely | Task frequency from operating records |
| Instruction-following evaluation | Partly | Video or robot episodes to score against |
| Success detection | No | Images of success and failure states |
| Learning a manipulation skill | No | Demonstrations and robot data |
| Safety constraints | Partly | Enforcement and testing on the robot |
Three practical consequences follow. First, buy procedures for planners, grounding and evaluation, and budget separately for demonstrations of every skill they name. Second, if you need language grounded in real footage, source instruction-paired demonstration datasets rather than text alone. Third, check the document type, because SOPs, work instructions and checklists differ in granularity and in how much preparation they need.
For planner-specific use, including how to convert steps into a planner's vocabulary, see grounding LLM planners with SOPs.
Limitations and preparation
Procedures arrive as PDFs, scans and wiki pages. Before they are useful, steps need to be extracted and structured, revisions reconciled, implicit steps written out, and confidential parameters reviewed. None of that preparation adds motion or force data; it only makes the text usable for the layers it can feed.
Questions to ask suppliers
- Which document types do you hold: SOPs, work instructions, checklists, or all three?
- Are steps numbered and structured, or written as prose?
- Which revision is current, and is revision history available?
- Do documents include parameters such as torques, temperatures or times, and are any confidential?
- Do completed checklists or sign-off records exist that show the procedure being executed?
- Is there video, photos or training material tied to the same procedures?
- How closely does floor practice follow the documents, and who audits that?
- Were any procedures copied or adapted from equipment makers or consultants?
Ownership questions in the last item are covered on who owns a procedure.
Discuss your requirements
If you are planning a procedures purchase alongside demonstration data, describe the tasks and the layers you want to feed to SourceX. SourceX looks for US businesses that hold suitable procedures and related material, checks the data and the supplier's licensing permissions, and coordinates the license and delivery. It reviews the request and follows up about potential sources; a request does not guarantee a match. Start from the humanoid training data guide for the other data types, or see the catalog entry for SOPs, playbooks and internal knowledge bases and the page on licensing SOPs and playbooks.
Discuss your humanoid training-data requirements with SourceX
Sources
- Do As I Can, Not As I Say: Grounding Language in Robotic Affordances — language task knowledge grounded by robot skills.
- Code as Policies: Language Model Programs for Embodied Control — language-model code calling perception and control APIs.
- ProgPrompt: Generating Situated Robot Task Plans using Large Language Models — plans constrained to available actions and objects.
- Inner Monologue: Embodied Reasoning through Planning with Language Models — success detection and replanning through language feedback.
- ALFRED: A Benchmark for Interpreting Grounded Instructions for Everyday Tasks — instructions paired with demonstrations.
- R3M: A Universal Visual Representation for Robot Manipulation — visual representation learned from human video.