Short answer
Many organizations arrange quality documents in layers: policy and manual at the top, process-level procedures beneath, then work instructions, then forms and records. For robotics data, the middle layers hold task structure and ordering, while the bottom layers hold step detail and evidence. Ask a supplier for a named layer, because each supports a different use and none contains motion data.
Why the hierarchy matters when you buy
"We'd like your SOPs" is an ambiguous request. One company will send a ten-page process description approved by a quality committee. Another will send a one-page laminated card from a workstation. Both are called procedures. They differ in length, in detail, in who is allowed to change them, and in what a training pipeline can extract from them.
A buyer who recognizes the layers can name the layer needed, estimate preparation work and spot gaps. A procurement lead can also see which layer carries confidential process parameters and which is closer to public knowledge.
For the vocabulary used inside the layers, see SOPs vs work instructions vs checklists. This page is about how those documents are organized as a system.
The common four-layer pattern
There is no single required structure. The ISO 9001 standard lists requirements that include documented information, but it describes itself as generic and applicable to any organization, and certification is optional (ISO, 2026). Companies therefore choose their own layout. The pyramid below is a convention many follow, often called levels 1 to 4 or tiers A to D. Names vary, so check how each supplier labels its own layers.
| Layer | Typical content | Typical owner | Value for robotics buyers |
|---|---|---|---|
| 1. Policy and manual | Scope, responsibilities, process map, references to procedures | Quality or executive team | Context and vocabulary; little task detail |
| 2. Process procedures | What happens, in what order, who is responsible, what triggers and ends it | Process owner | Task structure, ordering, roles, success conditions |
| 3. Work instructions | Step-by-step actions at a workstation, parameters, tools, images | Supervisor or engineer | Step detail, objects, tools, constraints |
| 4. Forms, checklists, records | Blank forms and completed evidence of execution | Whoever performs the task | Success criteria; records of what actually happened |
Some firms merge layers 2 and 3, others add a layer for training material or job aids. A few use structured authoring systems where a "data module" is the unit instead of a document; S1000D is one specification built that way for technical publications (ASD).
What each layer can support
Layer 1. Useful for definitions, process maps and the list of what procedures exist. A process map is a cheap way to scope what to ask for next, as covered in procedure coverage mapping. It does not describe executable steps.
Layer 2. The best source for task decomposition and role assignment. A process procedure states preconditions, outcome and handoffs. These documents are where task graphs from procedures are usually built.
Layer 3. The layer closest to what a robot-side planner needs: ordered actions, objects, tools and tolerances. It is also the layer most likely to hold proprietary parameters. See parameters and tolerances extraction.
Layer 4. Blank forms show what a supplier considers evidence of success. Completed ones show what happened in practice, including deviations. They need a different rights review because they can contain names, signatures and customer lots. See completed checklists as execution records.
Regulated settings change what exists
In some industries the existence of a layer is not optional. US drug manufacturing rules, for example, require written production and process-control procedures that are drafted, reviewed and approved by appropriate organizational units and by the quality control unit, with deviations recorded (21 CFR 211.100). A buyer can use that fact in a practical way: a regulated supplier is likely to have approval history and revision control that an unregulated one lacks. It also means the documents may be sensitive and heavily controlled. See regulated procedures. This is not legal advice.
Illustrative request using the hierarchy
The block below is Illustrative. The identifiers and scope are synthetic.
# Illustrative only - not an available package
request: layered_procedure_set_v0
process_area: inbound_receiving # example choice
layers_requested:
- layer: 2_process_procedure
need: ordering, roles, triggers, outcomes
format: structured text or PDF with parsing allowed
- layer: 3_work_instruction
need: steps, tools, objects, tolerances
exclude: customer-specific parameters
- layer: 4_blank_forms
need: success criteria fields
- layer: 4_completed_records
need: sample only; names and signatures removed before delivery
metadata_required: doc_id, revision, effective_date, owner_role, approval_status
How to decide which layer to request
- Scoping which tasks exist: start with layers 1 and 2.
- Building a planning or grounding corpus: layers 2 and 3, with revision history.
- Writing success criteria for evaluation: layer 4 forms plus layer 3 steps.
- Studying drift between written and actual practice: layer 4 completed records, compared with demonstrations. See procedural drift.
What this hierarchy cannot support
Even a complete set of all four layers contains no motion, force or perception data. A document hierarchy describes what the organization intends, not what workers or machines do. It cannot prove that a procedure matches practice, and it cannot teach a robot to execute a step. Physical control needs robot, teleoperation or purpose-built demonstration data. The documents can support task structure, language grounding and evaluation design. The wider limits are set out in what SOPs can and cannot teach a humanoid.
Other gaps to plan for: a controlled document may be superseded by a newer revision, a layer may exist only on paper, and lower layers may reference unwritten tacit knowledge. Ask about who owns each procedure before assuming a document can be licensed.
Questions to ask suppliers
- Which layers does your system have, and what do you call each one?
- Is there a controlled document register with IDs, revision numbers and effective dates?
- Which layers are authored in-house, and which come from customers, vendors or standards bodies?
- Are superseded revisions kept, and can they be delivered with dates?
- Where do process parameters and tolerances live, and which layer can be shared without them?
- Are completed records retained, and for how long?
- Does the system follow a structured authoring format, or are documents free-form files?
- Who can approve licensing of each layer?
Once a layer is chosen, the procedure step schema shows how to structure its content, and the SOP corpus evaluation checklist gives pass/fail checks for what arrives.
Discuss your requirements
If you know which layer of procedure documentation your project needs, describe the layer, process area and permitted uses to SourceX. SourceX reviews the requirement, looks for US businesses that may hold matching documents, checks the data and the supplier's licensing permissions, and follows up about potential sources. A request does not guarantee a match. Start from the humanoid training data guide or the procedures hub to see where this fits, and the catalog category for manufacturing quality records for the nearest existing listing type.
Explore sourcing and licensing options with SourceX
Sources
- ISO 9001:2026 Quality management systems - Requirements — documented information requirement; generic applicability; optional certification.
- 21 CFR 211.100 Written procedures; deviations — example of mandated, quality-approved written procedures.
- S1000D International specification for technical publications using a common source database — example of a data-module approach to technical publications.