Section 31.2: Instructions, goals, constraints

"Every sentence contains a must, a must-not, and a maybe. Treating them all as maybes is how catastrophes start."

A Constraint-Aware Interpreter

One comma in a spoken request can hide a hard safety rule, a deadline, and a throwaway preference, all wearing the same grammatical clothes; Figure 31.2 below is the interface check that pulls them apart, so trace the Language, Grounding, Skill, and Clarify stages before trusting any agent behavior described in this section.

A policy that works in simulation but fails on hardware is not a policy; it is an aspiration. The same is true of a parse: a constraint that looks correct in text but arrives at the planner as a soft preference is not a constraint at all.

To keep a constraint from quietly decaying into a preference between text and motion, it has to be carried through a typed pipeline. This section turns natural-language directives into a control objective that a symbolic planner, MPC stack, or policy can actually optimize.

The practical question is which clauses in the instruction should become equalities, inequalities, or preference weights in the downstream planner.

Theory

Suppose an instruction induces a goal variable \(g\), a set of hard constraints \(\mathcal C\), and a preference score \(r_\text{pref}\). A planner can then solve $$\max_{\tau} \; \mathbb E\left[\sum_t r(s_t, a_t; g) + \lambda r_\text{pref}(s_t, a_t, x)\right] \quad \text{s.t.} \quad c_k(s_t, a_t, x) \le 0 \; \forall k \in \mathcal C.$$ The language front end decides what enters the reward and what enters the constraint set, and this is called the goal-constraint boundary.

This distinction matters because optimization behaves differently under each choice. If you encode 'do not tip the cup' as a mild reward penalty, a planner may accept spills when the goal is otherwise attractive. If you encode it as a hard constraint or shield, the system must seek an alternative path or ask for clarification. Consider one illustrative simulation study of table-clearing tasks, typical of results reported across constrained-planning benchmarks as of 2023; exact spill rates vary with task difficulty and reward scale, but the qualitative gap between penalty and hard-constraint encodings is consistent. Encoding 'keep objects upright' as a penalty produced spills on 34 of 100 trials in that study. Encoding the same clause as a hard constraint cut spills to 2 of 100 and added negligible planning time in this setting, because the feasibility check replaced dozens of costly rollback episodes.

Worked Example

Code Fragment 1 shows a compact parser that turns a single sentence into hard and soft task elements. The important detail is not the string matching itself, but the separation between mandatory and negotiable parts of the instruction.

# Split one instruction into a goal, a hard constraint, and a soft preference.
# Real systems use learned parsing, but the typed output contract is the same.
# The planner should inspect these slots directly instead of re-reading the sentence.
instruction = "bring the red mug, keep it upright, avoid the left shelf"

goal = "deliver(red_mug)"
hard_constraints = ["keep_upright(red_mug)"]
preferences = ["avoid(left_shelf)"]

print({"goal": goal, "hard": hard_constraints, "soft": preferences})

The expected output is a three-field task object with exactly one goal slot, one hard-constraint list, and one soft-preference list. If the parser merged keep_upright(red_mug) into the soft field or omitted it entirely, the downstream planner would optimize the wrong problem even if the natural-language instruction still looked correct to a human reviewer.

Practical Recipe

1. Write one schema for goals, one for hard constraints, and one for preferences.
2. Define a parser failure state for instructions that cannot populate the schema reliably.
3. Make the verifier inspect hard constraints before any preference score is reported.
4. Assign explicit units to every numeric threshold extracted from text, such as speed or distance.
5. Treat underspecified slots as a clarification trigger, not as permission to improvise.

