Lesson 3.3.1 — LLM Task Planning and Decomposition

Week 23

Prerequisite lessons: 3.2.3 (planning with world models), 3.1.4 (VLA fine-tuning), 2.3.2 (motion planning for manipulation), 1.1.4 (the full-stack pick-and-place pipeline), 2.1.2 (object detection and 6D pose estimation).

Prior results used in this lesson. From 3.2.3: the receding-horizon planner, the four safety checks, and the model flag; the planner produces action sequences given a goal state, and the goal state is what the LLM must supply. From 3.1.4: the VLA as the task layer and the decision conjunction; the LLM is the layer above the VLA, and the conjunction includes it. From 2.3.2: the feasible set with clearance margins. From 1.1.4: the seven-stage state machine. From 2.1.2: the 6D pose estimate as the grounding signal. Each is restated at the point of use.

What this lesson hands forward. The task-network formalism, the LLM-as-decomposer pattern, the grounding layer, and the verification layer. Lesson 3.3.2 (code-as-policies) uses the decomposition as the program skeleton. Lesson 3.3.3 (grounding language to affordances) deepens the grounding layer. Lesson 3.3.4 (safety and constraints) uses the verification layer. Module 4.2 composes the reasoning layer with the policy layer.

The running case in one sentence. The running arm, gripper, eye-in-hand camera, table, cube, bin, and divider are unchanged; the instruction is now a natural-language conditional — “put the cube in the bin, but if the divider is in the way, put it in the second bin” — and this lesson asks how an LLM turns that sentence into a sequence of goals the 3.2.3 planner can execute.

§L.0 — Lesson map, objectives, and misconceptions

Observable outcomes. By the end of this lesson you can, without notes: (1) state the task-planning problem and why neither a classical planner nor an LLM alone solves it; (2) write an HTN decomposition and identify its preconditions and subtasks; (3) write a PDDL problem and its operators for the running case; (4) describe the LLM-as-planner pattern and its two failure modes; (5) state the grounding stack from language to pose and identify the ambiguity at each layer; (6) verify a plan against the robot’s model and against the 3.2.3 planner’s feasibility; (7) diagnose the four reasoning-layer failure modes from their signatures; (8) apply the propose–dispose–execute–monitor composition; (9) decompose the running case’s conditional instruction into a task graph with two branches; (10) design the DECOMPOSE state in the 1.1.4 state machine with its health checks.

Misconception inventory.

Everything is self-contained. Where a prerequisite lesson is used, the result is restated at the point of use.

§L.0.5 — Retrieval warm-up

Q1. In 3.2.3, the planner maximizes a predicted return over action sequences subject to feasibility. What input does it require that the reasoning layer must supply?

Answer. A goal state — the state the return is measured against — plus the feasibility constraints; the planner does not decide what to achieve, only how to achieve a specified goal. Used in §L.A.1 to define the reasoning layer’s deliverable.

Q2. In 3.1.4, the decision to deploy a VLA was a conjunction of necessary conditions including the offline gate, the safety gate, and the shadow deployment. How does the reasoning layer’s decision relate to that conjunction?

Answer. The reasoning layer’s plan is checked by the same gates, but at a higher level: the plan’s goal must be reachable, and the plan’s actions must pass the safety checks before the VLA or the planner executes. Used in §L.D.2 to place the verification in the pipeline.

Q3. In 2.3.2, the motion planner returns a collision-free path with a clearance margin. What does that planner assume about the goal?

Answer. It assumes a Cartesian goal pose; it does not decide which bin or which object the goal refers to, which is precisely the reasoning layer’s job. Used in §L.C.1.

Q4. In 1.1.4, the state machine has seven stages with health checks at each boundary. What would a reasoning layer add to that state machine?

Answer. A state between perception and planning that turns the instruction into a goal, checks the goal’s groundings, and hands the goal to the planner; this is the DECOMPOSE state introduced in §L.E.3. Used in §L.E.3.

Part A — Why a reasoning layer

§L.A.1 — The task-planning problem

The pipeline built through Modules 1.1 and 2.3 solves fixed tasks: the goal is encoded in the planner’s reward and the state machine’s stages. The 3.2.3 planner maximizes a predicted return against a goal state that someone else has specified; the 3.1.4 VLA follows an instruction but within a narrow task distribution. Neither decides which task to solve or how to decompose a compound instruction.

The task-planning problem is

where each $\tau_i$ is a sub-task that the low-level planner can execute — a goal state, a set of constraints, and a mode (grasp, transport, place). The sub-tasks are ordered and may be conditional.

The 3.2.3 planner supplies a critical observation: it is a conditional optimizer. Given a goal, it finds the best actions. It does not explore the space of goals. The space of goals is what the reasoning layer searches, and it is exponential in the number of objects and the number of predicates.

The running case’s instruction — “put the cube in the bin, but if the divider is in the way, put it in the second bin” — has three features that no single low-level planner handles.

Compound structure. It has two target goals with a condition that selects between them. The 3.2.3 planner optimizes one goal at a time.

Conditional logic. “If the divider is in the way” is a geometric predicate that must be evaluated against the current scene, not assumed.

Grounding. “The cube”, “the bin”, “the second bin”, “in the way” are all references that must be resolved to poses and predicates before any planner can use them.

§L.A.2 — What the LLM can and cannot do

The LLM contributes three capabilities that a classical system lacks.

Semantic parsing. It maps a natural-language instruction to a structured representation — a task graph, a program, a plan — handling the compositionality, negation, and reference that the 3.1.1 §L.B.2 grounding analysis named. This is what LLM pretraining supplies.

