Learning to Formalize: Bridging Open-Ended Workloads and Fast Decision Models

• Open-ended workloads provide context and an execution interface but often leave the useful alternatives implicit, requiring the backend to construct candidates as well as decide.A selector cannot recover an action omitted from its candidate interface.Source: §1 · p. 1
• 46.5% success with DeepSeek V4 Flash pose candidates compares with 11% using generic motions for the same Jev selector on 200 CALVIN-D test episodes.Both workflows use the same initial episodes, observations, action budget, and success oracle.Source: §1 · p. 1
• A small formalizer constructs explicit alternatives from workload context, and a frozen decision model selects an entry for the application.A validator checks the proposed list against the application's schema and declared constraints.Source: §1 · pp. 1–2
• The formalizer learns candidate-list construction from offline teacher-generated lists, without generating a full reasoning transcript or making the final choice at deployment.Its narrower task still requires semantic interpretation, not only JSON formatting.Source: §1 · p. 2
• 52.1% success at 1.826 s per decision for the 1.7B pipeline compares with 31.8% at 3.670 s for direct Qwen3.5-27B generation.The paper also reports 14.2% fewer reserved evaluation GPU-hours; the 4B pipeline reaches 52.6% success but uses more resources than direct generation.Source: §1 · p. 2

2.1 Open-Ended Workloads and Choice Interfaces

• An action schema defines expressible operations, but parameterized workloads may require a context-dependent candidate subset before a choice interface can select practically.Ranking options does not supply missing candidates or certify the outcome of execution.Source: §2.1 · pp. 2–3

2.2 Advantages of Decision Models

• 138 ms median hosted Jev latency contrasts with 8.387 s for Qwen3.6-27B verbal generation and 0.997 s using option likelihoods on an A100.These measurements use different serving setups and illustrate deployment latency profiles rather than isolate an architectural speedup.Source: §2.2 · p. 3

2.3 Generative Reasoning, Decoding, and Distillation

• Generating intermediate reasoning can lengthen sequential decoding, while teacher-produced sequences can train a student to expose competing alternatives for a downstream selector.The student-generated list still adds cost that must be measured in the complete pipeline.Source: §2.3 · p. 3

2.4 Structured Decisions in Embodied Tasks

• CALVIN tasks define an action schema but do not enumerate useful target poses for each state, making candidate construction a step before selection.Embodied approaches also differ in observation formats and execution interfaces, which comparisons must account for.Source: §2.4 · p. 3

3.1 Bridging the Candidate Interface

• A small formalizer constructs task-relevant alternatives from context, while a separate frozen decision model selects among them.The selector cannot recover an action omitted from the candidate interface.Source: §3.1 · pp. 3–4

3.2 Task Context and Formalized Candidates

• The formalizer turns task context into a configurable ordered list of alternatives, each with an executable payload and optional purpose description.Context can include the goal, available state, interaction history, and applicable budget.Source: §3.2 · p. 4

3.3 Validation, Selection, and Application

• A schema validator checks structural constraints, but validity does not establish semantic usefulness; applications consume only the selected payload.Each new schema needs corresponding supervision and adapters, and cross-domain transfer is not assumed.Source: §3.3 · p. 4

3.4 Distilling Candidate Lists

• The student learns to produce teacher-generated candidate lists through supervised next-token prediction, without a learned reward or additional coverage objective.Sequence supervision is not permutation-invariant, so candidate order and wording can affect learning; coverage and downstream performance require separate measurement.Source: §3.4 · pp. 4–5

3.5 Independent Selection and the Latency Tradeoff

• Keeping generator and selector parameters fixed during evaluation enables controlled comparisons, but longer lists or complex payloads can erase latency savings.The evaluation measures both stages, total decision latency, and task success; sequential feedback can also shift contexts beyond teacher collection.Source: §3.5 · p. 5

4.1 Evaluation Scope and Research Questions

• The local study compares fine-tuned and base Qwen3 models at two sizes with the same frozen selector, generic Jev selection, and direct Qwen3.5-27B generation.The base/SFT pairs control generator architecture and serving setup, while generic and direct arms differ in candidate budgets or model families.Source: §4.1 · p. 6