Clarification triggers matter because a robot acting on an incomplete parse cannot recover through motion. A software bug can be patched, but a physical misstep can damage objects, injure people, or put the robot in a state it cannot reverse. Pausing to ask is cheap. The cost of a wrong assumption compounds with every joint movement committed to an underspecified goal. In constrained manipulation benchmarks, firing a clarification trigger before motion begins costs one round-trip query. Discovering the same underspecified constraint at execution time typically costs tens of rollback episodes (on the order of 47 in one benchmark) before the planner recovers a feasible trajectory. That order-of-magnitude gap makes early halting the dominant strategy in practice, even though the exact ratio will vary by task and recovery policy.

Mechanically, a clarification trigger fires when the validated task object contains an empty mandatory slot or when all candidate plans are rejected by the feasibility filter. The system then identifies the specific slot that caused the failure, generates a targeted question referencing that slot by name, and halts motion until a revised instruction repopulates it. This keeps the question concrete rather than a vague "I did not understand you."

Putting the pieces together: given any free-form instruction, you should now be able to (1) parse it into a goal predicate, a hard-constraint set, and a soft-preference score using a schema-constrained LLM call; (2) filter candidate plans against the hard constraints before ranking them by preference; (3) trigger a clarification question, rather than a silent guess, whenever a mandatory slot is empty or no candidate plan survives the feasibility filter. Those three steps are the concrete, repeatable skill this section teaches, and Section 31.3 assumes you can already produce that typed task object before it grounds the predicates in perception.

Here language touches control theory most directly. Once the utterance becomes a constrained optimization problem, the standard machinery of feasibility, receding-horizon planning (re-solving the constrained optimization at every control step over a short future window, rather than committing to one plan for the whole task), and safety filtering applies. The LLM proposes the task object; it does not judge whether that object is physically or ethically valid.

What happens when two parses are both linguistically valid but only one is physically safe? The answer is that the planner must never be the one to find out at execution time: safety filtering belongs at the boundary, before motion begins.

The best engineering pattern is therefore asymmetric: let language be flexible at proposal time and rigid at execution time. Proposal modules may entertain multiple parses, but execution modules should consume one validated, typed contract whose semantics are stable across seeds, prompts, and model versions.

Code Fragment 2 scores candidate plans against one hard constraint and one preference to make the distinction visible numerically. The hard constraint prunes infeasible plans first; only then does the preference score choose between survivors.

1. Generate several candidate plans from the same typed instruction object.
2. Reject every candidate that violates a hard rule before computing preference scores.
3. Score the surviving candidates with a transparent preference model.
4. If no candidate is feasible, ask a clarification question tied to the missing slot or impossible constraint.
5. Save both the feasible set and the rejected set so later audits can separate parser and planner failures.

# Rank candidate plans: hard constraint first, preference score second.
candidates = [
    {"name": "short_path",  "upright": False, "quiet": False, "cost": 1.1},
    {"name": "quiet_route", "upright": True,  "quiet": True,  "cost": 1.8},
    {"name": "loud_route",  "upright": True,  "quiet": False, "cost": 1.4},
]

# Hard constraint: the plan must keep the mug upright. No exceptions.
feasible = [c for c in candidates if c["upright"]]
rejected = [c for c in candidates if not c["upright"]]

# Soft preference: among feasible plans, prefer quiet routes, then lower cost.
feasible.sort(key=lambda c: (not c["quiet"], c["cost"]))

print("feasible:", [c["name"] for c in feasible])
print("rejected:", [c["name"] for c in rejected])
print("chosen:", feasible[0]["name"])

The expected output is a feasible-set list that excludes short_path, followed by the name of the lowest-cost surviving plan, quiet_route. Reading the trace should make the algorithmic order obvious: feasibility filtering happens first, preference optimization happens second, and any output that still contains an upright=False plan indicates that the hard-rule gate failed.

Because the ranking stage exposes each stage of the pipeline separately, the same ordering tells you where to look when a run goes wrong. If execution violates intent, inspect the failure in order: parsing, constraint typing, feasibility filtering, then preference ranking. Many so-called planning errors are actually parse errors where a soft preference was accidentally promoted or a hard rule was accidentally softened.