Prior over decompositions. Given a high-level task, there are many valid decompositions; the LLM’s prior over “how pick-and-place works in the world” selects the plausible ones, which is what makes search tractable.

Common-sense preconditions. “Put the cube in the bin” implicitly requires the gripper to be empty, the bin to be open, and the cube to be reachable. The LLM’s pretraining encodes these, and it surfaces them as explicit preconditions in the decomposition.

The LLM’s limitations are equally sharp.

Hallucination. It can reference objects that are not in the scene, or capabilities the robot does not have. Its training objective is plausibility, not truth, and the two diverge exactly where the robot is unusual.

No grounding. It does not know the cube’s pose, the bin’s position, or the divider’s height; the scene description is a text serialization that discards the metric precision the planner needs.

No feasibility guarantee. A plan can be logically valid and physically impossible — the trajectory crosses the divider, the gripper opening is too small, the reach is exceeded.

Non-determinism. The same instruction can produce different plans across calls; the variance is a feature for exploration and a bug for reproducibility.

The composition in §L.D.1 addresses each limitation by pairing the LLM with a verifier and a grounded planner. The LLM’s role is proposing; the verifier’s role is disposing; the planner’s role is executing.

Self-explanation 1. Why is the LLM’s hallucination a feature of the composition rather than a bug?

Answer. Because the verifier rejects hallucinated plans before they reach the robot, so the LLM’s tendency to explore unusual decompositions is a source of diversity that the verifier filters; a more conservative model would be more predictable and less useful.

Concept check. An LLM proposes “pick up the cube with the left gripper”. The robot has one right-mounted gripper. Which layer catches this, and what is the fix?

Answer. The verifier, because “left gripper” is a reference to a capability that does not exist; the fix is either to re-prompt the LLM with a capability description or to add a symbol-grounding check that rejects unknown capabilities. [displaces M1]

Worked-example ladder.

WE-L.A.a (fully worked). The instruction “put the cube in the bin, but if the divider is in the way, put it in the second bin” has two possible target goals. Compute the number of distinct plans if each plan is a sequence of four sub-tasks and each sub-task has three possible parameterizations.

Solution. Two goals times $3^4 = 81$ parameterizations gives 162 plans. The LLM does not enumerate them; it proposes one and the verifier checks it. The arithmetic is why enumeration is not the mechanism.

WE-L.A.b (completion). With three objects and two bins and no condition, compute the number of goal-object pairs. Completion. Six. With a condition that selects among two bins, twelve. The growth is polynomial here but exponential in predicates, which is why the LLM’s prior is what makes search tractable.

WE-L.A.c (faded). Write the preconditions for “put the cube in the bin” as a list of predicates, and state which the LLM supplies and which the scene description supplies.

Faded step. Preconditions: gripper empty; bin open; cube reachable; cube graspable; path clear. The LLM supplies the first three as common sense; the scene supplies the last two as measurements.

Completion. The division is the reason the composition needs both: the LLM’s preconditions are necessary but not sufficient, and the scene’s are sufficient but not complete.

WE-L.A.d (contrastive near-miss). A learner gives the LLM the raw image and asks it to output joint torques. The outputs are plausible-looking and unusable. Why it fails: the LLM’s output space is symbols, and joint torques are not symbols; the mapping from language to action requires the grounding and planning layers, which the learner omitted. The fix: the LLM outputs goals and constraints; the 3.2.3 planner outputs actions.

Comparative table: the reasoning layer’s three inputs and their sources.

Design principle P42.1. The LLM proposes; the verifier disposes; the planner executes. Any layer that is missing turns a plausible plan into an unsafe action.

Consolidation checkpoint 1

(a) Three capabilities. You can write the task-planning problem and its three features. You can name the LLM’s three capabilities and four limitations. You can state the propose–dispose–execute composition.

(b) Transfer probe. A cell’s instruction is a single fixed task. Does it need a reasoning layer? Answer: no; the fixed task is encoded in the planner’s reward, and the LLM adds latency, non-determinism, and a failure mode without adding capability.

(c) Remediation rule. If you cannot state why the LLM’s output space is not the action space, re-read §L.A.2 before Part B.

Part B — The three formalisms

§L.B.1 — Hierarchical Task Networks

A Hierarchical Task Network (HTN; Erol, Hendler, Nau 1994, tier A, S) represents a task as a decomposition into subtasks. Formally, a task network is a pair $(T, \phi)$ where $T$ is a set of tasks and $\phi$ a set of constraints among them. A method is a rule

which says that when the preconditions hold, $\tau$ can be decomposed into the subtasks $T'$ with constraints $\phi'$. A primitive task is one that the low-level planner can execute directly.

For the running case, the top-level task “put the cube in the target bin” decomposes as:

with constraints that check-divider precedes choose-bin, and the rest are ordered. The preconditions of put are the preconditions of the first subtask, which in turn are the preconditions of the primitives.

The LLM’s role is to propose the methods. The HTN formalism supplies the structure — decomposition, ordering, preconditions — and the LLM supplies the content: which subtasks, in what order, under what conditions. This is the decomposition that §L.E.1 applies.

The HTN has two properties that make it the right formalism for the running case. It is executable: the primitive tasks are the 3.2.3 planner’s inputs, so an HTN decomposition is immediately a plan. It is verifiable: a method’s preconditions are predicates the verifier can evaluate, so the plan’s validity is a set of predicate evaluations.

The weakness is that HTN methods are hand-written or LLM-proposed, and their coverage is not guaranteed. A novel instruction may require a method the LLM has not proposed; the verifier will reject the plan, and the LLM must be re-prompted with the failure.

§L.B.2 — PDDL

