{"id":"e8fa0f80-fcc2-4db8-826a-dc34b1f725a2","arxiv_id":"2603.27719","paper_version":2,"verdict":"ACCEPT","confidence":"HIGH","novelty_score":5.0,"correctness_risk":"low","formal_verification":"none","parameter_count":1,"one_line_summary":"DaiSy unifies state-of-the-art exact iSAX-based similarity search into one open-source library spanning disk, in-memory, GPU, and distributed environments.","lead":"DaiSy is an open-source C++/Python library that packages several leading exact similarity-search algorithms for data series and vectors into one framework covering disk, memory, GPU, and distributed settings. It lets practitioners use a single API instead of stitching together separate specialized codebases.","discovery_kind":"new_method","skeptic_critique":{"model":"grok-4.5","headline":"No significant objection identified","rationale":"The strongest claim is tooling availability and unification, not a new algorithmic breakthrough. The manuscript is explicit that performance and exactness rest on prior work (§1, §3.1, §4.3) and supplies only a modest new FAISS comparison plus open code. That is appropriate for a library paper; the absence of a full multi-backend re-evaluation inside this manuscript is a presentational limitation, not a correctness risk that would overturn ACCEPT. The reader's weakest_assumption correctly flags re-implementation fidelity, but because the artifact is public the concern is checkable rather than fatal. No stronger load-bearing flaw (e.g., false first-library claim, broken exactness argument, or contradictory design) is present. Verdict therefore stays ACCEPT with high confidence.","tokens_in":10630,"tokens_out":485,"duration_ms":7081,"concrete_test":"Clone https://github.com/MChatzakis/DaiSy, build the MESSI and ParIS+ backends, and re-run the Deep100M / Seismic100M workload of Fig. 3 (100 queries, k=10..1000, 48 hyperthreads) against FAISS-IndexFlat under identical g++ flags; confirm that reported speed-ups remain within ~20% of the paper and that returned neighbors match FAISS exact results (zero distance mismatches).","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim is a systems/integration claim: first unified library packaging four previously published exact iSAX engines (ParIS+, MESSI, SING, Odyssey) under one C++/Python API for disk/in-memory/GPU/distributed exact search, also usable for vectors. Exactness and SOTA status are inherited by reference to the original papers (§1, §3.1) rather than re-proved here; the only new empirical result is a limited MESSI-vs-FAISS-IndexFlat comparison (Fig. 3). For a library paper whose artifact is released, that inheritance is standard and does not undermine the claim that such a unified multi-environment library now exists. The reader's weakest_assumption (re-implementation fidelity) is real but not load-bearing against the stated contribution once code is public; no internal inconsistency or unsupported novelty assertion appears in the text.","agreement_with_reader":"agree"},"referee_report":{"model":"grok-4.5","summary":"The paper presents DaiSy, an open-source C++/Python library that unifies four previously published exact iSAX-based similarity search algorithms—ParIS+ (disk), MESSI (in-memory), SING (GPU), and Odyssey (distributed)—under a layered architecture with shared distance primitives, an iSAX index service, and interchangeable execution backends. Exactness and SOTA status are inherited by reference to the original papers rather than re-proved. The library also supports L2-squared and DTW, z-normalized and non-normalized data, brute-force baselines, and is positioned as applicable to high-dimensional vector search. The only new empirical result is an in-memory comparison of DaiSy-MESSI against FAISS-IndexFlat on Deep100M and Seismic100M (Figure 3). The contribution is primarily systems/integration: a single coherent API and open artifact spanning multiple execution environments.","tokens_in":10804,"tokens_out":1130,"duration_ms":26408,"significance":"If the artifact faithfully packages the four engines under a usable dual-language interface, DaiSy fills a genuine gap: exact data-series (and vector) search tooling has been fragmented across specialized codebases. Open-sourcing a multi-environment library with C++ and Python bindings is a concrete community contribution that can lower adoption cost for exact search, ground-truth generation for approximate methods, and multi-hardware experimentation. Strengths that should be credited include the public GitHub release, the explicit layered design (core primitives / index service / execution models), dual-language demos and benchmarks, and the clear algorithm-selection decision tree (Figure 2). The work is incremental relative to the four prior systems papers, but the integration claim is real and useful for a systems/library venue.","major_comments":[{"comment":"§4.3 and Figure 3 provide the only new empirical evidence, and only for the in-memory MESSI backend versus FAISS-IndexFlat. The central multi-environment claim (disk, GPU, distributed) is not accompanied by any timing, scalability, or correctness check for ParIS+, SING, or Odyssey inside DaiSy. For a library paper this need not be a full re-evaluation of every original paper, but at least one controlled result per backend—or an explicit fidelity check against the original codebases—would make the “integrates SOTA without regression” claim load-bearing rather than purely by citation.","section":"§4.3, Figure 3"},{"comment":"§1 and §3.1 assert that all four algorithms “are guaranteed to always return the exact, correct answers” and that DaiSy inherits this property. Exactness is not re-proved and no regression-test methodology or differential check against the original implementations is described. Given that the library re-implements or re-packages these engines under a new adapter and distance layer (§3.1), a short statement of what was reimplemented versus wrapped, plus how exactness is validated in the released tests, is needed to support the correctness claim for users who will treat DaiSy as authoritative ground truth.","section":"§1, §3.1"}],"minor_comments":[{"comment":"Figure 1 is rendered as a dense block of placeholder glyphs in the manuscript text and is effectively unreadable. A clean component diagram is essential for a library architecture paper.","section":"Figure 1"},{"comment":"§2.1 positions FAISS, UCR Suite, TSSEARCH, AEON, and TSLEARN appropriately, but a one-sentence note on whether any other exact multi-backend data-series libraries exist (or that none do) would strengthen the “first library” claim.","section":"§2.1"},{"comment":"§3.3 notes that algorithms are “more suited to Z-normalized data” because default iSAX breakpoints assume that; the API examples in §4.4 do not show how non-normalized mode is selected. A brief API note would help.","section":"§3.3, §4.4"},{"comment":"Author emails in the header appear truncated (e.g., “francescadelgaudio56 @gmail.com”, “manos.chatzaki @gmail.com”). Fix for the camera-ready version.","section":"Title page"},{"comment":"§5 lists planned extensions (Bayesian hyperparameter tuning, subsequence search, streaming, early termination). These are fine as future work; ensure they are not read as current features of the released library.","section":"§5"}],"recommendation":"minor_revision","confidential_remarks":"Fit is appropriate for a systems/library track. Self-citation of ParIS+/MESSI/SING/Odyssey is ordinary for this group and not circular. The evaluation is thin for a full research paper but typical of short library/demo-style submissions; minor_revision asking for one fidelity or multi-backend result (or tempered claims) is proportionate. I did not find internal inconsistency; the stress-test concern about re-implementation fidelity is real but fixable with documentation and a small experiment rather than a redesign."},"author_rebuttal":null,"desk_editor":{"model":"grok-4.5","letter":"This is a clean library paper. What is new is the artifact itself: DaiSy packages four previously published exact engines (ParIS+, MESSI, SING, Odyssey) behind one layered C++/Python API covering disk, in-memory, GPU, and distributed settings, plus a simple decision tree and dual-language bindings. The algorithms are prior work by the same group and others; the unification, the adapter/index/search separation, and the public release are the contribution. That is legitimate systems novelty for this community.\n\nThey do the basics well. Architecture is coherent (core primitives, iSAX as a service, interchangeable execution models). Exactness is correctly inherited rather than re-proved. Code is open-sourced. The API examples are usable. The short MESSI-vs-FAISS-IndexFlat comparison on Deep100M and Seismic100M is a useful sanity check for the vector-search use case and shows clear speedups for exact answers. Related-work placement against FAISS, UCR Suite, etc., is fair: they are not claiming approximate search or subsequence search.\n\nSoft spots are real but proportional. Evaluation inside this manuscript is thin—one figure, broader SOTA claims deferred to earlier papers. Re-implementation fidelity is an assumption until someone audits the GitHub tree, but that is normal once the code is public and does not break the central claim that such a library now exists. Hyperparameters default to the original papers’ recommendations; no auto-tuning yet (they flag it as future work). None of this is load-bearing against a library contribution.\n\nWho it is for: people who need exact ground truth for data-series or high-d vector collections and do not want to stitch four separate codebases. It will not change theory, but it reduces friction. Math and citation pattern look ordinary and solid for systems work; no circularity games.\n\nI would send it to referees. Accept after ordinary library-paper scrutiny (code check, API completeness, whether the four backends still match the cited numbers). Worth engaging if you care about exact search tooling.","headline":"Solid systems library paper: first unified multi-backend exact iSAX search package with real code; novelty is integration, not new algorithms.","tokens_in":11442,"tokens_out":502,"would_cite":true,"duration_ms":6208,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"grok-4.5","headline":"DaiSy unifies exact data-series and vector similarity search across disk, memory, GPU, and distributed settings in one library.","keywords":["data series","exact similarity search","iSAX index","vector search","GPU acceleration","distributed search","library design"],"falsifier":"A head-to-head benchmark, on the same hardware and datasets used in the original papers, that shows either incorrect nearest neighbors or substantially worse wall-clock time for any of the four back-ends relative to the original implementations.","tokens_in":11507,"feed_emoji":"📚","tokens_out":632,"duration_ms":6775,"temperature":0.7,"pith_summary":"Exact nearest-neighbor search over huge collections of data series (and high-dimensional vectors) is required by many analytics tasks, yet the best algorithms live in separate codebases, each locked to one hardware setting. This paper presents DaiSy, an open library that folds four leading exact iSAX-based algorithms into a single C++ core with matching Python bindings. The same conceptual pipeline—index build plus exact k-NN search—runs on disk when data do not fit in RAM, entirely in memory on multi-core CPUs, with GPU offload, or across distributed nodes. Because the methods work on raw vectors as well as series, the library also supplies ground-truth answers for approximate vector-search workloads. Users select an algorithm by data size and available hardware; default hyperparameters come from the original papers, and both L2-squared and DTW distances are supported with early-abort lower bounds. The result is a practical, extensible stack that removes the need to re-implement or re-wire specialized systems for each new environment.","feed_headline":"One library runs exact series and vector search on disk, CPU, GPU, cluster","feed_subtitle":"Four leading exact algorithms share a single C++/Python interface and always return the true nearest neighbors.","key_machinery":"A layered C++ architecture whose core primitives (distance computer with lower bounds, adapter-based data streams, shared iSAX index service) are reused by interchangeable execution models—ParIS+ (disk), MESSI (in-memory), SING (GPU), Odyssey (distributed)—all exposed through the same buildIndex/searchIndex API in C++ and Python.","core_discovery":"DaiSy is the first library that delivers exact similarity search for data series and vectors under a single coherent interface while spanning disk-based, in-memory, GPU-accelerated, and distributed execution, by integrating one state-of-the-art iSAX algorithm for each setting and guaranteeing that every returned answer is exact.","pith_inferences":[],"forward_implications":[],"fun_headline_variants":["DaiSy unifies exact series and vector search on disk, CPU, GPU, cluster","One C++/Python library for exact iSAX search of series and vectors across all setups","Exact nearest-neighbor search for series and vectors from disk to distributed","Single coherent interface spans disk, memory, GPU and cluster for exact search","DaiSy integrates four exact iSAX engines for series and vectors under one API"],"cache_read_input_tokens":128,"weakest_assumption_plain":"The four chosen algorithms remain the right representatives of their hardware regimes, and the library re-implementation preserves both their exactness guarantees and their published performance without new regressions.","fun_headline_variants_meta":{"raw":{"variants":["DaiSy unifies exact series and vector search on disk, CPU, GPU, cluster","One C++/Python library for exact iSAX search of series and vectors across all setups","Exact nearest-neighbor search for series and vectors from disk to distributed","Single coherent interface spans disk, memory, GPU and cluster for exact search","DaiSy integrates four exact iSAX engines for series and vectors under one API"]},"model":"grok-4.5","effort":"low","cost_usd":0.006954,"raw_usage":{"total_tokens":1695,"prompt_tokens":708,"num_sources_used":0,"completion_tokens":107,"cost_in_usd_ticks":69540000,"prompt_tokens_details":{"text_tokens":708,"audio_tokens":0,"image_tokens":0,"cached_tokens":256},"completion_tokens_details":{"audio_tokens":0,"reasoning_tokens":880,"accepted_prediction_tokens":0,"rejected_prediction_tokens":0}},"tokens_in":708,"tokens_out":107,"duration_ms":8301,"temperature":1.0,"reasoning_tokens":880,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-07-13T16:46:25.848712+00:00","model_set":{"reader":"grok-4.5"},"falsifier":"A head-to-head benchmark, on the same hardware and datasets used in the original papers, that shows either incorrect nearest neighbors or substantially worse wall-clock time for any of the four back-ends relative to the original implementations.","supporting_citations":[],"review_version":1}