4.2 Experimental Setup

• CALVIN environment-D validation annotations across 34 manipulation tasks, excluded from SFT and checkpoint selection, are evaluated once per arm from fresh physics, with up to 12 decisions and 360 simulator steps; unrecovered failures count against success.Four episodes run concurrently, and physics pauses during inference.Source: §4.2 · p. 6

4.3 Motivating Comparison with the Official Jev API

• On the same 200 test episodes, DeepSeek V4 Flash pose candidates yield 46.5% success versus 11% with generic motions in the official Jev comparison.The observed difference is 35.5 percentage points; candidate source and count both change.Source: Table 1 · p. 6, §4.3 · p. 6

4.4 Task Outcomes and Formalizer Size

• 52.6% and 52.1% success for SFT Qwen3-4B and Qwen3-1.7B, versus 11.8% and 4.5% for their base counterparts; both SFT pipelines exceed direct Qwen3.5-27B's 31.8%.The six-arm comparison covers 1,011 validation annotations; the table measures complete decisions, including parsing, validation, and repairs.Source: §4.4 · pp. 6–7, Table 2 · p. 7
• On the previously uninspected 811 annotations, SFT 4B and 1.7B achieve 53.9% and 53.1% success versus 31.9% for direct generation, while per-task outcomes remain heterogeneous.Neither SFT pipeline succeeds on the 29 drawer-closing annotations, where base 4B succeeds on 14.Source: Table 3 · p. 7, §4.4 · p. 7

4.5 Latency and Request-Level Analysis

• Mean decision latency is 2.573 s for SFT 4B and 1.826 s for SFT 1.7B, versus 3.670 s for direct generation; request-stage means cannot be added to recover decision latency.The table distinguishes request latency from prefill and decode components; repairs add generation requests, while failed generation skips selection.Source: §4.5 · p. 7, Table 4 · p. 8

4.6 Resource Use

• SFT 1.7B reduces evaluation GPU-hours by 14.2% and energy by 17.0% versus direct generation, while SFT 4B uses 18.5% and 6.1% more, respectively.The table reports elapsed time, reserved GPU-hours, and whole-board energy; hybrids reserve two boards, including waiting.Source: Table 5 · p. 8, §4.6 · p. 8

4.7 Discussion

• The study does not establish transfer across datasets or selector families; repeated runs and further controls are needed to assess stability and isolate component contributions.The discussion also notes that measured latency does not establish universal compute savings.Source: §4.6 · p. 8, §4.7 · p. 9

5 Conclusion

• 52.1% success at 1.826 s per decision for the 1.7B pipeline compares with 31.8% at 3.670 s for direct Qwen3.5-27B generation.The 4B pipeline reaches 52.6% success but uses more resources than direct generation.Source: §5 · p. 9
• A small formalizer trained on teacher-generated lists constructs candidates for a frozen selector, bridging open-ended workloads and explicit-choice decision models.The formalizer and selector results are reported on validation episodes excluded from training and checkpoint selection.Source: §5 · p. 9
• The results support a success–latency tradeoff on CALVIN-D validation, but broader datasets and controlled component comparisons are needed to establish wider benefit.Source: §5 · p. 9

Limitations

• CALVIN-D manipulation with privileged state and paused physics does not establish real-time performance or transfer across datasets, schemas, or selector families.Normalizing pre-existing informal alternatives also remains unevaluated.Source: Limitations · p. 9
• Each annotation is evaluated once per arm and annotations may overlap, so repeated runs and dependence-aware uncertainty are needed to assess stability.Source: Limitations · p. 9
• Different candidate counts and model families mean the comparisons establish pipeline-level tradeoffs without isolating candidate quality, output validity, or selector contribution.The official-API study also provides no latency measurements.Source: Limitations · p. 9
• Resource savings depend on formalizer size: SFT 1.7B uses fewer evaluation GPU-hours and less board energy than direct generation, whereas SFT 4B uses more.Costs exclude teacher collection, SFT, and CPU/system energy.Source: Limitations · p. 9