PDDL (Planning Domain Definition Language; McDermott et al. 1998, tier A, S) represents a planning problem as a set of objects, a set of predicates, an initial state (a set of true predicates), a goal (a set of predicates that must be true), and a set of operators. An operator is a triple (preconditions, add-effects, delete-effects), and a plan is a sequence of operators whose preconditions are satisfied and whose effects transform the initial state into a state satisfying the goal.

The running case’s PDDL domain has predicates at(obj, pose), holding(obj), clear(path), in-bin(obj, bin), and operators pick, move, place. The instruction’s conditional is encoded as two goal sets and a derived predicate divider-blocks that is evaluated by the scene description.

The strength of PDDL is verifiability: a plan is valid if and only if every operator’s preconditions are satisfied and the goal is reached. A classical planner (Fast Downward; Helmert 2006, tier A, S) can search for a valid plan or prove that none exists. This is the “dispose” half of the composition, and it is what the LLM cannot supply.

The weakness is the modelling gap: PDDL requires a complete symbolic model of the domain, and open-ended manipulation does not have one. The predicates are discrete and the geometry is continuous; discretizing the geometry into predicates is lossy, and the loss is exactly where the planner’s decisions are made.

The LLM+P pattern (Liu et al. 2023, tier B, S) addresses this: the LLM translates the natural-language instruction and the scene description into PDDL, a classical planner solves the PDDL, and the LLM translates the plan back to language. The pattern’s strength is that it inherits the classical planner’s guarantees; its weakness is that the translation is the new bottleneck, and a translation error produces a plan that is valid in the wrong domain.

§L.B.3 — LLM-as-planner

The third formalism is the simplest: the LLM directly outputs a plan as text, and a parser converts it to sub-tasks. The patterns are ReAct (Yao et al. 2023, tier A, S), which interleaves reasoning traces and actions, and SayCan (Ahn et al. 2022, tier A, S), which scores each candidate skill by the product of the LLM’s likelihood of the skill’s description and the skill’s learned affordance value.

The strength is flexibility: the LLM can propose decompositions that no hand-written method covers, and the ReAct loop lets it recover from a failed step by re-planning. The weakness is unverifiability: a text plan has no formal semantics, and its feasibility must be checked by a separate parser and verifier.

The two failure modes of LLM-as-planner are characteristic. Plan drift: after a failed step, the LLM’s re-plan diverges from the original goal, because the re-plan is conditioned on the failure’s text rather than on the goal’s symbolic form. Plan inconsistency: consecutive plans produced by the same LLM for the same instruction differ in their decomposition, so the executed plan is not reproducible.

The composition in §L.D.1 uses the LLM-as-planner for the proposal and the HTN or PDDL for the verification. The LLM’s output is parsed into the formal representation, and the formal representation is checked.

Self-explanation 2. Why does SayCan multiply the LLM’s likelihood by an affordance value rather than using the likelihood alone?

Answer. Because the likelihood measures whether the skill’s description fits the instruction, not whether the skill is currently possible; the affordance value measures feasibility, and the product requires both.

Concept check. A PDDL plan is valid under the domain’s predicates and fails when executed because the gripper cannot reach the bin. Which formalism’s weakness is this, and what is the fix?

Answer. PDDL’s modelling gap: the reachability was not encoded as a predicate, so the plan’s validity is relative to an incomplete model. The fix is to add a reachable predicate computed from the 2.3.2 workspace and the 2.1.2 poses. [displaces M2]

Worked-example ladder.

WE-L.B.a (fully worked). Write the HTN decomposition of “put the cube in the target bin” with four subtasks, and identify the precondition of each.

Solution. put(c, b) → pick(c), transport(b), place(b) with precondition holding(c) for transport and at-grasp-pose(b) for place. pick(c) → reach(c), grasp(c) with precondition clear(path to c). The decomposition is four primitives: reach, grasp, transport, place.

WE-L.B.b (completion). Add the conditional branch: put → check-divider, choose-bin, then the four primitives. Write the precondition of choose-bin. Completion. choose-bin requires the result of check-divider, which is a boolean predicate divider-blocks. The precondition is divider-blocks evaluated, either true or false, which is always satisfiable after the check.

WE-L.B.c (faded). Write the PDDL operator for pick(c) with preconditions and effects, and state what predicate is missing that the HTN has.

Faded step. pick(c): pre at-grasp(c), gripper-empty; eff holding(c), not gripper-empty. Completion. The missing predicate is reachability, which is the modelling gap; the HTN’s clear(path to c) is a geometric precondition that PDDL has no native way to express.

WE-L.B.d (contrastive near-miss). A learner uses LLM-as-planner with ReAct and finds that after a failed grasp the LLM re-plans to “put the cube on the table” instead of retrying the grasp. Why it fails: the re-plan is conditioned on the failure text, which mentions the table, and the LLM’s prior shifts to a nearby goal. The fix: re-prompt with the original goal and the failure, or verify the re-plan against the original goal’s symbolic form before accepting.

Comparative table: the three formalisms.

Design principle P42.2. Use the LLM for what it is good at — proposing decompositions — and a formal representation for what it is not — guaranteeing feasibility.

Consolidation checkpoint 2

(a) Three capabilities. You can write an HTN decomposition with preconditions. You can write a PDDL operator and name the modelling gap. You can state the LLM-as-planner pattern and its two failure modes.

(b) Transfer probe. A new instruction mentions an object the PDDL domain has no predicate for. Which formalism fails, and what is the fix? Answer: the PDDL domain, because the object is unmodelled; the fix is to add the predicate and re-run the translation, or to fall back to the HTN with a hand-written method.

(c) Remediation rule. If you cannot state why PDDL’s modelling gap is the place the planner’s decisions live, re-read §L.B.2 before Part C.

