Preconditions, Postconditions and Success Checks in Procedure Data

The buyer's problem

SOP text is written for people who fill in the gaps. "Tighten the cover" assumes the cover is on, the screws are present and the tool is in hand. "Verify the seal" assumes you know what a good seal looks like. A planner or a language-model agent needs these assumptions written as conditions it can check against the world state, or it will issue steps in the wrong state.

State conditions connect procedures to two systems. Planners use them to decide whether an action is applicable. Success detectors and evaluators use them to decide whether a step worked. Without them, a procedure dataset is a list of sentences.

How published planning work uses conditions

Three lines of work show where state conditions sit in a language-model planning stack.

• Feasibility via skills. SayCan constrains a language model's proposals to actions that pretrained robot skills can do in the current context; the language model contributes task knowledge, and the robot supplies the "hands and eyes". It was evaluated with a mobile manipulator in a real kitchen, and the authors report that grounding roughly halves errors versus non-grounded baselines (Ichter et al., 2022). Preconditions are the written form of "can this skill run now?".
• Success feedback. Inner Monologue lets a language model plan and replan using closed-loop natural-language feedback from the environment, with sources including success detection, scene description and human interaction, without additional training (Huang et al., 2022). Postconditions define what success detection should check.
• Program-style specs. ProgPrompt gives the model the available actions and objects as program-like specifications plus example programs, and was deployed on a physical robot arm for tabletop tasks (Singh et al., 2022). Assertions in such programs correspond to precondition checks.

PDDL formalizes the same idea for classical planners. Version 1.2 specifies the syntax of the language and, less formally, its semantics (McDermott et al., 1998). The conversion from annotated steps is covered in procedures to PDDL and behavior trees; this page defines the data you need before converting.

Condition types to label

Many conditions are implicit. Mark each as explicit (stated in the text), implied (an annotator inferred it) or external (comes from another document). Do not mix them without flags; an evaluator should be able to score explicit conditions separately from inferred ones.

What the data can support — and what it cannot

It can support:

• Applicability checks in task planners and agent frameworks.
• Success and progress detection design, by listing what to observe after each step.
• Language-grounded evaluation: "given this state, can step 4 run?"
• Step-ordering validation, since a postcondition of one step should satisfy the precondition of the next; see task graphs from procedures.
• Better checklists as success criteria.

It cannot support:

• Physical control. Knowing gasket_seated is the goal does not teach the motion. See what SOPs can and cannot teach a humanoid.
• Perception. A condition is only usable if a sensor can observe it. bolt_torqued may need a tool log, not a camera.
• Truth about practice. The procedure may say a check is done; the worker may skip it.
• Complete state models. Free-text procedures state a fraction of the world state. Planners built on partial conditions will propose unsafe or impossible plans unless the missing ones are added.

Observability tagging

The most useful addition beyond logic is a tag for how a condition could be sensed.

This tag turns a procedure into a requirements list for sensors and integrations.

Illustrative annotated step

# Illustrative only; synthetic content
step_id: s07
text: "Install the access panel and secure with four screws"
preconditions:
  - {id: p1, expr: "panel_available", kind: resource, origin: implied, observable: vision}
  - {id: p2, expr: "opening_clear", kind: state, origin: implied, observable: vision}
  - {id: p3, expr: "equipment_isolated", kind: authorization, origin: external, source: "isolation_record", observable: human_attestation}
effects:
  - {id: e1, expr: "panel_installed", origin: explicit}
  - {id: e2, expr: "screws_fastened == 4", origin: explicit}
success_check:
  - {expr: "panel_flush", method: visual, tolerance: "set by buyer"}
  - {expr: "screws_fastened == 4", method: count_visual_or_tool_log}
failure_signals: ["gap_visible", "screw_missing"]
annotator: ann_07; reviewer: rev_02; agreement: agreed

Acceptance tests

• Chain consistency. For a linear procedure, each step's preconditions are satisfied by earlier effects or by declared initial state.
• Origin flags present. Every condition has an origin; the share inferred rather than explicit is reported.
• Observability coverage. Every success check carries an observable tag.
• Sample audit. A reviewer replays a sample of steps and verifies conditions against the source text.
• Inter-annotator agreement. Report it separately for preconditions, effects and success checks; they differ in difficulty.
• LLM-extracted conditions are validated before use; see validating LLM-extracted steps.

Supplier and rights considerations

Operating businesses hold the source documents in quality, operations and documentation teams. Annotators can add conditions, but domain reviewers should confirm them, since a wrong precondition can be worse than a missing one. Sources may carry trade secrets, vendor-owned content and numeric limits; redact parameters with symbols so logic stays testable. See redacting SOPs and who owns a procedure. This is not legal advice. Related branch logic belongs in branching procedures and decision points.

Questions to ask suppliers

1. Do your procedures state starting conditions, or do they assume them?
2. Are success criteria written per step, or only at the end?
3. Which checks depend on instruments or records rather than a person's eye?
4. Are there checklists or sign-off sheets that could supply success checks?
5. Which equipment has logs that could confirm postconditions?
6. Who can review inferred conditions for correctness?
7. Which documents rely on other documents for their conditions?
8. How are revisions tracked, so conditions match the version?

Discuss your requirements

To specify condition-annotated procedure data, describe the documents, fields, 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. SourceX can arrange annotation, 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. Related catalog entries: SOPs, playbooks and knowledge bases and robotics and embodied AI use cases.

Discuss your humanoid training-data requirements with SourceX

Sources

• Do As I Can, Not As I Say: Grounding Language in Robotic Affordances — Skill affordances constrain LLM proposals to feasible actions
• Inner Monologue: Embodied Reasoning through Planning with Language Models — Closed-loop feedback including success detection for LLM planning
• ProgPrompt: Generating Situated Robot Task Plans using Large Language Models — Program-like specifications of actions and objects for plan generation
• PDDL - The Planning Domain Definition Language (Version 1.2) — PDDL syntax for preconditions and effects in planning domains