Short answer
SOP data for embodied AI is the written procedural knowledge of operating businesses, such as SOPs, work instructions, checklists, training courses and task analyses, prepared for models. It gives a humanoid's planner task structure, ordering, constraints, tools and success checks, and grounds language in real workplace steps. It contains no motion, force or perception data, so it never replaces demonstrations or robot data.
Who this cluster is for
Three kinds of buyer reach this cluster. Planner and VLA teams want real workplace language to ground instructions and decompose long tasks. Evaluation leads want procedural reasoning tests built from procedures that real people follow, not from text a model generated. Data-program leads want SOPs as scripts for commissioned demonstrations, so new video arrives already organized into named steps.
All three are buying the same raw material: documents that businesses already write for training, quality and compliance. It sits in the procedures layer of the humanoid training data guide, next to demonstrations rather than in place of them.
What procedural data includes
| Document type | What it contains | Typical holder |
|---|---|---|
| Standard operating procedures | Purpose, scope, ordered steps, roles, cautions | Quality and operations teams |
| Work instructions, including visual ones | Station-level steps with photos, tools and parameters | Manufacturing and process engineering |
| Checklists and sign-off records | Verification items; completed records show execution | Operations, EHS, facilities |
| LMS courses and assessments | Modules, quizzes, practical-assessment rubrics | Learning teams and course vendors |
| Connected-worker platform exports | Structured steps, images and completion data | Sites using digital SOP tools |
| Task analyses and time studies | Hierarchical task breakdowns, motion-element codes, timings | Industrial engineering, human factors |
| Equipment and exception procedures | Start-up, shutdown, faults, emergencies | Operations and maintenance |
| Franchise operations manuals | Service standards across many sites | Franchisors |
What it can support, and what it cannot
Procedural data is useful wherever a model needs to know what to do and in what order. Published work shows several entry points:
- Grounded planning. In SayCan, a language model proposes steps and the robot's pretrained skills filter them to what is feasible; grounding roughly halved errors against non-grounded baselines (Ichter et al., 2022). Inner Monologue adds closed-loop replanning from success detection and scene descriptions (Huang et al., 2022). Real SOPs can supply the kind of task knowledge and success checks these systems reason over.
- Policy code. Code as Policies has a language model write robot programs that call perception and control APIs (Liang et al., 2022). Procedures with explicit parameters and preconditions make such programs easier to specify and test.
- Instruction following. ALFRED pairs about 25,000 natural-language goals and step instructions with expert demonstrations in simulated households (Shridhar et al., 2019); workplace procedures can seed comparable instruction sets for industrial and service tasks.
- Step structure for video. COIN annotates step-level descriptions with temporal boundaries across 11,827 instructional videos (Tang et al., 2019). An SOP gives the step vocabulary that makes this kind of labeling consistent.
- Visual manuals. IKEA-Manual pairs assembly manuals with 3D parts, assembly plans and 2D-3D correspondences (Wang et al., 2022), showing how illustrated instructions can be tied to geometry.
What procedures cannot do is show a body doing the work. They carry no motion, no forces, no images of the scene from a robot's cameras, and little of the tacit skill a trained worker uses. They also describe intended practice, which can differ from what happens on the floor. Read what SOPs can and cannot teach a humanoid for the full boundary, tacit knowledge gaps for what writers leave out, and procedural drift for the gap between document and practice.
Sourcing routes
Existing assets. Almost all procedural data comes from documents businesses already hold. Ownership is the main complication: procedures copied from equipment makers, written by consultants, or delivered inside a vendor's courseware may not be the holder's to license. See who owns a procedure. Confidential parameters, supplier names and customer details need handling before release; redacting SOPs covers what can be removed without gutting the content.
Preparation. Raw procedures arrive as PDFs, word-processor files, scans and platform exports. Making them usable means layout parsing, step extraction into a schema, and often task graphs or alignment to video. Layout recovery is real work when steps sit in tables, callouts and multi-column pages; human-annotated layout datasets such as DocLayNet, whose six document categories include manuals, are one resource for training the parsers that handle it (Pfitzmann et al., 2022). SourceX's role is sourcing, rights review, licensing and delivery coordination; it can also arrange annotation and engage specialist capture partners, scoped case by case.
Commissioned additions. Two needs usually require new work: collecting how workers actually phrase instructions, and recording demonstrations that follow an SOP step by step. Both bridge into the demonstrations cluster, where instruction-paired demonstration datasets cover video that already has matching procedures.
How to evaluate an SOP corpus
Use these checks on a sample before licensing; thresholds are the buyer's to set.
- Coverage. Map the corpus against your target tasks. Occupational task lists can help scope this: O*NET maps task statements to detailed work activities (O*NET Resource Center).
- Specificity. Count steps that name the object, tool, target state and success check, against steps such as "clean the area."
- Currency. Revision dates, change history and whether superseded versions are marked.
- Consistency. Whether the same task is written the same way across sites and authors.
- Media. Share of steps with photos or diagrams, and whether they are legible after redaction.
- Ownership. Author and source of each document, especially anything copied from manuals or vendor courses.
- Practice match. Whether any evidence, such as completed checklists or deviation reports, shows the procedure is followed.
The full pass/fail version is the SOP corpus evaluation checklist.
Illustrative: what one procedure step yields
# Illustrative only — synthetic procedure, not a supplier document
procedure_id: SOP_HK_014 # guest bathroom reset, site_022
step: 7
text: "Replace towels: two bath, two hand, one mat. Fold bath towels in thirds and hang on the upper bar."
extracted:
action: replace
objects: [bath_towel x2, hand_towel x2, bath_mat x1]
target_state: "bath towels folded in thirds on upper bar"
precondition: "used towels removed (step 6)"
success_check: "count and placement match reference photo P-7"
not_in_the_document:
- how to pick up, spread and fold a towel (motion, deformation)
- how much tension keeps the fold straight (force)
- what a correct fold looks like from the robot's cameras (perception)
The extracted fields can drive a planner, label a matching video segment, or become an evaluation item. The last three lines are why a humanoid program still needs demonstrations and robot data for the same task.
Key pages in this cluster
| Group | Page | What it answers |
|---|---|---|
| Foundations | What SOPs can and cannot teach a humanoid | The keystone limits page for procedures |
| Foundations | SOPs vs work instructions vs checklists | How the document types differ as data |
| Foundations | Tacit knowledge gaps | What written procedures leave out |
| Foundations | Real vs LLM-generated procedures | Why generated text is a weak substitute |
| Foundations | Workplace vs household instruction data | How industrial instructions differ from home tasks |
| Model use | Procedural text for instruction grounding | Sourcing text for VLA instruction grounding |
| Model use | Grounding LLM task planners with SOPs | Feeding procedures to planners |
| Model use | Procedural reasoning evaluation sets | Test sets built from real procedures |
| Model use | Instruction-following evaluation | Evaluating embodied agents on real instructions |
| Model use | Procedures to PDDL or behavior trees | Converting text into executable structure |
| Structuring | Procedure step schema | Fields for a structured step record |
| Structuring | Task graphs from procedures | Steps, dependencies and partial order |
| Structuring | SOP-to-video step alignment | Annotation spec for linking steps to video |
| Structuring | Branching procedures | Decision points and conditional steps |
| Structuring | Preconditions and postconditions | Success checks a planner can test |
| Structuring | Choosing step granularity | Atomic actions vs procedure steps |
| Structuring | SOPs as collection scripts | Scripting commissioned recording from procedures |
| Sources | Visual work instructions | Image-annotated steps for grounding |
| Sources | LMS training courses | Modules, quizzes and assessments |
| Sources | Connected-worker platform exports | Structured steps with execution records |
| Sources | Hierarchical task analyses | Task breakdowns from human factors teams |
| Sources | Predetermined motion time analyses | Motion-element codes as primitive labels |
| Sources | Checklists as success criteria | Verification items as success labels |
| Sources | Natural worker instructions | How workers actually phrase tasks |
| Rights and quality | Who owns a procedure? | Copyright in SOPs, manuals and courses |
| Rights and quality | Evaluating an SOP corpus | Pass/fail checks before licensing |
| Rights and quality | Procedural drift | When documents differ from practice |
| Rights and quality | Redacting SOPs | Removing trade secrets without losing content |
| Rights and quality | Scoring procedure quality | Completeness, specificity and executability |
Neighboring clusters
Procedures pair naturally with other data. Service manuals and troubleshooting guides sit in maintenance and tool use; BOMs, routings and standard work in manufacturing and assembly; warehouse onboarding materials in warehouse and fulfillment. For catalog context on corporate documentation, see SOPs, playbooks and knowledge bases and licensing SOPs and playbooks.
Discuss your requirements
Tell SourceX which tasks, sites and document types you need, the languages, and whether you also need matching video. Describe the procedural data to SourceX and it will investigate whether US businesses hold suitable material, check the supplier's licensing permissions and coordinate the license and delivery. SourceX reviews each requirement and follows up about potential sources; a request does not guarantee a match.
Explore sourcing and licensing options with SourceX
Sources
- Do As I Can, Not As I Say: Grounding Language in Robotic Affordances — language task knowledge filtered by robot skill feasibility.
- Inner Monologue: Embodied Reasoning through Planning with Language Models — closed-loop replanning from language feedback.
- Code as Policies: Language Model Programs for Embodied Control — language models writing robot policy code.
- ALFRED: A Benchmark for Interpreting Grounded Instructions for Everyday Tasks — instructions paired with expert demonstrations in simulation.
- COIN: A Large-scale Dataset for Comprehensive Instructional Video Analysis — step-level descriptions with temporal boundaries.
- IKEA-Manual: Seeing Shape Assembly Step by Step — manuals tied to 3D parts and assembly plans.
- DocLayNet: A Large Human-Annotated Dataset for Document-Layout Analysis — layout annotation including manuals.
- O*NET Database: Task Statements and Detailed Work Activities — occupational task statements for scoping coverage.