Part C — Grounding

§L.C.1 — The grounding stack

Grounding is the process of resolving the plan’s symbols to the scene’s entities and poses. It has four layers, and each has its own ambiguity.

Layer 1: reference resolution. “The cube” must be resolved to one object in the scene; if there are several, the reference is ambiguous and the LLM’s semantic prior must disambiguate, with the verifier checking that the choice is unique after disambiguation.

Layer 2: predicate evaluation. “In the way” must be evaluated as a geometric predicate — the divider’s projection intersects the straight-line path from the cube to the bin, or more precisely, the 2.3.2 clearance check fails on that path.

Layer 3: pose lookup. The chosen object’s pose must be looked up from the 2.1.2 estimator, with the estimator’s covariance carried forward so the plan can be robust to the pose uncertainty.

Layer 4: action-space mapping. The sub-task’s parameters (grasp pose, transport pose, place pose) must be mapped to the 3.2.3 planner’s goal states and the 2.3.3 controller’s action space.

The stack is the pipeline from 3.1.1 §L.B.2’s three groundings, specialized to the reasoning layer. Visual grounding is layer 3; linguistic grounding is layers 1 and 2; motor grounding is layer 4.

Self-explanation 3. Why does the pose lookup carry the estimator’s covariance forward rather than using the point estimate?

Answer. Because the plan’s feasibility depends on the pose within its uncertainty: a grasp that is feasible at the mean may be infeasible at a 2-sigma sample, and the planner’s sampling of the posterior (3.2.3 §L.A.3) needs the covariance to be representable.

§L.C.2 — The ambiguity of each layer

Each layer has a failure mode, and each failure has a signature.

Reference ambiguity. The instruction has a definite reference (“the cube”) but the scene has two cubes. The LLM’s prior usually disambiguates from context; when it does not, the plan’s reference is under-determined and the verifier must reject it rather than let the planner pick. The signature is a plan whose first sub-task’s object is ambiguous.

Predicate ambiguity. “In the way” is not a formal predicate; it has a family of formalizations (intersects the straight-line path; intersects the swept volume; within the clearance margin; blocks the line of sight). Each formalization is a different predicate, and the choice determines the plan’s branch. The signature is a branch that does not match the operator’s intent.

Pose uncertainty. The 2.1.2 pose has a covariance that is wider on shiny or occluded surfaces. A grasp planned at the mean can miss at 2 sigma; the plan must either carry the covariance into the 3.2.3 planner’s belief or add a margin to the grasp tolerance. The signature is a grasp that succeeds in nominal conditions and fails when the surface is shiny.

Action-space mismatch. The sub-task’s parameters are in the planner’s Cartesian space, and the controller’s action space may differ. A plan that specifies a Cartesian pose must be mapped to the end-effector’s reachable set; if the pose is outside it, the 2.3.2 planner returns infeasible and the plan fails. The signature is a plan whose final sub-task’s pose is outside the workspace.

§L.C.3 — The scene description

The LLM sees the scene as a text serialization. The serialization’s design determines what the LLM can ground and what it cannot.

A good serialization lists each object with its name, its pose, and its salient properties (size, material, whether it is in a container), plus the free-space information the predicates need (which paths are clear). A bad serialization lists only names, and the LLM hallucinates the poses.

The serialization is where the ambiguity is either resolved or introduced. A cube’s pose written as (0.5, 0.2, 0.3) with a rotation matrix is precise and opaque; a cube’s pose written as “on the table, about 20 cm from the bin” is interpretable and imprecise. The right choice is the precise form plus a natural-language gloss, so the LLM’s semantic prior can operate on the gloss and the verifier can check against the precise form.

Concept check. The serialization writes “cube at (0.5, 0.2, 0.3)” and “bin at (0.4, -0.3, 0.15)”. The LLM proposes a plan that moves the cube from (0.5, 0.2, 0.3) to (0.4, -0.3, 0.15) in a straight line. The divider at x=0.35 is not mentioned in the serialization. What fails, and how is it caught?

Answer. The predicate “in the way” is ungrounded because the divider is not in the serialization; the plan’s straight-line path violates the 2.3.2 clearance, and the verifier catches it. The mechanism is that the LLM cannot evaluate a predicate for an object it was not told about. [displaces M4]

Worked-example ladder.

WE-L.C.a (fully worked). The scene has two cubes at (0.5, 0.2, 0.3) and (0.6, -0.1, 0.3), and one bin. The instruction is “put the cube in the bin”. Compute the number of possible groundings and the disambiguation the LLM must supply.

Solution. Two cube references times one bin reference gives two groundings. The LLM must choose one, typically the nearer or the more salient; the verifier checks that the choice is unique by checking the scene for other objects of the same description. If the scene has two, the verifier rejects the plan and the LLM is re-prompted with “which cube?”.

WE-L.C.b (completion). Formalize “in the way” three ways and compute the branch each gives for the running case’s geometry. Completion. (1) Intersects the straight-line path: the divider at x=0.35 intersects, branch to the second bin. (2) Intersects the swept volume of the gripper: the divider is at y∈[0.05, 0.15], and the path from (0.5, 0.2, 0.3) to (0.4, -0.3, 0.15) crosses y=0.15 at x≈0.47, which is clear of the divider; branch to the primary bin. (3) Within the clearance margin: the margin’s value determines the branch. The three formalizations give two different branches, which is the ambiguity.

WE-L.C.c (faded). Design the scene serialization for the running case, listing each object and the fields the predicates need.

Faded step. Cube: name, pose, size, material (friction). Bin: name, opening pose, size. Divider: pose, extent. Free space: the clearance table from the 2.3.2 planner.

