{"id":"a57c9695-c5e8-42a7-bcf8-942b20ba90d0","arxiv_id":"2607.21117","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"GlucoTune is a configurable software framework that reproduces blood-glucose forecasting experiments from original datasets using portable YAML pipelines and a unified benchmarking leaderboard.","lead":"The authors describe GlucoTune, a software framework that standardizes how blood-glucose data is cleaned, split, and fed into forecasting models, using portable configuration files that let other labs reproduce experiments without sharing private patient data. It bundles several public diabetes datasets, many forecasting models, a benchmarking leaderboard, and a graphical interface, and it reports a usability study with 11 volunteers.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The central reproducibility claim is currently unverifiable: no code snapshot, YAML configuration, or version identifier appears in the manuscript, so 'reproducible experiments directly from the original datasets' cannot be checked.","rationale":"The reader's weakest assumption—original dataset access—is a relevant external condition, but it is not the most load-bearing issue. Even with all datasets available, the reproducibility claim cannot be assessed unless the code and configuration artifacts are public and deterministic. The reader's verdict was already CONDITIONAL, and the condition to release a versioned code snapshot directly addresses this concern. My analysis reinforces that condition rather than changing the verdict. I do not find an internal inconsistency in the framework design; the gap is evidentiary. The missing artifact is explicitly central because the paper's abstract and Section II repeatedly claim reproducible experiments via YAML configurations, yet no such configuration is shown or hash-pinned. A concrete reproducibility test would settle whether the claim lands; until then, CONDITIONAL is the appropriate verdict.","tokens_in":11850,"tokens_out":1889,"duration_ms":21960,"concrete_test":"Obtain the linked code repository and install the exact version referenced (or, if absent, the current version at submission time). Run the Section III-A protocol on OhioT1DM with PH=30 min, max normalization, temporal split, MSE loss, and the BiGRU configuration from Table I, using the same YAML config implied by the text. Then re-run on a second machine with the same package versions and seeds. If the RMSE/MAE/sensitivity values differ from Table I by more than rounding, or if the two runs differ beyond floating-point noise, the unified reproducibility claim is unsupported. If the repository is unavailable at review time, that itself confirms the claim is currently unverifiable.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central contribution is that portable YAML configurations let any researcher reproduce experiments from original datasets without redistributing sensitive data. For that to be true, the framework must be publicly available, versioned, and deterministic enough that the same YAML plus the same dataset files yields the same preprocessed data and model outputs. None of that is verifiable from the manuscript: there is no code, no commit hash, no YAML schema or example, no environment/package pinning, and no leaderboard content. Section III-A states 'All models are trained and evaluated under the same protocol' and Table I gives exact numbers, but no seeds, training iterations, or software versions are reported, so a reader cannot tell whether the numbers would reproduce even with the code in hand. The strongest claim is therefore a promise, not a demonstrated result. This is not an internal contradiction, but it is the load-bearing condition for the entire contribution: if the artifact is not available or is not deterministic, the central claim—reproducibility via shared configs—fails. The manuscript's own dependence on an external footnote URL (unimib-islab.github.io/glucotune) further emphasizes that the evaluation rests on resources not included in the paper.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"GlucoTune is presented as a modular Python framework that standardizes the complete experimental workflow for blood glucose time-series research: configurable preprocessing pipelines defined in portable YAML files, standardized wrappers for four public T1D datasets, a large model library, a benchmarking leaderboard with multi-metric evaluation, and a GUI. The paper claims that sharing YAML configurations enables other researchers to reproduce experiments directly from original datasets without redistributing sensitive preprocessed data. The experimental section reports a predictive benchmark on OhioT1DM and DiaTrend at 30- and 60-minute prediction horizons with and without SMOTE augmentation, comparing top models per family, plus a usability study of the GUI (n=11, mean SUS 80.91).","tokens_in":12107,"tokens_out":2993,"duration_ms":33207,"significance":"If the framework is actually released, versioned, and deterministic, GlucoTune would make a genuinely useful contribution: it addresses a real pain point in CGM-based research, where preprocessing heterogeneity and data-sharing restrictions block reproducibility. The design is sensible, the preprocessing modularity is broad, and the multi-metric evaluation plan (RMSE, MAE, MARD, TG, sensitivity/specificity, error grids, complexity measures) is more comprehensive than what is typically reported. The strongest contribution is the reproducibility-by-configuration idea, which would allow sharing experimental setups without sharing patient-level data. However, that contribution is currently a promise, not a demonstrated result: the manuscript contains no code snapshot, no YAML schema or example, no version identifier, and no determinism statement. The benchmark also lacks any measure of run-to-run variability. With those gaps filled, the paper could be accepted; as submitted, the central claim is unverifiable.","major_comments":[{"comment":"The central reproducibility claim is not verifiable from the manuscript. The paper repeatedly states that YAML configuration files enable experiments to be reproduced 'directly from the original datasets,' but no YAML configuration, schema, code snapshot, package version, commit hash, or dependency pinning is included. The only pointer is an external URL (unimib-islab.github.io/glucotune), which is not part of the manuscript. A reader cannot check whether the same YAML plus the same public dataset produces the same preprocessed data and model outputs. This is load-bearing because the paper's main contribution is precisely this reproducibility mechanism. Please provide a permanent artifact (e.g., Zenodo DOI), at least one example YAML configuration in the paper or appendix, and a clear statement about random seeds, package versions, and determinism of preprocessing and training.","section":"Section II, first paragraph; Section III-A; Abstract"},{"comment":"Table I reports single-point results to two decimal places for RMSE, MAE, MARD, TG, sensitivity, and specificity, but no error bars, standard deviations, or confidence intervals are given. For neural models with random initialization and data-dependent training, single-run differences of 0.1–0.3 mg/dL RMSE may be within noise. The family-level model selection (retaining only the top-performing neural model per family) also makes cross-family comparison harder to interpret. Please report variance over multiple seeds/splits, or at least justify why single-run results are sufficient for the benchmark's conclusions.","section":"Section III-A, Table I"}],"minor_comments":[{"comment":"The paragraph 'Model selection is performed at the family level ... retaining only the top-performing models' is duplicated verbatim. Please remove the duplicate.","section":"Section III-A, paragraph before Table I"},{"comment":"The table header is malformed: 'PH = 30 min PH = 30 min' repeats the horizon label, and the units line '(mg/dL) (mg/dL) (%) ...' is not properly aligned. Please reformat the header so each metric group is clearly associated with its PH column.","section":"Table I header"},{"comment":"The text repeatedly renders 'YAML' as 'Y AML' (e.g., 'portable Y AML configuration files'). This is likely a LaTeX/typing artifact and should be fixed throughout.","section":"Section II.A and Introduction"},{"comment":"The usability study reports a mean SUS of 80.91 from 11 participants, but no participant demographics, programming background, prior experience with diabetes tools, or task completion times are given. Given the small sample, please temper the claim that GlucoTune is 'highly usable' and report the study's limitations.","section":"Section III.B"},{"comment":"The paper states the framework supports four public datasets, but the benchmark uses only OhioT1DM and DiaTrend. Please clarify why T1DiabetesGranada and T1DEXI are not included in the experimental demonstration, or state explicitly that they are supported but not benchmarked in this paper.","section":"Section II.A.1"}],"recommendation":"major_revision","confidential_remarks":"The paper describes a potentially valuable software contribution, but the manuscript as submitted does not include the artifact that would make the central reproducibility claim testable. I strongly recommend requiring the authors to provide a stable code/artifact link, an example YAML configuration, dependency/version information, and a determinism statement before acceptance. The benchmark's lack of multiple runs is a secondary but important issue. If the artifact checks out and the authors add variance estimates, I would be willing to accept."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"GlucoTune is a credible software contribution: a YAML-driven pipeline that standardizes preprocessing, training, and evaluation across four public datasets and a wide model zoo. That integration is genuinely useful; if the code is clean and the configs actually work, it could become a standard harness for CGM forecasting. The paper also includes a reasonable usability study and a broad benchmark. Credit where due.\n\nThe soft spot is exactly where the stress-test lands. The central claim—that sharing configs reproduces experiments from original data—cannot be checked from the manuscript. No code, no YAML example, no commit hash, no leaderboard content. The footnote URL is a pointer, but reviewers need the artifact. That is a load-bearing issue for a framework paper, not a minor omission. I’d make the release of a versioned code snapshot and a config example a condition of acceptance.\n\nThe benchmark itself has weaknesses: no error bars, no seed information, and the per-family selection of \"top-performing\" models means the leaderboard is not a fair comparison across families, despite the paper saying all models are evaluated under the same protocol. The duplicated paragraph and the malformed table header suggest a rushed compile; trivial to fix but worth flagging.\n\nI disagree with any characterization that this is a prediction paper. It’s an engineering artifact paper, and the circularity concern is mostly off-target. The question is simply whether the artifact exists and works. The authors seem honest; they don't overclaim clinical relevance.\n\nWho should read this? People building baselines for glucose forecasting and anyone working on reproducible ML pipelines for sensitive medical time-series. A serious referee should push for code, seeds, and configs.","headline":"A genuinely useful engineering contribution whose central reproducibility claim rests on code not included in the manuscript; peer-review it, but demand the artifact.","tokens_in":12588,"tokens_out":2496,"would_cite":false,"duration_ms":24589,"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":"GlucoTune claims that portable YAML preprocessing configurations can make blood-glucose forecasting experiments reproducible from raw datasets without redistributing sensitive data.","keywords":["blood glucose prediction","reproducibility","preprocessing pipeline","YAML configuration","benchmarking","time series forecasting","type 1 diabetes","continuous glucose monitoring"],"falsifier":"Take a published GlucoTune YAML configuration and the corresponding original dataset, run it in a fresh environment with pinned dependency versions, and compare the generated train, validation, and test indices, normalized tensors, and leaderboard metrics to the published values; any mismatch beyond floating-point tolerance would falsify the reproducibility claim.","tokens_in":11747,"feed_emoji":"📈","tokens_out":3646,"duration_ms":34181,"temperature":0.7,"pith_summary":"GlucoTune claims that the reproducibility crisis in blood-glucose forecasting can be solved by standardizing the entire experimental workflow—preprocessing, model training, and evaluation—so that experiments can be rerun from the original datasets using portable YAML configuration files. The point is to let researchers share a preprocessing recipe rather than the preprocessed data itself, which privacy rules often forbid. The framework wraps four public type 1 diabetes datasets, offers a library of baseline models spanning statistical, machine-learning, and deep-learning families, and publishes a leaderboard with clinical and computational metrics. If the claim holds, comparing two forecasting models becomes meaningful because differences can be attributed to the models, not to divergent preprocessing choices.","feed_headline":"Config files, not patient data, now reproduce glucose forecasts","feed_subtitle":"A unified framework standardizes preprocessing, training, and evaluation so labs can compare fairly and rerun experiments without sharing se","key_machinery":"The load-bearing object is the portable YAML preprocessing configuration, which fully specifies a pipeline of modular operations: dataset wrapper, missing-data handling, feature synchronization and cleanup, event-to-continuity transform, time-series cropping, prediction-horizon segmentation, splitting strategy, smoothing, SMOTE augmentation, and normalization, plus the evaluation protocol. It works together with standardized dataset wrappers that unify naming and formats across heterogeneous sources, and a model library whose training and evaluation loop consumes the same pipeline output. The YAML file is the reproducibility unit: it replaces redistribution of sensitive preprocessed data wit","core_discovery":"The paper's central claim is that a single configurable pipeline can standardize every decision that currently varies across studies—missing-data imputation, feature alignment, event handling, prediction-horizon segmentation, splitting, smoothing, augmentation, and normalization—and encode that pipeline in a portable YAML file. Because the YAML file, not the data, is shared, a lab with access to the original dataset can recreate the exact train, validation, and test splits and inputs used in a published experiment. The paper also builds a model library and a benchmark leaderboard that reports RMSE, MAE, MARD, time gain, hypo/hyperglycemia sensitivity and specificity, and model complexity, ar","pith_inferences":["[Editorial inference] Beyond the paper's direct claims, the YAML-as-reproducibility-unit pattern could be adapted to other privacy-sensitive biomedical time-series domains, such as ECG or ICU monitoring, where sharing raw data is restricted but sharing preprocessing recipes is not.","[Editorial inference] The leaderboard could evolve into a living community benchmark if configurations are versioned and dataset access is managed centrally, but that would require governance the paper does not address.","[Editorial inference] The reported finding that performance is strongly influenced by experimental setting suggests meta-analyses of glucose-forecasting papers should weight studies by preprocessing similarity, not just reported accuracy.","[Editorial inference] A testable extension: systematically ablate each preprocessing stage (with and without SMOTE, different gap thresholds, different smoothing settings) across datasets to quantify how much each choice moves RMSE and event sensitivity; the framework makes this direct."],"forward_implications":["Researchers can include a YAML configuration as supplementary material, letting others reproduce preprocessing exactly without transferring patient data.","The leaderboard allows direct comparison of models across datasets and prediction horizons under identical preprocessing, making reported differences more trustworthy.","The comprehensive metric set—RMSE, MAE, MARD, time gain, event sensitivity and specificity, and complexity—gives reviewers and clinicians a fuller picture than single-error metrics.","The modular wrappers make adding a new dataset or model a matter of implementing a small interface, so the benchmark can grow with the field.","The benchmarking results suggest preprocessing choices and dataset characteristics can dominate model architecture in determining performance, reinforcing the need for standardized protocols."],"fun_headline_variants":["YAML configs, not patient data, make glucose forecasts reproducible","Reproducible glucose forecasting without sharing patient data","One YAML file standardizes blood glucose preprocessing","GlucoTune: Config-driven glucose forecasting for fair benchmarks","Stop sharing data: Share configs for glucose model comparisons"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The reproducibility mechanism assumes every researcher can obtain the original public datasets under the same terms and run the same YAML pipeline; if data access is restricted or dataset files change, sharing configurations no longer reproduces the experiment.","fun_headline_variants_meta":{"raw":{"variants":["YAML configs, not patient data, make glucose forecasts reproducible","Reproducible glucose forecasting without sharing patient data","One YAML file standardizes blood glucose preprocessing","GlucoTune: Config-driven glucose forecasting for fair benchmarks","Stop sharing data: Share configs for glucose model comparisons"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000199,"raw_usage":{"total_tokens":1230,"prompt_tokens":789,"completion_tokens":441,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":533,"completion_tokens_details":{"reasoning_tokens":374}},"tokens_in":533,"tokens_out":441,"duration_ms":4695,"temperature":1.0,"reasoning_tokens":374,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-01T08:25:00.526871+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take a published GlucoTune YAML configuration and the corresponding original dataset, run it in a fresh environment with pinned dependency versions, and compare the generated train, validation, and test indices, normalized tensors, and leaderboard metrics to the published values; any mismatch beyond floating-point tolerance would falsify the reproducibility claim.","supporting_citations":[],"review_version":1}