{"id":"81c9c98e-5d6b-432a-8184-e84a6c7ead8f","arxiv_id":"2501.03817","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A detector-agnostic deep learning library for neutrino telescopes is updated to support multiple model architectures and experiment-specific data conversion.","lead":"GraphNeT 2.0 is an open-source software library that lets different neutrino telescope experiments share and adapt deep learning models for analyzing particle events. It is a tooling advance that could make reconstruction methods easier to transfer across detectors, even though the paper itself contains no new physics measurements.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"GraphNeT 2.0's core claim—that detector-specific details are fully isolated in the Detector component—is never demonstrated: the manuscript contains no tagged code release, no cross-detector transfer test, and no executable check that a model transfers by swapping only that component.","rationale":"The reader's weakest_assumption and my concern are the same: the detector-agnostic abstraction is an unverified design assumption. I agree. I do not think the claim is internally inconsistent; the paper is a plausible software description. However, for a software library paper, the central claim is about what the code does, and the manuscript does not include the code artifact needed to check it. The applications in §3 demonstrate community use, and the Kaggle baseline and DynEdge results provide independent support for the underlying methods, but none of those establish the 2.0 component abstraction. The right verdict is unchanged: conditional acceptance contingent on a released, tagged, verifiable code artifact and a cross-detector integration test.","tokens_in":6736,"tokens_out":4232,"duration_ms":40292,"concrete_test":"Check out a tagged GraphNeT 2.0 release and run a cross-detector integration test: build a Standard model whose Detector is IceCube and whose Data Representation, Architecture, and Task are the published DynEdge components; then, keeping those three components untouched, replace only the Detector with a LiquidO or Prometheus-generated water/ice detector and execute one training step and one forward pass. If the run fails or requires edits outside the Detector component, Section 2.2's isolation claim is violated. Also report the commit hash and CI test suite results.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 2.2 makes the load-bearing design assertion: \"The Detector component is the only part of a Model with experiment-specific details, allowing the remaining components to be detector-agnostic.\" The central claim of the paper—inter-experimental reusability and detector-agnostic deep learning—depends on this assertion being true in the actual code. The manuscript gives no evidence. It offers no repository URL, commit hash, or tagged release for GraphNeT 2.0 (reference [11] is to GraphNeT 1.0.0), no unit or integration tests, and no experiment in which the same Architecture, Data Representation, and Task are run for two detectors with only the Detector component changed. The concern is not that the abstraction is conceptually impossible; the concern is that real detector differences routinely leak into other components. Standardization is formally placed in Detector, but calibration constants, noise cleaning thresholds, timing windows, feature masks, and task-label definitions are not enumerated. IceCube Upgrade's noise cleaning, for example, relies on detector-specific noise characteristics (§3.1). If any such detail appears in Data Representation or Task, the statement that only Detector carries experiment-specific information is false, and the reusability claim weakens to \"users can rewrite components,\" which is not detector-agnosticism. Because this is a software paper, the claim is verifiable in principle; the absence of the artifact is a failure of evidence, not necessarily of the software.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"This manuscript describes GraphNeT 2.0, an open-source deep learning library for neutrino telescopes, as an update to previously released GraphNeT. The paper's two main claimed additions are (i) a modular data conversion system based on a reader/writer scheme and (ii) support for multiple deep learning paradigms beyond the original graph neural networks, organized around a four-component model abstraction: Detector, Data Representation, Architecture, and Task. The central design claim is that the Detector component encapsulates all experiment-specific details, so that Architecture, Data Representation, and Task components are detector-agnostic and reusable across experiments. The paper also reports applications of GraphNeT in several experiments, including IceCube, KM3NeT, SNO+, MAGIC/CTAO, ESSnuSB, and LiquidO, and announces an upcoming public release of simulated neutrino events.","tokens_in":6931,"tokens_out":3741,"duration_ms":34343,"significance":"If the design claims are realized in the code, GraphNeT 2.0 would be a valuable community resource: it would lower the barrier for cross-experiment reuse of deep learning reconstruction methods and would allow practitioners outside neutrino physics to contribute. The cited applications, especially the IceCube Upgrade noise-cleaning study and the Kaggle competition baseline, provide plausible evidence of community uptake and physics utility. The reader/writer data conversion, if working as described, would also address a real interoperability problem. However, the manuscript contains no executable artifact, no tests, and no cross-detector transfer demonstration, so the central detector-agnosticism claim is unverified as presented. The direction is promising and the writing is clear, but the evidence supplied in the manuscript is currently insufficient to support the strongest claims.","major_comments":[{"comment":"The statement in Section 2.2 that 'The Detector component is the only part of a Model with experiment-specific details, allowing the remaining components to be detector-agnostic' is load-bearing for the paper's central claims of detector-agnosticism and inter-experimental collaboration, but the manuscript provides no direct support. There is no link to a GraphNeT 2.0 release (reference [11] points to version 1.0.0), no commit hash, no unit or integration tests, and no experiment in which the same Architecture, Data Representation, and Task are run with two different Detector components. Please provide an artifact and a minimal cross-detector transfer example, or revise the claim to reflect a design goal rather than a verified property.","section":"Section 2.2"},{"comment":"The boundary between Detector and the other components is under-specified. The Detector component is said to contain standardization functions and geometry, but the manuscript does not enumerate which aspects of a real detector-specific method, such as the IceCube Upgrade noise cleaning described in Section 3.1, reside in Detector and which in Data Representation or Task. Detector-specific noise statistics, feature masks, preprocessing constants, or label definitions could leak into the other components and invalidate the claim of Section 2.2. Please specify the API contract for Detector and give code-level tests or examples showing that no experiment-specific constants appear outside Detector.","section":"Section 2.2 and Section 3.1"},{"comment":"The DataConverter claim that 'extending support for a new experiment only requires users to provide a new reader' is functionally important but is not demonstrated. No example, test, or benchmark is shown for the IceCube and LiquidO readers or for the Parquet and SQLite writers. At minimum, please include a round-trip test (e.g., writing an event via a writer and reading it back with the corresponding PyTorch Dataset) or provide a link to the test suite in the released repository.","section":"Section 2.1"}],"minor_comments":[{"comment":"There is a typo in Section 3.2: 'the bst reconstruction algorithm' should be 'the best reconstruction algorithm', and 'computed over a a large sample' should be 'computed over a large sample'.","section":"Section 3.2"},{"comment":"Reference [11] is cited as GraphNeT version 1.0.0; once a GraphNeT 2.0 release artifact exists (with a Zenodo DOI or commit hash), it should be cited here so that the claims in the paper are tied to a specific, findable version.","section":"References"},{"comment":"The introduction says deep learning offers 'indifference to detector geometry and detection medium'; this is an overstatement, since models trained on one detector do not automatically transfer to another. Rephrase to say that deep learning methods can be designed to be insensitive to these differences, which is exactly what the paper's Detector abstraction aims to achieve.","section":"Section 1"},{"comment":"The paragraph on writers mentions that both Parquet and SQLite formats have corresponding PyTorch Dataset classes, but it does not explain how a user chooses a writer or instantiates the Dataset. One concrete example would improve usability of the description.","section":"Section 2.1"},{"comment":"Section 3 lists six experiments in prose but only describes IceCube and the Kaggle competition in any detail. Consider presenting the other applications (SNO+, MAGIC/CTAO, ESSnuSB, LiquidO) in a table with citations, so the breadth of adoption is easier to verify.","section":"Section 3"},{"comment":"The conclusion states that more than 100 million simulated events 'are expected to be released at the beginning of 2025' while the paper is dated January 2025; please update this to the actual release status or give a specific date.","section":"Section 4"}],"recommendation":"major_revision","confidential_remarks":"The paper is a workshop-style software description with unusually strong claims about cross-experiment reusability. As a referee, I think the main issue is not the design concept itself, which is plausible and clearly motivated, but the lack of an artifact or verifiable demonstration. For a software paper, a link to a tagged release and at least one minimal working example (or a pointer to a test suite) is essential. I would be willing to accept a revised version that adds such evidence or tones down the claim to 'designed to confine experiment-specific details' while reporting the actual verified behavior."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short take: this is a workshop paper about a real, useful software library, but the manuscript undersells the evidence needed to back its main claim. The new stuff is support for transformer, normalizing-flow, and generic models plus a reader/writer data conversion layer. That is a concrete extension of GraphNeT 1.0, which was GNN-only, and the design is sensible. The component abstraction—Detector, Data Representation, Architecture, Task—is clearly described and is the right instinct for reusable model code. The paper also credibly lists several outside experiments where GraphNeT is being used, and the Kaggle competition baseline is a real community artifact. Credit where due: the writing is clean and the modularity story is coherent.\n\nThe soft spot is exactly what the stress-test note flags. Section 2.2 asserts that the Detector component is the only part of a model with experiment-specific details, and that this is what makes the library detector-agnostic. That claim is load-bearing, and the paper gives no evidence for it. There is no repository URL or commit hash for the 2.0 release, no unit or integration tests, no benchmark, and no demonstration that the same Architecture, Data Representation, and Task transfer between two detectors with only the Detector swapped. The reader's concern about leakage—calibration constants, noise cleaning thresholds, feature masks, task-label definitions—is reasonable. If any of that lives outside the Detector, the strong reusability claim weakens to \"users can rewrite components,\" which is not detector-agnosticism.\n\nThat said, this is a software paper, not a physics result, and the absence of artifacts is a failure of evidence rather than proof the software is broken. The library exists, has a user community, and the design is plausible. The paper is slightly premature: it uses language like \"this coming update,\" so it is describing a release that may not be publicly tagged yet. For a workshop paper, that is acceptable; for a journal or conference, a referee should insist on a tagged release and a minimal cross-detector transfer experiment.\n\nFor whom: people working in neutrino telescopes or related experiments who might adopt or extend GraphNeT. It is an engineering contribution, not a scientific principle, and the significance is subfield-specific. I would not cite it in my own work, but I might bring it to a reading group to discuss component-based ML library design. It deserves a serious referee, not desk rejection, because the software is clearly useful and the central claim is testable—it just needs the test.","headline":"GraphNeT 2.0 is a credible software-library paper whose central detector-agnostic claim needs code and a cross-detector test before it is verified.","tokens_in":7502,"tokens_out":1791,"would_cite":false,"duration_ms":18756,"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":"GraphNeT 2.0 is a detector-agnostic deep learning library that aims to make neutrino telescope models reusable across experiments by isolating experiment-specific details in one component.","keywords":["neutrino telescopes","deep learning library","detector-agnostic","graph neural networks","transformers","normalizing flows","event reconstruction","data conversion"],"falsifier":"Prepare two simulated event samples with different detector geometries and media, train a GraphNeT model on the first using one Detector component, then evaluate on the second after swapping in the second Detector component and no other changes. If the reconstruction quality is no better than an untrained baseline, or if reproducing the first detector's published results requires modifying components outside Detector, the central reusability claim is falsified.","tokens_in":6499,"feed_emoji":"🔭","tokens_out":8053,"duration_ms":74332,"temperature":0.7,"pith_summary":"GraphNeT 2.0 is an open-source Python library that aims to make deep learning models for neutrino telescopes portable across experiments with very different hardware. The paper's central claim is that this portability is achievable by isolating all experiment-specific details in a single Detector component, so that the data representation, neural architecture, and task modules stay detector-agnostic. The library also provides a reader/writer data-conversion layer that turns each experiment's native files into common deep-learning formats, with readers for two very different detectors and writers for two storage formats. If the claim is right, a reconstruction model developed for one telescope could be reused by another telescope with different geometry and detection medium by swapping only the detector-specific module, which matters because current maximum-likelihood reconstruction methods are experiment-specific and difficult to share.","feed_headline":"One component makes neutrino AI models portable between detectors","feed_subtitle":"GraphNeT 2.0 quarantines detector-specific details so a model trained for one telescope can be reused in another.","key_machinery":"The carrying mechanism is the model-component abstraction: a four-part decomposition in which Detector is the only experiment-specific piece. Detector holds column names, geometry, and normalization; Data Representation transforms raw hits into a chosen representation on an event-by-event basis; Architecture contains the learnable parameters; Task defines the prediction head and loss logic. A second design, Generic, imposes only the Detector interchangeability for methods such as auto-encoders or hybrid deep-learning-plus-likelihood approaches. The companion DataConverter uses a reader/writer scheme—a per-experiment reader parses native files into a standardized intermediate, and a per-format writer saves it—so new experiments and new storage formats each require only one new module. The abstraction is what transfers methods developed at one detector into reusable assets at another.","core_discovery":"The paper's core claim, stated on its own terms, is that the low-level observations of all neutrino telescopes are the same kind of object—a geometric time series of photomultiplier hits—so a deep learning solution can be made detector-agnostic if the experiment-specific parts are quarantined. GraphNeT 2.0 embodies this in a Standard model with four components: Detector, which holds column names, geometry, and standardization; Data Representation, which converts raw observations to images, sequences, or graphs in real time; Architecture, which contains the learnable network; and Task, which defines the prediction head, activation, and loss. A Generic model variant relaxes the design to require only the interchangeable Detector for methods that do not fit the four-part split. The paper supports the design with applications in at least six experiments, including published results where a graph neural network outperformed maximum-likelihood reconstruction at low energies and reduced detector noise by roughly a factor of ten, and the inclusion of top solutions from a public reconstruction competition.","pith_inferences":["If the Detector isolation holds, the same four-component pattern could be applied to other sparse-sensor particle detectors beyond neutrino telescopes, where the low-level data is again a point cloud of sensor hits; the paper does not claim this extension.","A direct test the reusability claim invites is a zero-retraining transfer experiment: train on simulated events from one detector, swap only the Detector, and evaluate on simulated events from a different detector.","The reader/writer scheme suggests that once public simulated datasets for several geometries are released, a model zoo could emerge where the same architecture weights are published once and re-parameterized by Detector modules for each experiment.","Because GraphNeT standardizes the task interfaces, physics analyses that currently each build custom likelihood approximations could in principle adopt a common reconstruction interface, making sensitivity projections across experiments more directly comparable."],"forward_implications":["A reconstruction or classification model trained on one detector's simulated events can be applied to another detector by supplying a new Detector component, without changing the network architecture or task.","Adding support for a new experiment reduces to writing one reader module, and adding a new output format reduces to writing one writer module.","Users can vary Data Representation, Architecture, or Task independently for the same problem, letting one base model serve multiple physics analyses.","The paper reports that GraphNeT-based graph networks have outperformed traditional maximum-likelihood methods for low-energy reconstruction in an ice-based detector and removed roughly ten times more noise with minor signal loss, establishing a performance baseline for the reusable components.","The planned public release of more than 100 million simulated neutrino events across six detector geometries will let the community benchmark deep-learning reconstruction methods on identical data."],"supporting_citations":[{"why":"The original open-source library release whose GNN-only scope this update extends.","marker":"[11]"},{"why":"Provides the core deep learning backend and automatic differentiation the package builds on.","marker":"[12]"},{"why":"Supplies graph neural network layers used by the architecture components.","marker":"[13]"},{"why":"The GraphNeT 1.0 methods paper that defined the GNN reconstruction approach now generalized.","marker":"[17]"},{"why":"The ice-based detector whose file format motivates one built-in reader.","marker":"[1]"},{"why":"The opaque-detector experiment whose file format motivates the second built-in reader.","marker":"[18]"},{"why":"One of the two storage formats supported by the writer modules.","marker":"[19]"},{"why":"Defines the dataset abstractions used to load the converted formats.","marker":"[20]"},{"why":"The flagship application showing graph-network noise cleaning and reconstruction performance at low energies.","marker":"[28]"},{"why":"The simulation used to produce the planned multi-detector public benchmark dataset.","marker":"[34]"}],"fun_headline_variants":["Neutrino AI library lets models swap between detectors","GraphNeT 2.0: one toolbox for all neutrino telescopes","Detector-agnostic deep learning for neutrino astronomy","Open-source library transfers neutrino AI across experiments","Quarantine detector details, reuse neutrino models"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"Everything rests on the premise that all detector-specific knowledge—geometry, column names, calibration, noise statistics, and standardization—can be fully captured inside the single Detector component, so replacing it is sufficient to move a trained model to another detector.","fun_headline_variants_meta":{"raw":{"variants":["Neutrino AI library lets models swap between detectors","GraphNeT 2.0: one toolbox for all neutrino telescopes","Detector-agnostic deep learning for neutrino astronomy","Open-source library transfers neutrino AI across experiments","Quarantine detector details, reuse neutrino models"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00015,"raw_usage":{"total_tokens":1161,"prompt_tokens":874,"completion_tokens":287,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":490,"completion_tokens_details":{"reasoning_tokens":210}},"tokens_in":490,"tokens_out":287,"duration_ms":3048,"temperature":1.0,"reasoning_tokens":210,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T21:46:02.353183+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Prepare two simulated event samples with different detector geometries and media, train a GraphNeT model on the first using one Detector component, then evaluate on the second after swapping in the second Detector component and no other changes. If the reconstruction quality is no better than an untrained baseline, or if reproducing the first detector's published results requires modifying components outside Detector, the central reusability claim is falsified.","supporting_citations":[{"cited_title":"Søgaard, R","cited_arxiv_id":null,"evidence_quote":"The original open-source library release whose GNN-only scope this update extends."},{"cited_title":"Fey and J","cited_arxiv_id":null,"evidence_quote":"Supplies graph neural network layers used by the architecture components."},{"cited_title":"LiquidO: First Opaque Detector for ββ Decay?","cited_arxiv_id":null,"evidence_quote":"The opaque-detector experiment whose file format motivates the second built-in reader."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"One of the two storage formats supported by the writer modules."},{"cited_title":"Automatic differentiation in PyTorch","cited_arxiv_id":null,"evidence_quote":"Defines the dataset abstractions used to load the converted formats."},{"cited_title":"Prometheus: An open-source neutrino telescope simulation","cited_arxiv_id":null,"evidence_quote":"The simulation used to produce the planned multi-detector public benchmark dataset."}],"review_version":1}