Completion. The serialization is the interface between the LLM and the verifier, and its fields are determined by the predicates the plan uses; a field that no predicate reads is a cost without benefit.

WE-L.C.d (contrastive near-miss). A learner gives the LLM a serialization with names and no poses and finds that the LLM confidently proposes a plan with invented coordinates. Why it fails: the LLM’s prior over coordinates is not grounded in the scene, so it produces plausible-looking numbers. The fix: include the poses in the serialization and, more importantly, have the verifier check every coordinate against the scene’s ground truth, rejecting any that do not match.

Comparative table: the four grounding layers.

Design principle P42.3. Ground each symbol before planning; an ungrounded symbol is a plausible plan that cannot be executed.

Consolidation checkpoint 3

(a) Three capabilities. You can state the four grounding layers. You can name the failure mode of each and its signature. You can design a scene serialization.

(b) Transfer probe. The scene has two bins and the instruction says “the bin”. Which grounding layer fails, and what does the verifier do? Answer: reference resolution; the verifier checks uniqueness and rejects, and the LLM is re-prompted with a disambiguating question.

(c) Remediation rule. If you cannot state why the pose covariance must be carried forward, re-read §L.C.1 before Part D.

Part D — Verification and failure

§L.D.1 — The propose–dispose–execute–monitor composition

The reasoning layer’s composition has four stages, and each has a distinct role.

Propose. The LLM produces a plan in one of the three formalisms, given the instruction and the scene serialization. The proposal is non-deterministic and unverified.

Dispose. A verifier checks the plan against the scene’s predicates, the robot’s capabilities, and the 3.2.3 planner’s feasibility. A plan that fails any check is rejected and the LLM is re-prompted with the failure.

Execute. The 3.2.3 planner and the 2.3.3 controller execute the plan’s sub-tasks in order, with the 2.2.4 Q-shield active.

Monitor. The 1.1.4 state machine’s health checks observe the execution; a failure triggers a re-plan, which re-enters the propose stage with the failure as context.

The composition is the lesson’s answer to the LLM’s limitations. The propose stage is where the LLM’s semantic capabilities are used; the dispose stage is where its hallucination is caught; the execute stage is where its non-determinism is neutralized by the deterministic planner; the monitor is where its plan drift is detected.

§L.D.2 — The verifier’s checks

The verifier is a deterministic function that takes a plan and the scene and returns accept or reject with a reason. Its checks are:

Reference check. Every object reference resolves to exactly one object in the scene; an unresolved or ambiguous reference is a rejection.

Predicate check. Every predicate in the plan’s preconditions is evaluated against the scene; a predicate the scene cannot evaluate is a rejection.

Capability check. Every operator is in the robot’s capability set; an operator the robot cannot perform is a rejection.

Feasibility check. Every sub-task’s goal is in the 2.3.2 feasible set and passes the 3.2.3 safety checks; a sub-task that is infeasible is a rejection.

Consistency check. The plan’s sub-tasks are ordered consistently with the HTN’s constraints and the PDDL’s effects; a plan that violates an ordering is a rejection.

The checks are applied in order and the first rejection stops the plan. The order is by cost: reference and predicate are cheap, capability and feasibility are expensive, and consistency is intermediate.

§L.D.3 — The four failure modes

The verifier’s rejection reasons are the reasoning layer’s failure modes, and each has a signature.

Hallucination. The plan references an object or capability that does not exist. Signature: a reference check rejection. Cause: the LLM’s prior over the world, applied to a scene it was not fully told about. Fix: more complete serialization, or re-prompt with the capability list.

Grounding failure. The plan’s reference is ambiguous or its predicate is the wrong formalization. Signature: a predicate check rejection or a branch that does not match the operator’s intent. Cause: the scene’s ambiguity or the predicate’s formalization. Fix: disambiguation in the serialization, or a formalization chosen by the operator.

Infeasibility. The plan is logically valid and physically impossible. Signature: a feasibility check rejection. Cause: the plan’s sub-task is outside the 2.3.2 feasible set. Fix: re-prompt with the failure, and consider a different decomposition.

Plan drift. The re-plan after a failure diverges from the original goal. Signature: a consistency check rejection, or a monitored success rate that falls after a failure. Cause: the re-plan is conditioned on the failure’s text. Fix: re-prompt with the original goal’s symbolic form and the failure, and verify the re-plan against the goal before accepting.

Self-explanation 1. Why is plan drift caught by the consistency check rather than by the feasibility check?

Answer. Because a drifted plan can be perfectly feasible — it just solves a different problem; the consistency check compares the plan to the goal, not to the constraints.

Concept check. The LLM’s plan references “the second bin” and the scene has only one bin. Which failure mode, and what does the verifier return?

Answer. Hallucination, and the verifier returns a reference-check rejection with the reason “second bin not in scene”. The LLM is re-prompted with the scene’s bin list. [displaces M3]

Worked-example ladder.

WE-L.D.a (fully worked). The verifier’s rejection rate is 40% on hallucination, 25% on grounding, 25% on feasibility, and 10% on drift. The LLM is re-prompted on rejection, and the re-prompt succeeds 80% of the time. Compute the effective plan acceptance rate.

Solution. The first attempt’s acceptance is 60%. Of the 40% rejections, 80% succeed on re-prompt, so the effective acceptance is $0.6 + 0.4 \times 0.8 = 0.92$, with the remaining 8% requiring a third attempt. Two re-prompts give $0.6 + 0.4 \times 0.8 + 0.4 \times 0.2 \times 0.8 = 0.984$.

