{"id":"50bb036f-f588-451b-865b-e1c8b650fa18","arxiv_id":"2502.02223","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"SurvHive provides a unified scikit-learn-compatible interface to eight survival models from five packages, plus time-dependent metrics and censoring-aware cross-validation.","lead":"SurvHive is a new Python package that wraps eight survival analysis models from five existing libraries behind one scikit-learn-style interface. It aims to make it easier for machine learning practitioners to train, compare, and tune survival models without learning each package's unique API.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The central claim is unverified because no test checks that SurvHive wrappers reproduce the underlying packages' outputs; the custom FastCPH survival-function extension is an untested reimplementation.","rationale":"The reader's weakest assumption is exactly the load-bearing point: SurvHive's contribution is a unified interface for fair comparison, and that contribution collapses if the wrappers silently alter the behavior of the underlying methods. The paper provides no evidence that the adapters are faithful, and the added FastCPH survival-function code is a particularly concrete place where a bug could skew results. Because the paper is a software-description preprint with no experimental validation, the correct disposition is a conditional acceptance pending a minimal correctness check. I therefore agree with the reader's verdict and would not change it. The concrete test described above would settle the concern; until such a test is run, the central claim remains plausible but unverified.","tokens_in":7773,"tokens_out":2131,"duration_ms":22934,"concrete_test":"Install SurvHive and the four underlying packages. On a public dataset (e.g., the 'veterans' or FLchain data used by scikit-survival), fit each of the eight models twice: once through SurvHive and once by direct calls to the original package with identical hyperparameters and splits. Compare risk scores, survival functions at the quantile times used by the metrics, and C-index/Brier/AUROC values. Require exact or near-exact agreement (e.g., max relative difference < 1e-6 or C-index difference < 0.001) for all models except FastCPH, and additionally verify the new survival-function extension against numerical integration of the Cox PH baseline hazard from LassoNet. This test would directly settle whether SurvHive's comparisons are unbiased.","verdict_should_be":"UNCHANGED","load_bearing_attack":"SurvHive's stated purpose is unbiased comparison via faithful adapters (Section 2: 'reduced bias in the comparative evaluation'). This requires that each wrapper's fit/predict/predict_survival outputs match those of the original package on identical inputs. The paper contains no such equivalence test, no benchmark, and no unit tests. Moreover, Section 2.1 states FastCPH 'has been extended to support the calculation of the Survival function too,' so at least one model is not purely delegated to the original LassoNet implementation; this extension is precisely the kind of reimplementation the authors say they avoid, and its correctness is untested. If any adapter mis-converts the structured survival outcome (sksurv structured array vs PyCox/auton-survival formats), or mishandles censoring indicators during train/test splitting, then the unified scores and C-indices reported by SurvHive could differ from what the original packages would produce, and comparative rankings would be artifacts of SurvHive rather than of the methods. The garbled appendix code further illustrates that the documented workflow has not been exercised end-to-end.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper introduces SurvHive, a Python package that wraps eight survival-analysis models from scikit-survival, PyCox, auton-survival, LassoNet, and SurvTRACE behind a scikit-learn-style adapter interface. The package adds common facilities: fit/predict/score/predict_survival methods, time-dependent metrics (Antolini C-index, Brier score, time-dependent AUROC), censoring-stratified cross-validation, hyperparameter optimization helpers, and dataset utilities. The manuscript describes the package architecture, the included models, metrics, dataset preparation conventions, installation, and usage examples in an appendix. The central claim is that SurvHive lowers the barrier to using and comparing survival-analysis models while reducing bias in comparative evaluation by avoiding re-implementation. The paper contains no benchmark, no test suite, and no quantitative demonstration that the adapters faithfully reproduce the wrapped packages' behavior; the appendix code examples contain multiple syntax errors and corrupted identifiers.","tokens_in":7918,"tokens_out":3024,"duration_ms":33310,"significance":"If the package worked as described, it would be a plausible convenience layer for practitioners who want to compare classical and deep-learning survival models through one API. The adapter pattern is an appropriate design, and the inclusion of time-dependent metrics is a useful feature. The manuscript is also honest about the package's limited scope (single, non-competing events and minimal data preparation). However, the paper's core value proposition is faithful, unbiased comparison, and that proposition is not tested anywhere: no unit tests, no equivalence checks against the underlying packages, and no empirical demonstration on any dataset. The appendix examples appear not to have been executed end-to-end. Consequently, the contribution is currently a software description with unverified behavior rather than a validated software contribution. The issues are substantial but fixable in a revision: adding smoke tests, adapter-equivalence checks, and a small worked benchmark would directly address the main gap.","major_comments":[{"comment":"The central claim that the adapter design 'avoids re-implementation' and 'allows for a reduced bias in the comparative evaluation' is not substantiated by any test. The paper provides no unit tests, no equivalence tests, and no benchmark showing that SurvHive's fit, predict, predict_survival, and score produce the same outputs as the original packages on identical inputs. For example, the conversion between the structured array format of scikit-survival and the formats expected by PyCox/auton-survival/LassoNet is a nontrivial step; an error in censoring indicators or event-time mapping would change scores and rankings. The authors should add a systematic equivalence test (or at least a small set of smoke tests) covering each wrapper and each data format conversion, and report the results.","section":"Section 2 (Application description)"},{"comment":"The statement that 'FastCPH has been extended to support the calculation of the Survival function too' contradicts the paper's stated avoidance of re-implementation: this extension is exactly an added piece of code whose correctness is not verified. Since FastCPH is a proportional-hazards model, computing a survival function requires estimating or importing the baseline hazard, and a bug there would affect every metric that uses predict_survival. The manuscript should describe how the survival function is computed and include a validation test comparing FastCPH's risk ordering and survival-function outputs against a closed-form or reference implementation.","section":"Section 2.1 (Models provided)"},{"comment":"The printed code examples contain multiple syntax errors and corrupted identifiers, which undermines the claim that the documented workflow has been exercised. For instance, 'f o r in vanilla mods . keys ( )' is not valid Python; 'imputer . transform ( )' is missing the data argument; 'y tr ain' appears where 'y tr' was defined; and several function names are split by spaces. These are not stylistic quirks but invalid code. The appendix should be replaced with an executed notebook output or a clearly tested script; otherwise the reader cannot reproduce the advertised workflow from the paper.","section":"Appendix A.2-A.4 (SurvHive usage examples)"},{"comment":"The paper contains no quantitative evaluation of any kind. It does not demonstrate SurvHive on one of the included benchmark datasets, report runtime, show C-index/Brier/AUROC values, or compare SurvHive's results with the outputs of the underlying packages. For a software paper whose purpose is to enable reliable comparison, such a demonstration is load-bearing, not cosmetic. The authors should add a small experimental section (e.g., on one or two public datasets) showing that the package installs, runs, and produces sensible scores for all eight methods, and ideally a consistency check against the original packages.","section":"Section 3 (Conclusion) / overall"}],"minor_comments":[{"comment":"The text states that lack of observed events is 'called left-censoring'; the described situation (event not observed by the end of follow-up) is right-censoring. This terminology error appears in the first paragraph and should be corrected.","section":"Section 1 (Introduction)"},{"comment":"The paper refers to 'Harrel's Concordance-index' and 'Harrel's C-index'; the standard spelling is 'Harrell's'. Also, the default metric is stated to be Antolini's Concordance Index, but the reader is not told how the Antolini index is computed for models that only output a risk score (as opposed to a survival function); a brief explanation would help.","section":"Section 2.2 (Metrics)"},{"comment":"The reader is asked to upload a CSV with columns 'event' and 'event time', but the code then uses 'get_x_y(dataset, attr_labels=[...], pos_label=True)'. It would be clearer to show a concrete CSV header or a small example DataFrame, since the package's expected input format is central to usability.","section":"Appendix A.2"},{"comment":"The final URL in the appendix is truncated as 'https://github.com/compbiomed-unito/survhi'; the full documentation URL should be given. Also, the author name 'Piero F ariselli' contains an internal space and the copyright line says '©2022' while the paper is dated 2025.","section":"References / Appendix"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is a software-description paper with no validation. The most important issue is not the absence of a benchmark for comparing models, but the absence of any evidence that the adapters are faithful to the original packages; this is the load-bearing claim of the paper. The appendix code corruption is a red flag that the documented workflow has not been run end-to-end. I would not accept the paper in its current form, but the gap is fixable: a revision with wrapper-equivalence tests, corrected executable examples, and a small reproducible demonstration would make the contribution credible. If the authors cannot provide such tests, the paper should be rejected."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this is a modest but legitimate software contribution, and the paper as written doesn't yet demonstrate it works. The package wraps eight survival models behind a scikit-learn-style API, adds survival-specific scorers (Antolini C-index, time-dependent Brier/AUROC), and extends FastCPH to output survival functions. That integration is new, even if no new model or algorithm appears. The motivation is real: comparing survival models usually means fighting incompatible interfaces, and a unified adapter layer could save people real time.\n\nWhat the paper does well: the design choices are sensible—subclassing BaseEstimator, using sksurv's structured array format, stratifying CV splits by censoring. The metric scorers take the fitted estimator as an argument, which is a nice touch for time-dependent metrics. The citation list covers the original methods fairly, and the authors are upfront about only supporting single-event data.\n\nThe soft spots are real. The central promise is that wrapping avoids re-implementation and therefore reduces bias in comparisons. That promise is never tested. There is no equivalence test showing SurvHive's CoxNet gives the same predictions as scikit-survival's coxnet, or that DeepHitSingle matches PyCox. Without that, the claim of unbiased comparison is just an assertion. Worse, the FastCPH extension is exactly the kind of reimplementation they say they avoid, and it gets no validation either. The stress-test note is correct on both points. The appendix code is garbled—variable names split by spaces, half-written list comprehensions—so the printed example cannot be run, which undercuts the reproducibility story. I'd treat that as a manuscript defect, not necessarily a package defect; the GitHub repo may be fine. But the paper should either paste the real notebook output or omit the appendix.\n\nThe conclusion also oversells ('significant advancement'). It's a convenience layer, not a scientific advance. That's fine if stated plainly.\n\nWho is this for? Someone doing survival-model benchmarking who wants one API to call Cox, RSF, DeepHit, DSM, FastCPH, and SurvTRACE. That reader would find the package useful, and the paper gives a decent overview. But I wouldn't trust it until the wrapper equivalence is checked. The package should have unit tests against the underlying libraries, and the paper should report a smoke test on a real dataset.\n\nMy recommendation: send it to peer review as a software/tool paper, but with required revisions—add a minimal verification benchmark, fix the appendix, and soften the conclusions. It deserves referee time because the tool is potentially useful and the engineering is sound in principle.","headline":"A useful wrapper package whose core promise—faithful, unbiased access to underlying survival models—is asserted but never demonstrated; worth reviewing after validation is added.","tokens_in":8452,"tokens_out":2090,"would_cite":false,"duration_ms":21626,"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":"SurvHive presents a Python package that unifies eight survival-analysis implementations behind a single scikit-learn-compatible interface, enabling consistent training, tuning, and comparison of classical and deep-learning survival models.","keywords":["survival analysis","time-to-event prediction","machine learning","deep learning","censored data","scikit-learn API","model comparison","Python package"],"falsifier":"Run one wrapped model, such as DeepHitSingle or FastCPH, and the same model's standalone implementation on an identical dataset with identical hyper-parameters, then compare predicted risk scores and survival functions for numerical agreement.","tokens_in":7562,"feed_emoji":"🐝","tokens_out":6632,"duration_ms":56754,"temperature":0.7,"pith_summary":"SurvHive is a Python package that wraps eight existing survival-analysis implementations behind a single, consistent API modeled on scikit-learn. The paper's central claim is that this unification lets practitioners train, evaluate, and compare classical statistical models and modern deep-learning survival models without learning each library's data formats, interfaces, and preprocessing quirks. If the claim holds, the package lowers the barrier to entry for applying state-of-the-art survival methods and makes head-to-head comparisons more reliable, because every model is invoked and scored through the same code path. The package also adds time-dependent evaluation metrics and censoring-aware cross-validation defaults that are missing from most of the wrapped libraries.","feed_headline":"One Python API now wraps eight survival-analysis models","feed_subtitle":"Cox to transformer-based deep learners become comparable with the same fit, tune, and score code.","key_machinery":"The central mechanism is the SurvivalEstimator dataclass, which subclasses scikit-learn's BaseEstimator and follows the Adapter pattern to wrap each underlying model. This dataclass standardizes fit, predict, and score calls, exposes survival-function prediction, and carries a default hyper-parameter grid plus random-seed handling. Around it, the optimization submodule provides censoring-stratified, repeated cross-validation for grid or random search, and the metrics submodule implements Antolini's time-dependent concordance index, Brier scores, and time-quantile AUROC as scikit-learn scorers.","core_discovery":"The central discovery is a working software bridge. By subclassing scikit-learn's BaseEstimator and applying the Adapter pattern, SurvHive exposes eight models—Cox proportional hazards, elastic-net Cox, gradient-boosted survival analysis, random survival forest, DeepHit, Deep Survival Machines, FastCPH, and a transformer-based survival model—through a uniform fit/predict/score interface. The authors argue that wrapping rather than re-implementing existing methods reduces the risk of unintended changes to complex algorithms, and therefore reduces bias when the models are compared on equal footing. The interface adds a predict_survival method for survival-function output, default hyper-parameter grids for optimization, and a seeded random-number parameter for reproducibility.","pith_inferences":["A direct testable consequence the paper leaves implicit: parity checks between SurvHive adapters and their standalone upstream packages would confirm whether the 'reduced bias' claim is actually met in practice.","The Adapter-based architecture makes SurvHive a natural hub for community benchmarks; adding a new model is a matter of writing one wrapper, so the package could grow into a living comparison of survival methods.","Because all metrics and splits are centralized, SurvHive could serve as a neutral referee in method evaluation, reducing the variance that comes from each author's preferred preprocessing and scoring choices."],"forward_implications":["A user can fit, tune, and score eight survival models on one dataset with identical code, making multi-model benchmark comparisons a few lines of work.","The default scoring metric, Antolini's concordance index, is appropriate for deep-learning models whose risk ranking changes over time, which the classic C-index mishandles.","The censoring-stratified repeated cross-validation default gives fairer hyper-parameter selection on censored data than ordinary K-fold splits.","Because each method is wrapped rather than reimplemented, upstream improvements to the underlying packages automatically propagate into SurvHive.","The scikit-learn-compatible scorers let users plug survival metrics into existing machine-learning pipelines and even adapt standard classification metrics like Matthews correlation coefficient."],"supporting_citations":[{"why":"Provides the scikit-learn estimator API that SurvHive models its interface on.","marker":"Pedregosa et al. (2011)"},{"why":"Additional scikit-learn API design conventions used by the framework.","marker":"Buitinck et al. (2013)"},{"why":"Source of four classical models (CoxPH, CoxNet, GRBoostSA, RSF) from scikit-survival.","marker":"Pölsterl (2020)"},{"why":"Source of DeepHitSingle from PyCox.","marker":"Kvamme et al. (2019)"},{"why":"Source of Deep Survival Machines from auton-survival.","marker":"Nagpal et al. (2022)"},{"why":"Source of FastCPH via LassoNet.","marker":"Lemhadri et al. (2021)"},{"why":"Source of SurvTraceSingle from SurvTRACE.","marker":"Wang and Sun (2022)"},{"why":"Defines the time-dependent concordance index used as the default score.","marker":"Antolini et al. (2005)"}],"fun_headline_variants":["Eight survival models, one simple Python API","SurvHive: unify survival analysis in Python","One package to rule survival analysis models","Python API wraps 8 survival models seamlessly","SurvHive: consistent interface for survival models"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that SurvHive's adapter wrappers faithfully reproduce the behavior of the original packages, since the paper does not test output parity; if an adapter introduces a subtle bug or version mismatch, the comparative evaluations the package enables would be skewed.","fun_headline_variants_meta":{"raw":{"variants":["Eight survival models, one simple Python API","SurvHive: unify survival analysis in Python","One package to rule survival analysis models","Python API wraps 8 survival models seamlessly","SurvHive: consistent interface for survival models"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000206,"raw_usage":{"total_tokens":1372,"prompt_tokens":895,"completion_tokens":477,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":511,"completion_tokens_details":{"reasoning_tokens":407}},"tokens_in":511,"tokens_out":477,"duration_ms":4225,"temperature":1.0,"reasoning_tokens":407,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-09T12:54:27.205664+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run one wrapped model, such as DeepHitSingle or FastCPH, and the same model's standalone implementation on an identical dataset with identical hyper-parameters, then compare predicted risk scores and survival functions for numerical agreement.","supporting_citations":[],"review_version":1}