Short answer
A human procedure assumes a reader who sees, judges and improvises. A robot needs conditions it can perceive, parameters stated numerically, steps mapped to skills it actually has, and explicit handoffs when it cannot proceed. Rewriting adds those elements and removes implicit judgment; it is a separate, reviewed step, not something a licensed document arrives with.
The gap between a human reader and a robot executor
Procedures are written for people who share background. "Wipe the counter until clean" works because the reader knows what clean looks like, how hard to press, when the cloth is too dirty, and what to do about a sticky spot. None of this is on the page.
A robot system consumes a procedure differently. In published language-model planning work, the model supplies task knowledge and the robot's pretrained skills decide which proposed actions are feasible in the current context; in SayCan the evaluation used a mobile manipulator in a real kitchen (Ichter et al., 2022). In another approach, code-writing language models turn natural-language commands into policy code that calls perception and control APIs, and the work demonstrates this on several real robot platforms (Liang et al., 2022). In both, the procedure text meets a fixed vocabulary of things the robot can do and see. Anything in the text that falls outside that vocabulary has to be removed, replaced or handled by a person.
That is the core of rewriting: translating from human-readable intent to the robot's available skills, sensors and limits. This page explains the changes. The question of what an SOP can teach at all is in what SOPs can and cannot teach a humanoid.
What changes when the executor is a robot
| Human procedure says | Problem for a robot | Rewrite toward |
|---|---|---|
| "Until it looks clean" | No perceivable criterion | A measurable or classifiable condition, or a handoff to a person |
| "Gently place" | Not a parameter | Speed, force or height limits the control stack can use, if known |
| "Use the usual cart" | Undefined reference | A named object, location or marker |
| "Check it is safe" | Judgment | An explicit sensor check or an escalation step |
| "Wear gloves" | Not applicable | Remove, or replace with an equivalent constraint |
| "Ask the supervisor if unsure" | Needs a communication channel | A defined stop condition and who is notified |
| "Fold the towel in thirds" | May exceed the robot's skills | Mapped to an available skill or marked unsupported |
The right-hand column is not a recipe; it depends on the robot, its sensors and its skill set. A buyer should treat the left column as the thing to look for in a corpus, and the right column as work to plan for.
Four kinds of edit
Perceivable conditions. Each precondition and success check must be something the robot's perception can determine. If it cannot, the step needs a person, a tool or a changed design of the environment. See preconditions and postconditions.
Parameters. Quantities that a person infers become explicit values or ranges with units. Sources are the business's own specifications, equipment documents or measurements; parameter and tolerance extraction covers where those live.
Skill mapping. Each step is mapped to a skill the robot has, to a composition of skills, or to "unsupported". Steps the robot does not have a skill for are the useful output of the exercise: they define what to collect. Structured targets such as PDDL or behavior trees are common ways to record the mapping.
Handoffs and exceptions. Add what the robot does when preconditions fail, an object is missing or something unexpected happens. Human procedures leave this to judgment; see branching procedures and decision points and exception and emergency procedures.
Controlled language as a starting point
Controlled languages make sentences less ambiguous, which helps both human reviewers and software. ASD-STE100 is a controlled natural language and international standard for writing technical documentation; Issue 9 is dated 15 January 2025 (ASD-STE100). A source procedure written this way is easier to parse into steps. It is still written for people, so the rewrite is still needed. See controlled-language procedures.
Illustrative before-and-after
# Illustrative only - synthetic procedure, not from any source
HUMAN: "Clear the table and wipe it down. Make sure it is dry before
the next guests sit."
ROBOT-ORIENTED (draft for human review):
precondition: table_zone_T3 visible; no person within 1.0 m
1. For each item on table_zone_T3 classified as dishware:
move to bus_tray_B; if item not graspable -> stop, notify staff.
2. Apply wipe_skill to table_zone_T3 using cloth_C1, pattern=raster.
3. Check: surface_dry_classifier(table_zone_T3) == dry;
if not after 2 passes -> stop, notify staff.
postcondition: no objects on table_zone_T3; surface dry
unsupported: items classified "unknown" -> handoff
The rewrite is longer than the original. The added length is the conditions, checks and handoffs that the human reader supplied silently.
Limitations
A rewritten procedure is still text. It contains no motion, force or perception data, and the skills it names must come from robot data, simulation or teleoperation. Automated rewriting by language models can introduce plausible but wrong parameters, so rewritten steps need review by someone who knows the task; see validating LLM-extracted steps.
Rewrites are specific to a robot and site. A version that fits one humanoid's hands, reach and sensors may not fit another, and a buyer should not expect a licensed corpus to arrive in robot-executable form. Where robots and people share a workflow, the human steps should be kept and labeled, as in shared human-robot workflow procedures.
Who does the rewriting
Rewriting needs two kinds of knowledge that seldom sit in one person: the task as practiced, and the robot's skills, sensors and limits. A task expert can say what "clean" means at a given site but not whether the perception stack can detect it. A robotics engineer can say what is detectable but not which deviations matter. Plan for a review loop between them, and keep the original human text next to the rewrite so changes can be audited.
If a language model drafts the rewrite, treat the output as a proposal and check it against the grounding approach in grounding LLM planners with SOPs: a step that names a skill the robot lacks should fail a check, not pass quietly into a plan.
What to buy for this purpose
Useful inputs are documents that already contain explicit conditions, quantities and exceptions, together with the context needed to fill gaps: equipment specifications, parts lists, photos, layout drawings and recordings of the task. A supplier that can provide a procedure alongside matched demonstration video gives a reviewer something to check the text against. Buy the rewriting capability separately from the data; it is typically done by the buyer's own team or a specialist.
Questions to ask suppliers
- Which conditions in your procedures depend on judgment, such as "clean" or "adequate"?
- Are quantities, settings and tolerances written down, and where do they come from?
- Do procedures name objects and locations unambiguously, or by habit and nickname?
- Do documents describe what to do when a check fails?
- Are there linked photos, diagrams, specifications or recordings that explain the steps?
- Does any procedure already assume equipment or automation, and how is it documented?
- Were any documents rewritten by software, and was the result reviewed by someone who does the job?
- Can you identify procedures that people and machines already share, such as with automated equipment?
- Who at the supplier could answer questions about unclear steps?
Discuss your requirements
If you are planning to translate procedures for a robot stack and need source material with enough detail to do so, describe the task domain, document types and permitted uses to SourceX. SourceX looks for US businesses that hold suitable material, checks the data and the supplier's licensing permissions, and coordinates the license and delivery. A request does not guarantee a match; SourceX follows up about potential sources. Start at the humanoid training data guide or the procedures hub, and see the site's page on robotics and embodied AI data.
Discuss your humanoid training-data requirements with SourceX
Sources
- Do As I Can, Not As I Say: Grounding Language in Robotic Affordances — language model proposals constrained by robot skills.
- Code as Policies: Language Model Programs for Embodied Control — natural-language commands turned into policy code over perception and control APIs.
- ASD-STE100 Simplified Technical English — controlled language standard for technical documentation.