WE-L.D.b (completion). The feasibility rejection rate rises to 40% because the LLM proposes plans that cross the divider. Recompute and state the fix. Completion. First-attempt acceptance $0.6 - 0.15 = 0.55$; after two re-prompts, about 0.98. The fix is to add the divider to the serialization and to re-prompt with the feasibility failure’s reason.

WE-L.D.c (faded). Design the re-prompt template for a feasibility rejection: which fields, and in what order.

Faded step. The template has the original instruction, the scene serialization, the rejected plan, the verifier’s reason, and a directive to revise. Completion. The order matters because the LLM attends to the end of the prompt; the directive last.

WE-L.D.d (contrastive near-miss). A learner accepts the LLM’s plan without verification because the plan “looks right”. The execution collides with the divider. Why it fails: the plan’s plausibility is a language property, and the collision is a geometric property; the verifier is what connects them. The fix: never execute an unverified plan.

Comparative table: the verifier’s checks and failure modes.

Design principle P42.4. Verify before executing; the verifier is the layer that turns the LLM’s plausible plans into the robot’s safe actions.

Consolidation checkpoint 4

(a) Three capabilities. You can state the four stages of the composition. You can write the verifier’s five checks in cost order. You can diagnose each failure mode from its signature.

(b) Transfer probe. The rejection rate on feasibility is 30% and on hallucination is 5%. Which is the priority fix, and why? Answer: feasibility, because it is the larger cost and the fix is a serialization change; hallucination is already low and the fix is a capability list, which is a smaller change.

(c) Remediation rule. If you cannot state why plan drift is caught by consistency and not feasibility, re-read §L.D.3 before Part E.

Part E — The running case

§L.E.1 — The conditional decomposition

The instruction is “put the cube in the bin, but if the divider is in the way, put it in the second bin”. The decomposition into an HTN:

with choose-bin branching on divider-blocks(c, primary): true selects the second bin, false selects the primary. The primitives are the 3.2.3 planner’s goals.

The decomposition is verified against the scene. The check-divider subtask’s predicate is the 2.3.2 clearance check: the straight-line path from the cube’s pose to the primary bin’s opening crosses the divider’s extent, so the branch is true for the running case’s nominal geometry.

The plan’s execution is the 3.2.3 planner’s query for each primitive, with the 2.2.4 Q-shield active and the 1.1.4 state machine monitoring. If a primitive fails, the monitor re-enters the propose stage with the failure, and the LLM is re-prompted with the original instruction and the failure reason, not with a drifted goal.

§L.E.2 — The scene serialization

The serialization for the running case lists:

• the cube, with pose, size, and friction;
• the primary bin, with opening pose and size;
• the second bin, with opening pose and size;
• the divider, with pose and extent;
• the free-space clearance table from 2.3.2, in the form of a boolean for each object pair.

The predicate divider-blocks(c, primary) is computed by the verifier from the clearance table, not by the LLM. The LLM’s role is to name the predicate; the verifier evaluates it. This division is the lesson’s core.

§L.E.3 — The DECOMPOSE state

The 1.1.4 state machine gains a DECOMPOSE state between PERCEIVE and PLAN.

Entry condition. The instruction is received and the 2.1.2 pose estimate is fresh for all objects in the scene.

Exit condition. A verified plan exists, with all sub-tasks grounded and feasible; or the LLM’s three re-prompts have failed and the state machine transitions to a safe HALT.

Health checks. The plan’s rejection count, the verifier’s rejection reasons, the number of re-prompts, and the plan’s total predicted return are logged at the state boundary.

Recovery. A rejected plan triggers a re-prompt with the failure reason; a plan that is rejected three times transitions to HALT and requests operator intervention. The halt is safe because the 2.3.3 controller is holding the current pose and the 2.2.4 Q-shield is active.

Self-explanation 2. Why does the DECOMPOSE state log the verifier’s rejection reasons rather than only the rejection count?

Answer. Because the reasons are what the re-prompt and the operator use; a count without reasons cannot distinguish a hallucination from a grounding failure, and the fixes differ.

Worked-example ladder.

WE-L.E.a (fully worked). The nominal geometry has the cube at (0.5, 0.2, 0.3), the primary bin at (0.4, -0.3, 0.15), and the divider at x=0.35 with y∈[0.05, 0.15]. Compute whether the straight-line path crosses the divider.

Solution. The path from (0.5, 0.2) to (0.4, -0.3) in the xy-plane has $y = 0.2 - 5(x - 0.5) \cdot 0.1 / 0.1$. At $x=0.35$, which is outside the segment’s $x$-range [0.4, 0.5], so the path does not reach the divider’s x-position. The divider is not in the way in the nominal geometry.

WE-L.E.b (completion). The cube moves to (0.5, -0.1, 0.3). Recompute. Completion. The path from (0.5, -0.1) to (0.4, -0.3) crosses $x=0.35$ only if extended, which it is not. The divider is again not in the way. The completion shows that the nominal geometry is clear, and the conditional’s branch is false.

WE-L.E.c (faded). Move the primary bin to (0.3, 0.0, 0.15), so the path crosses x=0.35. Compute the branch and the plan.

Faded step. The path from (0.5, 0.2) to (0.3, 0.0) crosses x=0.35 at $y \approx 0.15$, which is on the divider’s boundary. Completion. The branch is true; the plan targets the second bin. The boundary case is the hardest, and the verifier’s clearance margin determines the branch.

WE-L.E.d (contrastive near-miss). A learner has the LLM evaluate divider-blocks directly from the scene serialization, and the LLM’s answer varies across calls. Why it fails: the predicate is a geometric computation, and the LLM’s prior over geometry is not precise; the answer is plausible and non-deterministic. The fix: the verifier computes the predicate from the clearance table; the LLM only names it.

Comparative table: the running case’s reasoning layer.

