{"id":"03e9efc2-1c9d-4b51-aa28-4705a1097100","arxiv_id":"2508.21063","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"A staged text-to-LEGO pipeline combining a fine-tuned LLM text-to-brick generator (BRICK GPT++) and a bimanual robotic assembler (BRICK MATIC) builds physical brick structures from natural-language prompts.","lead":"Prompt-to-Product takes a natural-language description, generates a LEGO brick design with a fine-tuned language model, and builds it with two robot arms. The paper reports that the combined pipeline reduces the physical and mental effort of making LEGO models, based on a user study with 21 participants.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Uncalibrated stability oracle is the load-bearing link: buildable-rate and construction-success claims both depend on fstability, which is only validated by four human-assisted builds.","rationale":"The reader's weakest_assumption correctly identifies the stability oracle as load-bearing. I agree: both the generative design filter and the construction planner depend on fstability, and the only physical validation is four builds whose success metric includes human intervention. The virtual-mass model for dynamic stability is an additional weak spot because it is uncalibrated against the robot's own force-torque sensor. This concern does not overturn the paper's narrow demonstration—four real LEGO structures were built—but it does justify keeping the verdict CONDITIONAL rather than ACCEPT. A held-out physical test with FTS logging would directly settle whether the oracle generalizes.","tokens_in":15781,"tokens_out":4445,"duration_ms":51612,"concrete_test":"Run a held-out physical validation: select 10 BRICK GPT++ designs that pass fstability with varied stability margins (e.g., min s_i between 0.05 and 0.5), build each with BRICK MATIC while logging ATI FTS forces during Place-Down/Place-Up/Support, and compare predicted vs observed collapses under strictly no-human-intervention operation. If any brick with s_i>0 collapses, or the measured peak contact force exceeds the equivalent of the 1 kg virtual mass, the oracle/dynamic model is not validated and the buildable-rate claims need recalibration.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The pipeline's guarantee B∈B(u|I,A,S) rests on fstability (Eq. 1) from StableLEGO. It is used to filter StableText2Brick (Sec IV-A), to prune generated designs via physics-aware rollback (Sec IV-B), to plan the assembly sequence through static/dynamic action masks (Sec V-C), and to compute '% Buildable' in Table I. No experiment calibrates fstability against physical outcomes except the four Table II builds, and those builds count as successes even when the system pauses for human intervention. The dynamic-stability model specifically adds a +1 kg virtual brick for placement and a -1 kg virtual brick for support (Sec V-C), but the EOAT is equipped with an ATI FTS whose measured forces are never used to validate these masses; placement impact is modeled as a static 1 kg load, potentially underestimating a real insertion impulse. If the oracle is over-optimistic on larger or open-ended designs—the same regime where the Discussion concedes degraded performance—the 66.6% buildable rate and Table II success rates support only the four demonstrated instances, not the central claim's generality. The four physical builds are real positive evidence, but they are too narrow to validate the oracle's use as the sole gate for buildability.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper describes Prompt-to-Product, a two-stage system that converts a natural-language prompt into a physical LEGO assembly. Stage 1, BRICK GPT++ (an LLM fine-tuned on StableText2Brick), generates brick layouts subject to inventory and collision checks, with physics-aware rollback and multi-head CLIP selection. Stage 2, BRICK MATIC, plans a bimanual construction sequence using assembly-by-disassembly, action masks, and APEX-MR-style temporal plan graphs, then executes it with two Yaskawa GP4 arms with custom Eye-in-Finger EOATs and a skill set including pick/place/support/handover and perception skills. The central coupling is a stability oracle from StableLEGO (Eqs. 4-6), used to certify final designs, prune intermediate structures, and model robot impacts as virtual bricks of +1kg and -1kg. Experiments report a buildable rate of 66.6% for BRICK GPT++ over 36 prompts (Table I), physical construction of four designs in one attempt each (Table II), and a 21-participant user study showing reduced effort.","tokens_in":16116,"tokens_out":6583,"duration_ms":70020,"significance":"If the claims hold, the paper is a worthwhile integration of generative design and bimanual manipulation for a concrete, replicable assembly domain. The strongest evidence is the physical construction of four nontrivial structures with a real dual-arm system; this distinguishes the paper from simulation-only pipelines. The staged architecture and the use of shared physics reasoning are sensible engineering contributions. The perception-skill additions (detect place/pick/anomaly/error) are a plausible reason for improved robustness over APEX-MR. However, the quantitative claims are narrower than their presentation: the buildability metric is oracle-based, the construction table has one attempt per design, and the stability oracle is uncalibrated against measured forces. These issues do not invalidate the demonstrated integrations but they materially limit the generality claimed in the abstract.","major_comments":[{"comment":"The stability oracle f_stability is the single load-bearing gate for both design generation and construction planning, but it is never calibrated against physical outcomes. The dynamic-stability check models a place operation as a virtual brick with 1 kg mass and support as a -1 kg mass (Sec. V-C), yet the robot is instrumented with ATI FTS and the measured forces are not used to substantiate these values or the static friction capacity FT in Eq. (6). The only physical validation is the four builds in Table II, all of which are designs that the oracle presumably deemed stable. If the oracle is over-optimistic on larger or more open-ended designs, the buildable rate in Table I and the success in Table II will not transfer. Please add a calibration/validation study: for example, measure peak insertion/support forces, tune the virtual-brick masses, and test a set of designs spanning oracle-","section":"Sec. III, Eqs. (5)-(6); Sec. V-C; Table I"},{"comment":"The construction comparison uses different success criteria. A successful build is defined as 'without manually stopping or restarting,' but the text then states that BRICK MATIC automatically pauses and requests human intervention, and continues once the failure is addressed without starting over. Thus an attempt that required one or more human interventions is still counted as a 1/1 success, while the APEX-MR baseline restarts after any failure. The reported '1/1' therefore does not demonstrate fully autonomous construction, and with n=1 per design there is no evidence of repeatability. Please report the number and type of human interventions per build, use a single success definition for both systems (e.g., fully autonomous completion vs. completion with human assistance), and provide multiple trials or at least state explicitly that these are single demonstrations.","section":"Sec. VI-B, Table II"},{"comment":"The central metric '% Buildable' in Table I is computed with the authors' own feasibility stack: f_stability from StableLEGO [13] and the action masks from [15]. This makes the comparison of BRICK GPT++ to BRICK GPT an oracle-level comparison, not a physical one. Since the same oracle is the thing whose accuracy is at issue (see first major comment), the 66.6% figure should be labeled as 'predicted buildable by the internal oracle' and, ideally, supported by a small physical spot-check on randomly selected designs from the 36 prompts. Without this, Table I's improvement may reflect oracle biases rather than real buildable rate.","section":"Sec. IV-C, Table I; Sec. II-E"}],"minor_comments":[{"comment":"The notation 'tau * ˙=' appears to be a typo; it should be an equality sign.","section":"Sec. II-B, Eq. (4)"},{"comment":"The full-pipeline user study used the Gazebo digital twin with physical interactions between bricks disabled, not the physical BRICK MATIC system. This is stated in Sec. VI-A but should be repeated as a limitation in Sec. VI-C so that the user-study claims about BRICK MATIC are not overread as physical-robot results.","section":"Sec. VI-A, Sec. VI-C"},{"comment":"The 'Time' column reports planning time, not total execution time. Please label it 'Planning Time' in the header or clarify in the caption.","section":"Table II"},{"comment":"The statement 'manual creation time ranged from under 2 to over 7 minutes' would be more informative with a mean and standard deviation.","section":"Sec. VI-C"},{"comment":"The text states 'StableText2Brick ⊂ B(u | I, S)' but the notation B(u | I, S) depends on the prompt u; the inclusion should be 'StableText2Brick ⊂ ∪_u B(u | I, S)' or be phrased as 'each structure in StableText2Brick is physically buildable.'","section":"Sec. IV-A"}],"recommendation":"major_revision","confidential_remarks":"The paper leans heavily on the authors' own prior systems (StableLEGO, BRICK GPT, APEX-MR, action masking) both as components and as baselines. This is not improper, but because the same stability oracle is used for both generation and evaluation, an independent or at least more adversarial evaluation would strengthen the manuscript. The n=1 physical trials and the human-intervention policy in Table II are likely to be a reviewer focus; I suggest the authors preemptively add calibration data, per-build intervention logs, and a clearer separation between autonomous and human-assisted success."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Bottom line: this is a working hardware system, not a simulation paper. BRICK MATIC's Eye-in-Finger tooling, the perception skills, and the bimanual assembly reasoning are genuinely new in the LEGO-robotics space. The four physical builds—Faucet, Fish, Vessel, Guitar—are real results, and the contrast with the dual-arm baseline is useful evidence that the added perception skills help. The generative part, BRICK GPT++, is a modest extension of their own BRICK GPT, but multi-head generation plus rejection sampling buys a real improvement in buildable rate (19.4% to 66.6%) and CLIP score. The user study is small but directionally consistent with the effort-reduction claim.\n\nThe soft spots are mostly about evaluation breadth and the load-bearing stability oracle. fstability from StableLEGO is used to prune designs, plan assembly sequences, and compute the buildable rate. It is a serious model, but it is only validated indirectly by those four builds. The dynamic-stability check adds 1 kg and -1 kg virtual bricks, and the FTS data is never used to calibrate those masses. That matters because the whole guarantee that B lies in B(u|I,A,S) depends on this oracle. The stress-test note is right: four builds, even successful ones, are a thin basis for the generality implied by the pipeline diagram. I would soften one part—the builds are genuine positive evidence, not just a formality—but the calibration gap remains.\n\nAlso, Table II's success metric is softer than it looks: BRICK MATIC pauses and asks a human for recovery, and that still counts as a success. The baseline APEX-MR restarts from scratch. That is a meaningful difference in robustness, but it is not a fair full-autonomy comparison as written. Sample sizes are also n=1 for each BRICK MATIC design. The self-referential baselines (their own oracle, their own systems) are worth noting but not disqualifying—any integration paper has to start somewhere. The Discussion already concedes open-ended prompts are degraded.\n\nWho is this for? Robotics researchers working on assembly, manipulation, and text-to-drug pipelines. A serious referee should engage with it. I would want the authors to add more physical validation of the oracle, more trials per structure, and a clearer breakdown of when human intervention happened. That is revision-worthy, not desk-reject worthy.","headline":"A real bimanual text-to-LEGO pipeline with honest limitations; the main caveat is that the stability oracle gating the whole pipeline is only validated by four human-assisted builds.","tokens_in":659,"tokens_out":839,"would_cite":true,"duration_ms":27039,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Prompt-to-Product claims to turn natural-language prompts into physically buildable and physically constructed LEGO assemblies, coupling an LLM-based designer with a bimanual robot builder through a shared structural-stability oracle.","keywords":["prompt-to-product","LEGO brick assembly","bimanual manipulation","structural stability reasoning","generative assembly design","text-to-3D generation","assembly-by-disassembly","robot skill learning"],"falsifier":"Have the robot attempt to build a set of, say, fifty structures the oracle scores as stable and fifty it scores as unstable using the same inventory and skills, then record collapse rates: if stable-scored structures frequently fall or unstable-scored ones stand, the oracle's threshold is not predictive. A more targeted test is to measure the end-effector force during real Place-Down and Support-Bottom actions and compare it with the virtual ±1 kg bricks; a large mismatch would indicate the dynamic-stability checks are protecting the wrong failure modes.","tokens_in":15664,"feed_emoji":"🧱","tokens_out":8193,"duration_ms":78949,"temperature":0.7,"pith_summary":"Prompt-to-Product claims to remove both expert steps between an idea and a physical assembly product: generating the design and building it. Given a natural-language prompt, the paper's design stage runs eight parallel instances of a text-to-brick model, keeps only layouts that use the available inventory and pass a per-brick stability check, and renders the best candidate for the user. The construction stage then has two robot arms snap the bricks together in an order recomputed so that every partial structure is stable under the robot's own forces, with camera-based checks at each step. In a user study with 21 participants, the full pipeline significantly reduced self-reported physical and mental effort compared with manual creation, and the robot assembled four test products on the first attempt. If these results hold, the paper establishes a working end-to-end path from text to tangible modular objects.","feed_headline":"Robots build LEGO products from text prompts, no human assembly","feed_subtitle":"A shared physics check filters unstable designs and plans each brick placement, so the robot finishes in one attempt.","key_machinery":"The shared load-bearing mechanism is the structural-stability oracle fstability(B), which solves a nonlinear force-balance program over all connection forces, friction, and gravity to assign every brick a stability score si > 0 if it can reach static equilibrium. The oracle is used in three places: it prunes unstable candidates after BrickGPT generates them; it rejects disassembly steps that would leave a partial structure unstable during assembly-sequence search; and, with virtual bricks of +1 kg and -1 kg added to model the placing hand and a supporting hand, it checks whether the partially built structure survives the robot's own actions. This single oracle is what couples the creative an","core_discovery":"On its own terms, the paper's claim is that the feasible space B(u | I, A, S)—prompts whose generated brick layouts satisfy inventory limits, system skills, and stepwise stability—can be navigated automatically, and the paper supports this with a working system rather than a theoretical guarantee. The design stage, BrickGPT, generates brick layouts as text and uses brick-by-brick rejection sampling plus physics-aware rollback to keep every output stable; the construction stage, BrickMatic, replans the generation order by assembly-by-disassembly, models each robot placement as a heavy virtual brick in a force-balance solver, and executes the resulting temporal plan graph with two arms and eye","pith_inferences":["The paper does not test this, but the design/construction split means the stability oracle is the only physical coupling; swapping it for a different feasibility model would plausibly let the same designer target other modular materials, kits, or even manual build instructions.","A third of open-world prompts still produce no buildable design; a natural next step would be to use the stability score as a training objective rather than a post-hoc rollback filter, which could shrink the failure rate without more parallel samples.","The +1 kg/-1 kg virtual bricks used to model robot forces are chosen rather than calibrated; reading the force-torque sensors during real placement and support actions would test whether the dynamic-stability checks are conservative, permissive, or about right.","The user study found no significant preference between manual and generated starting designs, so the system may be most defensible as a fast scaffold that users then customize, rather than as an oracle that finalizes the design."],"forward_implications":["Users without assembly expertise can go from a text idea to a finished brick product; the user study reports significantly lower physical and mental effort with the full pipeline than with manual creation.","Perception-augmented bimanual assembly—checking every pick, place, and anomaly and pausing for human recovery instead of restarting—is what lets the system finish four designs in one attempt, where the comparison dual-arm system failed on one and needed multiple restarts on the others.","Running multiple generative heads with stability rollback raises the share of prompts that yield a buildable design from 19.4% to 66.6%, so inference-time filtering is an effective way to enforce physical constraints on a text-to-brick model.","Generated designs are not just end-state stable: the assembly-by-disassembly step reorders bricks so every intermediate structure is stable, which is why a design from the generator can actually be constructed.","For repeated production, users prefer robotic assembly over manual, while for a single one-off build they lean manual, indicating the pipeline's practical value is batch fabrication rather than one-off hobby assembly."],"supporting_citations":[{"why":"Supplies the stability oracle fstability: the nonlinear force-balance solver that scores every brick and is used for design pruning, assembly sequencing, and dynamic-stability checks.","marker":"[13]"},{"why":"Supplies the BrickGPT text-to-brick generation method and the StableText2Brick dataset of stability-verified brick structures used to fine-tune it.","marker":"[22]"},{"why":"Supplies the APEX-MR asynchronous task/motion/action planning method used to build the bimanual execution graph, and serves as the dual-arm baseline in construction comparisons.","marker":"[5]"},{"why":"Supplies the action mask that decides whether a brick can be removed from a partial structure under the robot's skill set and stability constraints during assembly-by-disassembly search.","marker":"[15]"},{"why":"Supplies the insert-and-twist policy used for robust brick pick and place operations.","marker":"[14]"},{"why":"Supplies the CLIP text-image similarity score used to select the best of multiple generated designs.","marker":"[23]"},{"why":"Supplies the assemble-by-disassembly search that BrickMatic reverses to plan a stepwise stable assembly sequence.","marker":"[25]"}],"fun_headline_variants":["Text to LEGO: robot builds your prompt's product","Robot turns natural language prompts into LEGO assemblies","Brick by brick, robot assembles LEGO from text prompts","From text to tangible: bimanual robot builds LEGO designs","Say it, see it: robot builds your LEGO idea"],"cache_read_input_tokens":2688,"weakest_assumption_plain":"The pipeline's guarantees stand on the stability oracle accurately predicting which real brick structures collapse, and on the assumption that representing the robot's placing hand as a 1 kg virtual brick and its support hand as a -1 kg virtual brick captures the forces that actually act during construction.","fun_headline_variants_meta":{"raw":{"variants":["Text to LEGO: robot builds your prompt's product","Robot turns natural language prompts into LEGO assemblies","Brick by brick, robot assembles LEGO from text prompts","From text to tangible: bimanual robot builds LEGO designs","Say it, see it: robot builds your LEGO idea"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000522,"raw_usage":{"total_tokens":2311,"prompt_tokens":639,"completion_tokens":1672,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":383,"completion_tokens_details":{"reasoning_tokens":1588}},"tokens_in":383,"tokens_out":1672,"duration_ms":12475,"temperature":1.0,"reasoning_tokens":1588,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T14:34:24.913326+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Have the robot attempt to build a set of, say, fifty structures the oracle scores as stable and fifty it scores as unstable using the same inventory and skills, then record collapse rates: if stable-scored structures frequently fall or unstable-scored ones stand, the oracle's threshold is not predictive. A more targeted test is to measure the end-effector force during real Place-Down and Support-Bottom actions and compare it with the virtual ±1 kg bricks; a large mismatch would indicate the dynamic-stability checks are protecting the wrong failure modes.","supporting_citations":[{"cited_title":"Stablelego: Stability analysis of block stacking assembly","cited_arxiv_id":null,"evidence_quote":"Supplies the stability oracle fstability: the nonlinear force-balance solver that scores every brick and is used for design pruning, assembly sequencing, and dynamic-stability checks."},{"cited_title":"Generating physically stable and buildable brick structures from text","cited_arxiv_id":null,"evidence_quote":"Supplies the BrickGPT text-to-brick generation method and the StableText2Brick dataset of stability-verified brick structures used to fine-tune it."},{"cited_title":"Apex-mr: Multi-robot asynchronous planning 11 Fig","cited_arxiv_id":null,"evidence_quote":"Supplies the APEX-MR asynchronous task/motion/action planning method used to build the bimanual execution graph, and serves as the dual-arm baseline in construction comparisons."},{"cited_title":"Physics- aware combinatorial assembly sequence planning using data-free action masking","cited_arxiv_id":null,"evidence_quote":"Supplies the action mask that decides whether a brick can be removed from a partial structure under the robot's skill set and stability constraints during assembly-by-disassembly search."},{"cited_title":"A lightweight and transferable design for robust lego manipulation","cited_arxiv_id":null,"evidence_quote":"Supplies the insert-and-twist policy used for robust brick pick and place operations."},{"cited_title":"Learning transferable visual models from natural language supervision","cited_arxiv_id":null,"evidence_quote":"Supplies the CLIP text-image similarity score used to select the best of multiple generated designs."},{"cited_title":"Willis, and Wojciech Matusik","cited_arxiv_id":null,"evidence_quote":"Supplies the assemble-by-disassembly search that BrickMatic reverses to plan a stepwise stable assembly sequence."}],"review_version":1}