{"id":"85a3d54b-5a5f-40fc-9813-8c6dd35dc2da","arxiv_id":"2509.02902","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"LiGuard is a new open-source GUI tool that lets lidar researchers assemble, reorder, and tune processing pipelines interactively instead of writing custom code for each experiment.","lead":"This paper introduces LiGuard, an open-source GUI framework for assembling lidar data processing pipelines without rewriting code. It aims to make point cloud research in autonomous driving and traffic safety faster, more interactive, and easier to share.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"LiGuard's interactivity claim rests on an unvalidated data-dependency contract: the shared dictionary has no schema or dependency metadata, so arbitrary enable/disable/reorder may break pipelines. A permutation test of the paper's own Pipeline 2 would settle this.","rationale":"The reader identifies the modular-design assumption as the load-bearing premise; this stress-test agrees and sharpens it. The paper is honest about being a demonstration, and the open-source repository, example pipelines, and video tutorial are genuine independent support that the tool exists and runs. However, the central claim of 'interactive' and 'reusable' pipelines requires more than the absence of hardcoded function calls. It requires a contract for the shared data dictionary: what keys each function produces and consumes, and what happens when those keys are absent. The paper does not describe such a contract, and the case studies do not exercise reordering or disabling in a way that would reveal violations. The proposed permutation test is a direct, low-cost check: if the framework crashes or produces wrong results for reasonable permutations, then the interactivity claim is overbroad and the paper should either add dependency validation or scope the claim to independent stages. This does not change the reader's CONDITIONAL verdict; it reinforces it and gives the authors a concrete path to strengthen the paper.","tokens_in":10815,"tokens_out":6104,"duration_ms":72819,"concrete_test":"Run a headless permutation test on the shipped Pipeline 2 example (six stages from Section IV-B) on the provided sample data. For each of the 720 permutations, set priorities accordingly, execute one frame, and record exceptions and outputs. Also run the 2^6 ablation that disables each stage. If any permutation or disable causes a raw KeyError/AttributeError from a downstream function rather than a clear dependency warning, or produces silently wrong outputs, the arbitrary-reorder claim is not supported. Additionally, inspect the source/GUI to check whether any validation prevents invalid reorderings; if none exists, that limitation must be documented. A pass would treat the documented order as the only supported configuration.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim—rapid, interactive, reusable, reproducible lidar research—depends on the modularity assertion in Section III: every functional step is independent and relies only on the shared data dictionary, so enabling, disabling, reordering, and replacing steps should work. But the architecture only removes hardcoded function-to-function calls; it does not remove or manage data dependencies. A function can consume keys produced by another function; the dictionary is an untyped global namespace with no schema, dependency declaration, or validation. The GUI permits live priority edits and toggling without checking whether required data will exist. Therefore, reordering or disabling a step can crash a downstream consumer or silently change semantics. The two case studies never exercise a nontrivial reorder/disable; Pipeline 2's stages are described in a fixed order. The paper's own qualifier, 'As long as the required data is available in the data stream' (Section III), concedes the gap: availability is the user's responsibility, not a framework guarantee. This is not a disagreement with community norms; it is an internal gap between the claimed interactivity and the demonstrated mechanism. If hidden couplings exist, the core differentiator over conventional code editing is substantially weakened.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents LiGuard, an open-source GUI-based framework for point cloud and image research, targeting ITS applications. It claims to enable rapid, interactive, reusable, and reproducible lidar experimentation by providing built-in readers, pre/post-processing functions, algorithms, visualizers, and an interactive pipeline editor built around a shared data dictionary. The architecture is described in Section III, and two case studies (KITTI PointPillars inference and a self-supervised label generation pipeline) are presented in Section IV as qualitative demonstrations. The central claim is that functional steps are independent (no hardcoded calls) so users can enable/disable/reorder steps and live-edit parameters.","tokens_in":11072,"tokens_out":3795,"duration_ms":48190,"significance":"If the claims are substantiated, LiGuard would provide a practical tool to reduce duplicated code and experimental rework in lidar-related research, especially for ITS applications. The open-source release, structured pipeline directories, custom function templates, and support for CARLA and multiple datasets are concrete contributions. The paper's value is in the system design and its potential community impact, but the current manuscript offers only qualitative case studies and no quantitative validation of the key interactivity and reusability claims.","major_comments":[{"comment":"The paper's central interactive/reorder claim rests on the modularity assertion that any function can be enabled/disabled/reordered because it only relies on the shared data dictionary. However, this assertion is not validated. The shared dictionary has no schema or dependency metadata, and the text itself qualifies the claim: 'As long as the required data is available in the data stream' (Section III). The GUI permits toggling functions without checking whether required keys exist. Neither case study exercises a non-trivial reorder or disable; Pipeline 2 is presented in a fixed order. This is a load-bearing gap: if hidden data dependencies break, the claimed 'interactive' advantage over conventional code editing is substantially weakened. Please either add dependency validation/schema or empirically demonstrate a non-trivial reorder/disable on both pipelines.","section":"Section III (Data Flow & Operation)"},{"comment":"The reusability case study using the custom dataset ends with the caption: 'The model is clearly hallucinating as the data is completely different.' This is not a successful demonstration of reusability; it shows the pipeline executes but produces meaningless detections. As a result, this example undermines the paper's effectiveness claim rather than supporting it. The authors should either replace this example with a case where the same pipeline produces useful results after appropriate retraining/fine-tuning, or explicitly frame this as a known limitation and discuss the additional steps required (e.g., domain adaptation). Presenting a failure as evidence of reusability is confusing and disproportionate to the claim.","section":"Section IV-A, Figure 5"},{"comment":"The paper does not provide any quantitative evidence for the 'rapid' or 'effective' claims. The two case studies are qualitative screenshots with no metrics such as time-to-pipeline, code-line reduction, number of GUI interactions, throughput, or usability measures. No comparison is made with a conventional code-based workflow (e.g., using Open3D/PCL directly). For a systems paper, some quantitative demonstration of the claimed productivity gains is needed, even if modest. Without it, the central contribution is only that the tool runs, which is not sufficient to distinguish it from existing SDKs.","section":"Section IV (Technology Demonstration)"}],"minor_comments":[{"comment":"Descriptions contain typos: 'Inifity' should be 'Infinity'; 'Trvelotocam' likely 'Tr_velo_to_cam'. The 'manualcalibration' row appears to combine three separate descriptions without separators.","section":"Table II"},{"comment":"Typo: 'Forth, for reproducibility' should be 'Fourth'.","section":"Abstract / Introduction"},{"comment":"The comparison table uses checkmarks without defining the criteria (e.g., what counts as 'Interactive GUI' or 'Data Agnostic Support'). This makes the comparison hard to interpret and potentially misleading.","section":"Table I"},{"comment":"Reference [36] is dated 2000; the associated GitHub repository for PointPillars is recent. Please verify and update the year. Reference [34] (PCL.py) should also list a proper URL.","section":"References"},{"comment":"The priority mechanism is defined within process categories, but it is unclear how ordering is handled across categories or whether cross-category reordering is supported in the GUI. A short clarification would help.","section":"Section III-C"}],"recommendation":"major_revision","confidential_remarks":"This is a software/tool paper whose value depends heavily on the credibility of the interactivity and reusability claims. The most serious issue is that the architecture's core invariant (untyped shared data dictionary) is not stress-tested. The Figure 5 hallucination example is an own-goal that should be fixed. If the authors can supply a dependency-validation mechanism or a convincing reorder/disable experiment, the paper could become acceptable. The reviewer also notes that the manuscript appears to use an IEEE journal template without the final number/DOI; that is a formatting matter for the editors."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"LiGuard is a real open-source GUI framework for building lidar processing pipelines, and it fills a genuine gap: PCL/Open3D are libraries, Paraview is a visualizer, but none give you a clickable pipeline editor that generates reusable code templates. The architecture is described clearly, the two case studies are appropriate (the second one, a multi-stage self-supervised labeling pipeline, is exactly the kind of thing researchers actually stitch together), and the code is on GitHub with examples. Full credit for honesty: the PointPillars example in Figure 5 is obviously hallucinating on out-of-domain data, and the authors say so rather than pretending it worked.\n\nThe soft spots are real but proportionate. The effectiveness claim rests on qualitative screenshots. No metrics, no user study, no comparison with hand-coded pipelines or with a baseline like a Jupyter notebook. The paper's own conclusion mentions 'several areas of improvement' but doesn't quantify any of them. That's the main thing a referee should push on.\n\nThe stress-test concern about the shared data dictionary is fair. The design makes functions independent in terms of hardcoded calls, but the dictionary is an untyped global namespace. Reordering or toggling a step can break a downstream consumer if the expected key isn't there. The authors do qualify this — 'as long as the required data is available in the data stream' — but that caveat is doing a lot of work: it means the interactive reordering promise is only as safe as the user's discipline. The case studies never exercise a non-trivial reorder or disable during execution, so the load-bearing claim is not actually demonstrated. That's not a fatal flaw, but it should be tested explicitly (e.g., a permutation test on pipeline 2) and the framework could add dependency metadata or validation.\n\nMinor: the preprint says version 2.1.3 but doesn't pin a commit or provide a DOI, which makes the reproducibility claim weaker than it could be. The table comparing features is useful but the checkmarks are a bit hand-wavy; some entries need footnotes.\n\nWho's this for? ITS/lidar researchers who want to quickly wire up pipelines without writing glue code. It's not a scientific discovery. It deserves a serious referee because it's a concrete, open-source tool that could genuinely reduce boilerplate, and the architectural claims are testable. My recommendation: send it for review, but require a quantitative or at least user-study-based validation and a discussion of the dependency contract before acceptance.","headline":"A genuinely useful open-source lidar pipeline tool, but the paper's interactive reordering claim is under-validated and the shared-data-dictionary dependency issue is the real soft spot.","tokens_in":11545,"tokens_out":2492,"would_cite":true,"duration_ms":27733,"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":"LiGuard lets lidar researchers reorder pipelines live, no rewiring.","keywords":["lidar","point cloud","interactive pipeline","open-source software","data dictionary","object detection","intelligent transportation systems","visualization"],"falsifier":"Run Pipeline 2 through the GUI and disable the background-filtering step while leaving downstream clustering and bounding-box regression enabled; if the pipeline silently produces garbage clusters or crashes without a clear error, the claimed modular independence is violated. Alternatively, reorder the background-filter and clustering steps via the GUI and observe whether the pipeline still executes or whether it raises an unexplained data-availability error.","tokens_in":10691,"feed_emoji":"📡","tokens_out":2678,"duration_ms":33387,"temperature":0.7,"pith_summary":"This paper presents LiGuard, an open-source, GUI-based framework for research on lidar point clouds and accompanying image data. The central claim is that by making every functional step of an experiment independent and communicating only through a shared data dictionary, researchers can rapidly assemble, tweak, and reuse multi-stage lidar pipelines without rewriting or recompiling code. The authors argue this addresses the common frustration of duplicated effort and tightly coupled code in lidar research. The value would be concrete: experiments that once required editing interdependent scripts can instead be built, ablated, and shared as structured, reorderable components. The paper demonstrates the claim with two case studies, one using a pre-trained PointPillars detector on the KITTI dataset and one using a custom roadside lidar dataset.","feed_headline":"A GUI framework that lets lidar researchers reorder pipelines live","feed_subtitle":"LiGuard handles data I/O, processing, and visualization so experiment steps can be reused, ablated, and shared by clicking.","key_machinery":"The shared data dictionary is the central mechanism: every function reads from and writes to this common structure, so no function invokes another directly. A companion configuration dictionary stores pipeline settings, and GUI panels expose these settings live, allowing on-the-fly reordering, enabling, disabling, and parameter adjustment without code changes.","core_discovery":"The paper's core claim is that a software framework with a modular, data-dictionary-centric architecture can make lidar research substantially faster and more reproducible. In LiGuard, every functional step—data reading, preprocessing, point cloud operations, image operations, labeling, and post-processing—is implemented as an independent function that reads input from and writes output to a shared data dictionary. Because no function is hardcoded to call another, users can enable, disable, reorder, and tune steps live through a GUI, and can create new custom steps from standardized templates. The authors argue that this design decouples the experiment logic from application plumbing, and th","pith_inferences":["The modular data-dictionary design could be extended beyond point clouds and images to other time-series or multi-modal sensor research, since the core independence principle is not lidar-specific.","A natural testable extension would be a user study measuring time-to-pipeline-completion or number of code edits for a standard task on LiGuard versus a conventional script-based approach; the paper does not provide such a quantitative comparison.","The claim that pipelines are automatically reproducible partly depends on the stability of the pipeline directory format and the compatibility of referenced external tools (e.g., Open3D, OpenCV, PointPillars), so version pinning would be a prudent extension.","The interactivity benefit is most valuable for iterative tuning loops with slow-to-edit parameters; the paper's case studies demonstrate this qualitatively but do not benchmark how much faster a full tuning cycle becomes."],"forward_implications":["Researchers can perform ablation studies by simply disabling a step in the GUI, without editing or rerunning code, making systematic evaluation of pipeline components easier.","Individual functions built for one experiment can be reused in another by copying the structured component files, reducing duplicated implementation effort across studies.","Entire experiment pipelines can be shared as structured directories, improving reproducibility and making it easier for others to inspect and modify the exact sequence of operations.","The framework's support for multiple data sources (stored files, live sensors, and the CARLA simulator) means the same pipeline logic can be transferred across data modalities with minimal changes.","Because custom functions follow a standard template and integrate into the GUI, the framework can grow a library of reusable components contributed by the research community."],"supporting_citations":[{"why":"Open3D is the underlying point cloud processing and visualization library on which many LiGuard operations and GUI components are built.","marker":"[35]"},{"why":"OpenCV provides the image processing and visualization backend for LiGuard's image data handling.","marker":"[2]"},{"why":"The KITTI dataset is used in Case Study 1 to demonstrate rapid setup of a pre-trained deep object detector inference pipeline.","marker":"[8]"},{"why":"PointPillars is the pre-trained object detection model used in Case Study 1, showing how a custom research algorithm can be integrated as a pipeline step.","marker":"[13]"},{"why":"CARLA is used as a live simulation data source in Case Study 2, demonstrating the framework's ability to switch data sources without changing pipeline logic.","marker":"[7]"},{"why":"OpenPCDet defines the label file format that Case Study 2's post-processing step writes, showing integration with existing deep learning toolboxes.","marker":"[25]"},{"why":"TEPPDBSCAN is the parallel DBSCAN clustering algorithm provided as a built-in function in LiGuard's point cloud processing toolbox.","marker":"[29]"},{"why":"The IPS300+ dataset appears in the interface figure, illustrating the visualizer's ability to display real-world roadside lidar frames.","marker":"[28]"}],"fun_headline_variants":["Lidar pipelines you can reorder live with LiGuard","Data-dictionary design lets lidar steps be swapped on the fly","LiGuard: modular lidar processing with a shared data dictionary","Interactive lidar research: reorder steps, reuse modules, share easily","One dictionary to pipeline them all: LiGuard for lidar"],"cache_read_input_tokens":2688,"weakest_assumption_plain":"The load-bearing premise is that every functional step in a pipeline is truly independent and relies only on the shared data dictionary, so enabling, disabling, reordering, or replacing steps will not break the pipeline in hidden ways.","fun_headline_variants_meta":{"raw":{"variants":["Lidar pipelines you can reorder live with LiGuard","Data-dictionary design lets lidar steps be swapped on the fly","LiGuard: modular lidar processing with a shared data dictionary","Interactive lidar research: reorder steps, reuse modules, share easily","One dictionary to pipeline them all: LiGuard for lidar"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000479,"raw_usage":{"total_tokens":2200,"prompt_tokens":725,"completion_tokens":1475,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":469,"completion_tokens_details":{"reasoning_tokens":1386}},"tokens_in":469,"tokens_out":1475,"duration_ms":9911,"temperature":1.0,"reasoning_tokens":1386,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T11:15:59.351036+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run Pipeline 2 through the GUI and disable the background-filtering step while leaving downstream clustering and bounding-box regression enabled; if the pipeline silently produces garbage clusters or crashes without a clear error, the claimed modular independence is violated. Alternatively, reorder the background-filter and clustering steps via the GUI and observe whether the pipeline still executes or whether it raises an unexplained data-availability error.","supporting_citations":[{"cited_title":"The OpenCV Library,","cited_arxiv_id":null,"evidence_quote":"OpenCV provides the image processing and visualization backend for LiGuard's image data handling."},{"cited_title":"Pointpillars: Fast encoders for object detection from point clouds,","cited_arxiv_id":null,"evidence_quote":"PointPillars is the pre-trained object detection model used in Case Study 1, showing how a custom research algorithm can be integrated as a pipeline step."},{"cited_title":"Openpcdet: An open-source toolbox for 3d object detection from point clouds,","cited_arxiv_id":null,"evidence_quote":"OpenPCDet defines the label file format that Case Study 2's post-processing step writes, showing integration with existing deep learning toolboxes."},{"cited_title":"Ips300+: a challenging multi-modal data sets for intersection perception system,","cited_arxiv_id":null,"evidence_quote":"The IPS300+ dataset appears in the interface figure, illustrating the visualizer's ability to display real-world roadside lidar frames."}],"review_version":1}