Design principle P42.5. Let the LLM name the predicates and the verifier compute them; the division is what makes the reasoning layer deterministic where it must be.

Consolidation checkpoint 5

(a) Three capabilities. You can write the conditional HTN. You can design the serialization and name the predicate-computation division. You can add the DECOMPOSE state with its health checks.

(b) Transfer probe. The second bin is moved so that it is also blocked by the divider. What does the plan do? Answer: the verifier rejects both branches as infeasible, the LLM is re-prompted with the rejection, and the state machine halts if no branch is feasible.

(c) Remediation rule. If you cannot compute the branch for WE-L.E.b, redo it before the lab.

Failure taxonomy

The table covers the three lab corruptions plus three failures not exercised in the lab: staleness, temperature, and verbose decomposition.

The lab

Task. Implement the propose–dispose composition with a stub LLM (a scripted planner that can be made to hallucinate or drift) and a verifier with the five checks. Run the running case’s conditional instruction through the composition and measure the acceptance rate across the failure modes.

Conditions. Python 3.10+, NumPy. The stub LLM returns a plan from a small set of pre-written plans; the verifier evaluates against a scene dictionary. Seed all RNGs.

Controls. (i) The nominal composition; (ii) the composition with the LLM made to hallucinate 30% of the time; (iii) the composition with the LLM’s predicate evaluation left to the LLM instead of the verifier; (iv) the composition with the consistency check disabled.

Metrics.

Pre-registered hypotheses.

H1. Control (i) has acceptance ≥ 0.9, because the verifier catches the stub’s errors and the re-prompt fixes them.

H2. Control (ii) has a higher reference-rejection rate but a similar final acceptance, because the re-prompt fixes hallucination.

H3. Control (iii) has a non-deterministic branch and a lower branch-correctness rate, because the LLM’s geometric evaluation is imprecise.

H4. Control (iv) has a higher drift rate, because the consistency check is what catches it.

Break-it sequence.

1. Remove the object from the serialization silently. The reference check rejects, and the re-prompt cannot fix it because the object is still missing. Silent: the LLM’s plan looks plausible.
2. Change the predicate’s formalization silently. The branch flips, and the plan is feasible for the wrong bin. Silent: the plan passes all checks.
3. Disable the consistency check silently. A drifted re-plan is accepted. Silent: the plan is feasible and the drift is only visible against the goal.

Acceptance criteria.

What good looks like. A good artefact has five properties. (1) The verifier’s rejection reasons are logged per check, not aggregated. (2) The re-prompt template includes the reason and the original goal. (3) The predicate computation is a function separate from the LLM’s call. (4) The break-it results are a table. (5) The branch correctness is measured against an operator-specified ground truth.

A minimal composition, seeded and annotated:

# lab_3_3_1.py — propose–dispose with a stub LLM and a verifier
import numpy as np
np.random.seed(0)

SCENE = {
    "cube":     {"pose": (0.5, 0.2, 0.3), "size": 0.05},
    "bin1":     {"pose": (0.4, -0.3, 0.15), "size": 0.1},
    "bin2":     {"pose": (0.2, -0.4, 0.15), "size": 0.1},
    "divider":  {"pose": (0.35, 0.1, 0.2), "extent": (0.01, 0.05, 0.4)},
}

def clears_path(p0, p1, obs, margin=0.02):              # 2.3.2 clearance
    for k, o in obs.items():
        if k in ("cube", "bin1", "bin2"):
            continue
        lo = np.array(o["pose"]) - np.array(o["extent"]) / 2 - margin
        hi = np.array(o["pose"]) + np.array(o["extent"]) / 2 + margin
        for t in np.linspace(0, 1, 50):
            p = (1 - t) * np.array(p0) + t * np.array(p1)
            if np.all(p >= lo) and np.all(p <= hi):
                return False
    return True

def divider_blocks(scene, cube_key="cube", bin_key="bin1"):
    return not clears_path(scene[cube_key]["pose"],
                           scene[bin_key]["pose"], scene)

def verify(plan, scene):                               # the five checks
    for ref in plan["refs"]:
        if ref not in scene:                           # reference
            return False, f"reference: {ref} not in scene"
    for sub in plan["subtasks"]:
        if sub["op"] not in ("pick", "transport", "place"):  # capability
            return False, f"capability: {sub['op']} unknown"
    if plan["branch"] != ("bin2" if divider_blocks(scene) else "bin1"):
        return False, "consistency: branch does not match predicate"  # consistency
    target = scene[plan["branch"]]["pose"]
    if not clears_path(scene["cube"]["pose"], target, scene):   # feasibility
        return False, "feasibility: path blocked"
    return True, "ok"

def stub_llm(instruction, scene, mode="nominal"):
    branch = "bin2" if divider_blocks(scene) else "bin1"
    if mode == "hallucinate" and np.random.rand() < 0.3:
        branch = "bin3"                                # nonexistent bin
    if mode == "llm_predicate":
        branch = "bin2" if np.random.rand() < 0.5 else "bin1"
    return {
        "refs": ["cube", branch],
        "branch": branch,
        "subtasks": [
            {"op": "pick",      "target": "cube"},
            {"op": "transport", "target": branch},
            {"op": "place",     "target": branch},
        ],
    }

def run(mode="nominal", n=100):
    accepted = rejected = 0
    reasons = {}
    for _ in range(n):
        plan = stub_llm("put the cube in the bin", SCENE, mode=mode)
        ok, reason = verify(plan, SCENE)
        if ok: accepted += 1
        else:
            rejected += 1
            reasons[reason.split(":")[0]] = reasons.get(reason.split(":")[0], 0) + 1
    return accepted / n, reasons

