Short answer
Branching procedure data represents conditional logic explicitly: a decision point names its inputs, lists outcomes with their conditions, and routes each to a next step, an exception path or a stop. Buyers specify it as structured records, not prose, so planners and evaluators can test whether a model chooses the right branch. It describes intent; it does not prove what workers do.
The buyer's problem
Most written procedures are linear on the surface and conditional underneath. "Check the filter; if clogged, replace it, otherwise continue" is one sentence in a PDF. A model that reads it can paraphrase it, but a planner needs to know what state to test, what counts as clogged, what "continue" points to, and what to do when the test cannot be run. Ordinary step lists lose this. A dataset that keeps conditions as free text makes every downstream user rebuild the logic.
The page covers how to specify branch-aware records. Related layers have their own pages: the state predicates attached to steps are in preconditions, postconditions and success checks, and abnormal or emergency flows in exception and emergency procedures.
Kinds of decision points to label
| Kind | Example phrase | Representation |
|---|---|---|
| Binary condition | "If the gauge reads above the limit, stop" | Test, two outcomes |
| Multi-way selection | "Use the blue form for A, the green for B" | Test with N outcomes |
| Loop or repeat-until | "Wipe until no residue remains" | Loop with exit condition and max iterations |
| Optional step | "If required by the customer, label the box" | Guarded step |
| Parallel or unordered | "Do 3 and 4 in any order" | Unordered group |
| Escalation | "If unsure, call the supervisor" | Handoff outcome |
| Time-based | "Wait 10 minutes, then check" | Timed wait with check |
| Role-dependent | "Operator does X; inspector does Y" | Role guard |
Common traps: conditions hidden in notes or warnings; negations ("do not proceed unless"); references to another document ("per the work order"); and vague tests such as "if necessary" or "as appropriate". Label each vague test as ambiguous rather than inventing a threshold; ambiguous instructions and clarification discusses how to handle them.
What the data can support
- Task planning. Colledanchise and Ogren describe behavior trees as a way to structure switching between tasks in an autonomous agent, yielding modular and reactive systems (Colledanchise and Ogren, 2017). Branches map naturally to fallback and sequence nodes, and the page on procedures to PDDL and behavior trees covers conversion.
- LLM planning with program-like specs. ProgPrompt prompts a language model with available actions and objects as program-like specifications plus example programs, evaluates on VirtualHome household tasks, and was deployed on a physical robot arm for tabletop tasks (Singh et al., 2022). Branch-aware procedures give such prompts real conditionals instead of invented ones.
- Instruction-grounding evaluation. Test items ask "given this state, which branch applies?"
- Deviation detection. A recorded run can be compared to the branch the state required; see deviation reports.
- Procedural question answering. Conditional questions test comprehension beyond step order; see procedural QA for embodied assistants.
What it cannot support
- Physical control. A branch says what to do, not how the hand moves. See what SOPs can and cannot teach a humanoid.
- Tacit judgment. Experienced workers resolve "looks clogged" using cues the document often does not record.
- Proof of practice. A branch in a document may never be used, or may be bypassed. Compare against recorded work where possible.
- Perception of the condition. A branch that depends on an odor, a sound or a surface feel needs sensors a robot may not have.
- Complete coverage. Documents list the branches authors thought of; real work has others.
Source formats
Branches appear in different shapes depending on origin. PDF SOPs embed them in prose and flowcharts. Structured authoring systems may hold them as typed elements. S1000D, an XML-based specification for technical publications, stores procedural content in stand-alone data modules identified by a unique code in a common source database (S1000D), which can make conditional steps easier to extract than from a PDF. Whether any given supplier's export follows it is something to ask, and structured authoring exports discusses the options. For PDFs, see parsing scanned manuals and validating LLM-extracted steps.
Illustrative record schema
# Illustrative only; synthetic content
procedure_id: proc_0042
version: r3
nodes:
- id: n10
type: action
text: "Remove the filter cover"
next: n20
- id: n20
type: decision
text: "Inspect filter element"
inputs:
- {name: filter_condition, observable: visual, values: [clean, clogged, damaged]}
branches:
- {when: "filter_condition == clean", next: n40}
- {when: "filter_condition == clogged", next: n30}
- {when: "filter_condition == damaged", next: n35}
- {when: "cannot_determine", next: n90}
source_span: {page: 4, lines: "12-15"}
ambiguity: none
- id: n30
type: action
text: "Replace the filter with part type F"
next: n40
- id: n35
type: exception
text: "Tag out of service and notify supervisor"
next: end_escalated
- id: n90
type: escalation
text: "Ask supervisor"
next: n20
loops:
- {node: n50, exit_when: "residue_visible == false", max_iterations: 3}
Fields in your own spec will differ. The point is that every decision lists inputs, observability, branches (including "cannot determine") and a pointer back to the source text.
Acceptance tests a buyer can set
- Coverage. Every decision has an outcome for every declared value plus an "unknown" path.
- Reachability. All nodes are reachable from the start and lead to a terminal.
- Traceability. Each node has a source span, so a reviewer can check it against the document.
- Agreement. Two annotators label a sample, and disagreements on branch structure are reported.
- Ambiguity flags. Vague tests are marked, not resolved by guess.
- Held-out sets. Evaluation procedures come from organizations or document families not used in training, as in procedural reasoning evaluation sets.
Rights and redaction
Procedures contain trade secrets: parameters, vendor names, internal part numbers. Redact them before delivery but keep the logic. Redaction should replace a limit with a symbol (limit_A) so branches stay testable; see redacting SOPs and parameters and tolerances extraction. Ask who owns the document, since third-party standards or vendor manuals may be embedded; see who owns a procedure. This is not legal advice.
Questions to ask suppliers
- What formats are the procedures in, and are any available as structured exports?
- How many procedures contain conditional logic, and of what kinds?
- Are flowcharts available, or only prose?
- Who last reviewed each procedure, and how are revisions tracked?
- Do any documents reference other documents for the decision criteria?
- Can parameters be replaced with symbols without breaking the logic?
- Is there evidence, such as deviation or completion records, of which branches occur in practice?
- Which documents embed third-party content?
Discuss your requirements
To specify conditional procedure data for your project, describe the document types, branch structure, formats 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. Structuring and annotation are scoped case by case. A request does not guarantee a match; SourceX follows up about potential sources.
See the humanoid training data guide and the procedural data hub for the wider map. Related catalog entries: SOPs, playbooks and knowledge bases and SOPs and playbooks as a buying category. Also see task graphs from procedures and the procedure step schema.
Discuss your humanoid training-data requirements with SourceX
Sources
- Behavior Trees in Robotics and AI: An Introduction — Behavior trees as a modular, reactive way to structure task switching
- ProgPrompt: Generating Situated Robot Task Plans using Large Language Models — Program-like plan specifications listing available actions and objects
- S1000D International specification for technical publications using a common source database — Data-module structure for procedural technical publications