Robotic task planning has to do more than reach the goal: every intermediate step must also satisfy constraints such as ordering, mutual exclusion and resource limits. A plan that eventually puts an object in the right place is still unacceptable if it enters a restricted region, handles a fragile object in the wrong order or skips a required inspection step. In the preprint SLoSa (arXiv 2610.28955, 2026-10-20), authors from the University of Notre Dame and Northwestern University move classical planners and formal verifiers out of the inference loop and into training: they first use them to build training problems in which an added constraint invalidates the original plan, then use the verifier’s graded outcomes as GRPO rewards to fine-tune 4-bit quantized models of 4B–14B parameters. The authors report that these compact planners reach 70.5–76.0% success on a 200-instance PDDL test set and draw 17.85–26.41 W of average power when run locally in INT4 on a Jetson AGX Orin. This article focuses on a detail that is easy to miss: the verifier checks in a fixed order, so a plan is only judged for safety violations once it is executable. All numbers below are author-reported [R]; this site has not reproduced them.
What “safe” means here: formal constraints and a fixed check order
The paper writes a task as P = (S, A, s0, G, C): a symbolic state space, an action set, an initial state, a goal and a set of safety constraints. Each action corresponds to a high-level skill (such as pick, move or place) with preconditions and effects; a plan is a sequence of actions. Safety constraints are expressed as PDDL3 trajectory constraints, which check the whole state trajectory, not just the end state. The paper states explicitly that the “safety awareness” in SLoSa’s name means compliance with this formal task specification, and that “low power” is an empirical deployment objective rather than an assumed property.
The verifier checks each output in a fixed order, and the first failed check determines the outcome, so every output falls into exactly one category:
- It cannot be parsed, or contains undefined actions or objects: a format error.
- It parses, but some action’s precondition is not met: a precondition violation.
- Only once a complete, executable trajectory exists is constraint C checked; violating C is a safety violation.
- It is safe and executable but does not reach goal G: a goal failure.
- It passes all of the above: a success.
The same order is used for training-data filtering, reward design and evaluation, and it also determines how the results table should be read. In the table below, the “safety violation” column is low throughout (0–1.0%), but that does not mean most failed plans were safe: a plan that violates a precondition at step 3 never reaches the safety check. For example, 73.0% of the directly prompted GPT-5.6 Sol’s outputs are precondition violations and only 0.5% are safety violations; whether those 73.0% satisfy the constraints is something the table cannot tell us (this is this site’s reading of the paper’s definitions). The more direct measure of whether constraints change behavior is the data ablation in the next section.
Training data: keep only problems where the constraint changes the plan
The data come from four robotics-inspired PDDL domains, Blocksworld, Ferry, Grippers and Spanner, covering manipulation, transportation, object transfer and tool use. For each base problem P0, a classical planner first produces a baseline plan τ0 that is verified as executable and goal-reaching; a PDDL3 constraint grounded in the domain semantics is then added to obtain a constrained problem Pc. Each constraint follows one of four patterns:
| Pattern | PDDL3 construct | Robotic interpretation |
|---|---|---|
| Ordering safety | sometime-before | A required event must precede another event |
| Staging safety | sometime, sometime-before | The robot must pass through a safe intermediate state |
| Resource restriction | always, not | Unsafe, reserved or faulty resources cannot be used |
| Mandatory inspection | sometime | The robot must visit a checkpoint or complete an inspection |
The paper’s example is an ordering constraint in Spanner requiring nut1 to be tightened before nut2: (sometime-before (tightened nut2) (tightened nut1)). A plan that tightens the two nuts in the reverse order still reaches the goal but violates this trajectory constraint.
A planner then solves Pc for an alternative plan τc. A problem is kept only if all three conditions hold: τ0 succeeds on the original problem, τc succeeds on the constrained problem, and τ0 is judged a safety violation on the constrained problem. In other words, the added constraint must invalidate the original plan while a verified alternative remains; the authors call these instances behavior-changing. The paper cautions that this definition is relative to the selected baseline plan and does not imply that the formal specification captures every real-world hazard. Difficulty is assigned solely by the length of the verified plan (Easy, Medium, Hard); each problem yields one PDDL prompt and one prompt in structured or narrative natural language; for 20% of problems a teacher model, GPT-5.4-mini, generates additional candidate plans, which are kept only if the same verifier accepts them.
The effect of the data composition is tested in one comparison. On Qwen3-4B with SFT alone, the authors compare three positive-only datasets of equal size: U-SFT uses unconstrained plans, OC-SFT a mixture in which the constraint leaves the nominal solution unchanged in half the problems and is behavior-changing in the other half, and BC-SFT only behavior-changing instances. “Conditional safety violation” is the fraction of goal-reaching outputs that violate at least one constraint.
| Data | Success (95% CI) | Goal reach | Conditional safety violation |
|---|---|---|---|
| U-SFT | 3.5% [1.7, 7.0] | 17.5% | 80.0% |
| OC-SFT | 53.0% [46.1, 59.8] | 56.0% | 5.4% |
| BC-SFT | 59.0% [52.1, 65.6] | 59.5% | 0.8% |
The three columns are mutually consistent (this site’s check): 17.5% × (1 − 0.800) = 3.5%, 56.0% × (1 − 0.054) ≈ 53.0%, 59.5% × (1 − 0.008) ≈ 59.0%. The main difference is in conditional safety violation: for the model trained without constraints, 80% of goal-reaching plans violate a constraint; training only on behavior-changing instances brings this down to 0.8%. The success-rate confidence intervals of OC-SFT and BC-SFT overlap, so the gap in success between them is not established by these data; the ablation was run on one model with SFT only.
Rewards: the verifier sets the interval, planner distance only ranks within it
In the GRPO stage, K = 4 candidate plans are sampled per prompt and scored directly by the verifier, without training a separate reward model or critic. Format errors receive a fixed −1 and successes a fixed 1; the three intermediate failure types each get a non-overlapping negative interval, set in the paper to [−0.9, −0.7] for precondition violations, [−0.6, −0.4] for safety violations and [−0.3, −0.1] for goal failures. The authors explain the order: a precondition violation cannot even produce a complete trajectory, and among executable plans a safety violation is treated as more severe than a safe plan that only fails to reach the goal.
Within a failure category, candidates are separated by progress computed with a classical planner. An evaluation state is chosen (for a precondition violation, the state before the failed action; for a safety violation, the first state where the violation is detected, or the terminal state for constraints evaluated over the whole trajectory; for a goal failure, the terminal state), the shortest plan length d_res from it to the goal is computed, and it is compared with the shortest length d_init from the original initial state:
ϕ_dist = (d_init − d_res) / (d_init + d_res + ε)
r = ℓ_c + (h_c − ℓ_c) · (ϕ_dist + 1) / 2If the planner cannot solve the residual problem within its time limit, the lowest progress value is assigned. A worked example with hypothetical numbers (this site’s illustration, not data from the paper): for a plan with a safety violation, d_init = 10, and the state at the violation is still d_res = 4 steps from the goal; ignoring ε, ϕ_dist = 6/14 ≈ 0.43 and the reward is ≈ −0.6 + 0.2 × 0.71 ≈ −0.46. Even a precondition violation with full progress (ϕ_dist = 1) only gets −0.7, still below any safety violation. In other words, the progress term can only rank candidates within the interval set by the verifier; it cannot lift one failure category into a higher one. Successful plans get no plan-length term, because the objective is to raise verifier acceptance rather than optimize plan cost.
Physical AI Lab 1.7: Reinforcement Learning worked out one episode’s return to show how a badly written shaped reward gets gamed. SLoSa’s interval design is one structured response to that problem; the text read does not test separately whether it prevents gaming. Two more training details: when all four candidates in a group receive identical rewards, the group carries no relative preference signal, is marked inactive and is excluded from both the policy and KL terms; GRPO follows a three-stage curriculum with Easy/Medium/Hard sampling ratios of 6/3/1, 1/6/3 and 1/3/6 over 125, 250 and 125 steps respectively.
Results: higher success comes mostly from fewer precondition violations
The three backbones are open models loaded with 4-bit quantization and adapted with LoRA (rank 32): Qwen3-4B, Llama-8B (Llama 3.1 8B Instruct) and Qwen3-14B. Evaluation uses greedy decoding without intermediate chain-of-thought output, and Qwen3’s thinking mode is disabled in training and evaluation. PT denotes the original model before SLoSa post-training. The table below gives results on the 200-instance PDDL test set; the five columns are mutually exclusive and sum to 100%:
| Model | Stage | Success | Goal failure | Safety violation | Precondition violation | Format error |
|---|---|---|---|---|---|---|
| GPT-5.6 Sol | Direct prompting | 26.5 | 0.0 | 0.5 | 73.0 | 0.0 |
| Claude Sonnet 5 | Direct prompting | 31.0 | 3.5 | 0.0 | 55.5 | 10.0 |
| Qwen3-4B | PT / SFT / GRPO | 0.0 / 59.0 / 70.5 | 1.5 / 1.5 / 1.5 | 0.0 / 0.5 / 0.5 | 0.0 / 36.5 / 25.0 | 98.5 / 2.5 / 2.5 |
| Llama-8B | PT / SFT / GRPO | 0.0 / 62.0 / 74.0 | 5.0 / 5.5 / 7.5 | 0.0 / 1.0 / 0.0 | 70.0 / 30.5 / 18.0 | 25.0 / 1.0 / 0.5 |
| Qwen3-14B | PT / SFT / GRPO | 0.0 / 67.0 / 76.0 | 0.5 / 2.5 / 1.5 | 0.0 / 0.0 / 0.0 | 0.0 / 30.5 / 22.0 | 99.5 / 0.0 / 0.5 |
The jump from PT to SFT mainly reflects the models learning the task-specific action vocabulary and strict output format: in the PT stage, 98.5% and 99.5% of the two Qwen3 models’ outputs are format errors. From SFT to GRPO, success rises by 9.0–12.0 percentage points across the three models while precondition violations fall by 8.5–12.5 points (this site’s arithmetic from the table), so most of GRPO’s gain comes from making plans executable. Citing the two directly prompted large models (26.5% and 31.0%), the authors argue that model scale alone does not replace safety-aware post-training. Note that these two models received no task-specific training, the text read does not give their prompts, and their failures are also mostly precondition violations.
The authors also plugged the three Llama-8B checkpoints into SafePilot, which returns verifier-rejected plans with feedback for revision for at most three rounds and accepts only plans that pass every check. On the 200 instances, final success for PT, SFT and GRPO is 0.5%, 68.0% and 77.5%, gains of 0.5, 6.0 and 3.5 points over first-pass success; the average number of iterations (including the initial generation) is 2.995, 1.735 and 1.500, and average tokens are 5,185.81, 2,179.52 and 1,782.87. Subtracting the gains gives first-pass success of 62.0% and 74.0% for SFT and GRPO, matching the Llama-8B figures in the table above (this site’s check). What this shows is that better first-pass quality means the repair loop needs fewer rounds and tokens.
The same pipeline was also applied separately to Qwen3-4B on adapted versions of two household benchmarks: success on VirtualHome-Safe is 0.0% (PT), 74.5% (SFT) and 80.5% (GRPO), and on ALFWorld-FO-Safe 0.0%, 76.0% and 85.0%. Both are fully observed, non-interactive adaptations in which the model must emit a complete plan with no intermediate environment feedback or replanning; ALFWorld-FO-Safe exposes the complete symbolic state and is not the standard partially observed, interactive ALFWorld protocol. The paper states that these examples assess high-level symbolic safety compliance, not physical collision safety.
Deployment: low power on a Jetson Orin, but a plan takes over ten seconds
Edge tests were run on an NVIDIA RTX 4080 (16GB) and a Jetson AGX Orin Developer Kit (64GB) with INT4 inference, batch size one and a single concurrent request; each model ran the same 100 PDDL prompts three times after 20 warmup queries. Latency includes generation and parsing; throughput counts generation only; energy per plan divides the measured inference energy (including inter-request overhead) by the number of plans and excludes model loading, warmup and validation energy.
| Hardware | Model | P50 (s) | P90 (s) | Tokens/s | Peak memory (GB) | Avg. power (W) | Energy per plan (J) |
|---|---|---|---|---|---|---|---|
| RTX 4080 | Qwen3-4B | 6.65 | 8.66 | 11.73 | 3.80 | 71.16 | 464.75 |
| RTX 4080 | Llama-8B | 6.01 | 7.77 | 13.19 | 5.91 | 88.14 | 516.70 |
| RTX 4080 | Qwen3-14B | 8.03 | 11.11 | 9.77 | 11.22 | 122.90 | 983.78 |
| Jetson Orin | Qwen3-4B | 18.28 | 23.53 | 4.30 | 3.89 | 17.85 | 316.33 |
| Jetson Orin | Llama-8B | 15.88 | 20.01 | 5.01 | 6.06 | 23.14 | 355.18 |
| Jetson Orin | Qwen3-14B | 22.00 | 30.04 | 3.55 | 11.50 | 26.41 | 581.14 |
The “17.85–26.41 W” in the abstract is the average power of the three Jetson Orin rows. The same table shows the other side: P50 latency on the Orin is 15.88–22.00 s, about 2.6–2.7 times that of the same model on the RTX 4080; yet because power is much lower, energy per plan is lower than on the RTX 4080 (316.33 J versus 464.75 J for Qwen3-4B). This is a task-level, high-level planner that produces a plan in over ten seconds (median 15.88–22.00 s), a different layer from a millisecond-scale low-level control loop; Physical AI Lab 0.3: See, Think, Act explained that each layer has its own rate. The text read does not say whether power was measured for the whole board or for the GPU only, nor does it report the spread of these measurements. One more distinction: Figure 4, on 41 Blocksworld instances with 10–50 blocks, compares the generation time of Fast Downward, OPTIC (with many larger instances hitting the 300-s timeout) and GPT-5.6 Sol, not SLoSa’s compact models; the text says only that GPT-5.6 Sol’s generation time stays “comparatively stable” and gives no share of valid plans for it on these instances. This site previously discussed 4-bit inference energy and latency in Frontier Radar | EdgeVLN and Frontier Radar deep dive | Edge and real-time; those results concern other models and hardware and cannot be compared directly with the numbers here.
The physical demonstration implements Blocksworld with a desktop 6-degree-of-freedom arm and a third-person camera. Each task is given as an image of the initial block configuration, an image of the goal configuration and a natural-language description of the safety constraints; a vision-language model grounds these into a PDDL3 problem (the text read does not name the model), a Qwen3-4B SFT or GRPO checkpoint generates a plan, a SafePilot-style verify-and-revise loop runs before execution, and only verifier-accepted plans are passed to the controller, which maps symbolic actions to predefined manipulation skills. Each planner is run 30 times:
| Metric (/30) | SFT | GRPO |
|---|---|---|
| Verifier-accepted plans | 17 | 19 |
| Verifier-rejected plans (not executed) | 13 | 11 |
| Successful executions | 13 | 14 |
| Low-level failures | 4 | 5 |
A low-level failure means a verifier-accepted plan could not be completed because limited execution precision caused a stacking failure or the resulting stack exceeded the arm’s reachable workspace; the paper states that these failures come from manipulation precision, not from violating the encoded symbolic constraints. The two checkpoints differ by a single successful execution (13 versus 14), and 30 trials are not enough to separate them on that basis; Physical AI Lab 1.8: Evaluation practiced reading gaps like this in small samples. What this experiment shows is that the verifier stopped 11–13 unacceptable high-level plans from being sent straight to the robot; it is not a hardware safety validation.
Limitations
- This is an arXiv preprint; all numbers are author-reported [R] and this site has not reproduced them. The text read gives no release location for code, data or model weights.
- Limitations listed by the authors: SLoSa addresses only high-level task planning; its safety supervision comes from symbolic action models and formal verifier outcomes, and the reported safety performance measures compliance with the corresponding high-level constraints only; the evaluation does not cover perception errors, motion-level failures or unmodeled physical risks; long-horizon domains such as Blocksworld remain challenging; the desktop-arm evaluation uses one workcell and fixed low-level skills.
- The behavior-changing definition is relative to the selected baseline plan and does not mean the formal specification covers every real hazard. In the physical pipeline, if the PDDL3 problem produced by the vision-language model is wrong, the verifier can only check against that specification; the text read does not report the accuracy of this step separately.
- The low safety-violation shares in the results table must be read together with the check order: precondition-violating plans never enter the safety check. More direct evidence of the constraints’ effect on behavior is the conditional safety violation in the data ablation, which was run only on Qwen3-4B with SFT alone, and in which the success-rate confidence intervals of OC-SFT and BC-SFT overlap.
- The two directly prompted large models received no task-specific training, and the text read does not give their prompting setup; the comparison with the compact models is not made under equal conditions.
- The edge tests use batch size one, a single request and 100 prompts; the text read does not state what the power measurement covers or how much it varies. The table note says “energy per accepted plan” but defines it as division by the number of plans, without saying whether only verifier-accepted plans are counted. The ~2.6–2.7×, the 9.0–12.0 and 8.5–12.5 points, and the first-pass 62.0% and 74.0% are this site’s arithmetic from the paper’s tables. The d_init = 10 and d_res = 4 in the rewards section are hypothetical numbers.
Links
- SLoSa: Small, Low-Power, and Safe Foundation Models for Robotic Task Planning (arXiv 2610.28955)
- Full paper in HTML
- Physical AI Lab 0.3: See, Think, Act — Putting Each Rate Back in Its Own System
- Physical AI Lab 1.7: Reinforcement Learning — Working Out One Episode’s Return to See How a Reward Gets Gamed, Then Reading the Paper’s Terrain Curriculum and Time-out Resets
- Physical AI Lab 1.8: Evaluation — Splitting a “Net Gain of 2” into a Paired Table, Then Checking the Failure Labels and Random Seeds
- Frontier Radar | EdgeVLN: same 4 bits, 36.8× difference in step energy depending on the execution path
- Frontier Radar deep dive | Edge and real-time: where the latency budget of VLAs and world action models goes
- Physical AI Lab: a physical AI course where every number can be checked (course outline)