for mode in ("nominal", "hallucinate", "llm_predicate"):
    rate, reasons = run(mode)
    print(f"{mode:14s} acceptance={rate:.2f} reasons={reasons}")

Line 4 defines the scene; lines 11–22 implement the 2.3.2 clearance check as the geometric predicate the verifier computes. Line 24 implements divider-blocks, which the verifier calls and the LLM does not. Lines 26–36 are the five checks in cost order: reference, capability, consistency, feasibility. Lines 38–51 are the stub LLM, with the hallucinate mode producing a nonexistent bin and the llm_predicate mode producing a non-deterministic branch. Lines 53–64 run the composition and log the rejection reasons per check.

Cheat sheet

Exercises with solutions

E 3.3.1.1. Write the task-planning problem and identify the reasoning layer’s three inputs.

S 3.3.1.1. Given instruction and scene, produce a sub-task sequence that achieves the instruction. The three inputs are the instruction, the scene serialization, and the capability description. The lesson: the reasoning layer’s output is a plan in the planner’s input space, not an action.

E 3.3.1.2 (transfer). A plan references “the second bin” and the scene has one bin. Which check rejects, and what is the re-prompt?

S 3.3.1.2. The reference check rejects with “second bin not in scene”; the re-prompt includes the scene’s bin list and the reason. The lesson: hallucination is caught by the reference check, and the re-prompt’s content is what fixes it.

E 3.3.1.3. Write the HTN decomposition of the running case’s conditional instruction with five subtasks and their orderings.

S 3.3.1.3. put-conditional(c) → check-divider(c), choose-bin(b), pick(c), transport(b), place(b), with orderings check-divider < choose-bin < pick < transport < place. The lesson: the conditional is a branch inside the decomposition, not a separate plan.

E 3.3.1.4 (diagnostic). A plan is logically valid and physically infeasible, and the verifier rejects it on the feasibility check. Name the cause and two fixes.

S 3.3.1.4. The modelling gap: a constraint the plan’s logic did not encode. Fixes: add the predicate to the scene’s serialization, and re-prompt with the feasibility reason. The lesson: infeasibility is a missing constraint, and the fix is to make it explicit.

E 3.3.1.5. Formalize “in the way” three ways and state which gives the correct branch for the running case’s nominal geometry.

S 3.3.1.5. Intersects the straight-line path: clear. Intersects the swept volume: clear. Within the clearance margin: depends on the margin. The nominal geometry is clear under the first two; the operator’s intent is the swept-volume formalization. The lesson: the formalization is a choice, and the choice must be the operator’s.

E 3.3.1.6 (transfer). The LLM evaluates divider-blocks itself and its answers vary across calls. Diagnose and state the fix.

S 3.3.1.6. The predicate is a geometric computation that the LLM’s prior cannot perform precisely. The fix is for the verifier to compute the predicate from the clearance table and the LLM only to name it. The lesson: the division of labour is what makes the layer deterministic.

E 3.3.1.7. State why plan drift is caught by the consistency check and not the feasibility check.

S 3.3.1.7. A drifted plan solves a different goal and can be entirely feasible; the consistency check compares the plan to the goal, which is the property that drift violates. The lesson: feasibility is about constraints, consistency is about the goal.

E 3.3.1.8 (diagnostic). The same instruction produces different plans across calls with temperature 0.7. Name the cause and the fix.

S 3.3.1.8. The temperature injects sampling variance. The fix is temperature 0 for planning calls, or a seed-and-verify loop that rejects plans that differ from the previous plan on the same instruction. The lesson: non-determinism is a feature for exploration and a bug for reproducibility.

E 3.3.1.9. Compute the effective acceptance after two re-prompts with a first-attempt rejection rate of 35% and a per-re-prompt success of 75%.

S 3.3.1.9. First attempt 0.65. After one re-prompt: $0.65 + 0.35 \times 0.75 = 0.9125$. After two: $0.9125 + 0.35 \times 0.25 \times 0.75 = 0.978$. The lesson: re-prompts recover most rejections, and the third attempt’s marginal value is small.

Exit test

You are ready for Lesson 3.3.2 when you can, without notes:

1. Write the task-planning problem and its three inputs.
2. Name the LLM’s three capabilities and four limitations.
3. State the propose–dispose–execute–monitor composition.
4. Write an HTN decomposition with preconditions.
5. Write a PDDL operator and name the modelling gap.
6. State the LLM-as-planner pattern and its two failure modes.
7. State the four grounding layers and their ambiguities.
8. Design a scene serialization for the running case.
9. Write the verifier’s five checks in cost order.
10. Diagnose hallucination, grounding failure, infeasibility, and plan drift from their signatures.
11. Write the re-prompt template with its four fields.
12. Apply the predicate-computation division.
13. Write the conditional HTN for the running case.
14. Add the DECOMPOSE state with entry, exit, and health checks.
15. Compute the effective acceptance after re-prompts.

Cross-references. 3.2.3 supplies the planner and the four safety checks restated in §L.A.1 and §L.D.2. 3.1.4 supplies the VLA as the task layer and the decision conjunction restated in §L.A.2. 2.3.2 supplies the clearance constraint restated in §L.C.2 and §L.E.1. 1.1.4 supplies the state machine extended in §L.E.3. 2.1.2 supplies the pose estimate used for grounding in §L.C.1. Lesson 3.3.2 uses the HTN decomposition as the program skeleton for code-as-policies. Lesson 3.3.3 deepens the grounding layer. Lesson 3.3.4 uses the verifier as the safety layer for LLM outputs.

Ready. The next lesson to write is 3.3.2 — Code-as-Policies. Say “next” to generate it.