{"id":"4c805482-9df6-47c3-adab-89625f663720","arxiv_id":"2507.02210","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"low","formal_verification":"none","parameter_count":0,"one_line_summary":"The exoatlas package provides a Python interface for retrieving, deriving, and visualizing exoplanet and Solar System populations.","lead":"exoatlas is a new Python package that pulls exoplanet and Solar System data into one table, calculates derived properties with uncertainties, and plots comparisons. This paper is the software description that accompanies the release.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The paper's central claim is unverifiable as written: no repository, release, or commit hash is provided, so the described API behavior and the example in Figure 1 cannot be checked against the actual code.","rationale":"The reader's conditional verdict is the right one. The manuscript is a clear, modest software description, and Figure 1 is genuine support for the visualization claim. However, the strongest claim that exoatlas reduces effort for population-context tasks depends on the package being publicly usable and on the API wrappers returning accurate, current data. The paper does not provide a source repository, DOI, or commit hash, so neither the code itself nor the exact version described is identifiable. This is not a matter of style; it is the central evidence for a software paper. The concrete proposed test would settle the concern: if a pinned version installs and reproduces the paper's example, and its results match a direct archive query, the conditional can be lifted. If the artifact cannot be located or fails these checks, the claim remains unverified.","tokens_in":2831,"tokens_out":2702,"duration_ms":33937,"concrete_test":"In a clean environment, install the exact version of exoatlas referenced by the paper's documentation site; run the six-line example from §3 and verify it reproduces Figure 1; then compare the resulting exoplanet table against a direct NASA Exoplanet Archive API query for the same date, checking row count and key columns, and confirm that any planet missing a semimajor axis gets one from Kepler's third law whose uncertainty is numerically propagated, not silently dropped.","verdict_should_be":"UNCHANGED","load_bearing_attack":"To support the claim that exoatlas provides a friendly, working Python interface, the package must be publicly available in a versioned form and its data-access wrappers must return correct, current data from the NASA Exoplanet Archive and JPL Solar System Dynamics APIs (§3). The manuscript provides neither a repository URL, DOI, nor commit hash; it only names a documentation site. This makes the primary artifact unverifiable. A reader cannot rerun the six-line code block that supposedly produces Figure 1, cannot confirm that Population objects parse archival columns as claimed, and cannot check Kepler-derived semimajor axes or the astropy.uncertainty propagation described in §3. The absence of tests or benchmark output is particularly relevant because the value of the package is precisely that it hides these API and unit-handling details; if a wrapper is wrong, the friendly interface silently produces incorrect context. Figure 1 is a visual example, but without the generating code and version it cannot validate the claimed behavior.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The manuscript describes exoatlas, a Python package intended to provide a friendly interface for retrieving and working with exoplanet and Solar System planet populations. The central abstraction is a Population class that pulls data from the NASA Exoplanet Archive and JPL Solar System Dynamics, attaches astropy units, computes derived quantities such as semimajor axes with numerically propagated uncertainties, supports masking and subpopulation creation, plans ground-based observations of transits, and offers a visual-language layer for population comparison figures. The paper demonstrates the interface with a six-line code example that produces a gallery placing HD 209458b in context with transiting exoplanets and Solar System planets. No repository URL, version identifier, tests, or benchmark outputs are included in the manuscript.","tokens_in":2983,"tokens_out":2183,"duration_ms":29472,"significance":"If the package works as described, it could lower the barrier for students, educators, and researchers who wish to contextualize individual planets within broad populations, and it would provide a useful pedagogical complement to the existing archive services. The paper's scientific claims are modest and are largely about software behavior rather than astrophysical results, and the design choices—standard archives, astropy-based units and uncertainty propagation, a uniform column naming scheme—are sensible and aligned with current community practice. The main strength is conceptual: the package would centralize several commonly repeated tasks in one consistent API. However, the significance is currently conditional because the manuscript provides no way to verify the software, no reproducibility artifacts, and no external validation of the data-access wrappers or derived-quantity calculations.","major_comments":[{"comment":"The central claim that exoatlas is a friendly, working Python interface is unverifiable as written. The manuscript identifies only a documentation URL (zkbt.github.io/exoatlas/) but provides no persistent repository address, DOI, release tag, or commit hash. A reader cannot run the six-line code block in §3 that supposedly generates Figure 1, cannot inspect the Population class implementation, and cannot check how archival columns are parsed or how derived quantities and uncertainties are computed. For a software-description paper, versioned, publicly accessible source code is the primary evidence for the claims, and its absence is a load-bearing omission rather than a presentation issue.","section":"General availability and §3"},{"comment":"The manuscript asserts that Population objects 'automatically access archive data' from the NASA Exoplanet Archive and JPL Solar System Dynamics APIs, but it provides no tests, no example outputs, and no demonstration that the wrappers correctly handle the current API schemas or column names. Because the value of the package is precisely that it hides these details, an incorrect wrapper would silently produce wrong contexts for every user. The paper should include a small test suite or at least a minimal verification script showing that the returned tables match known reference values (e.g., a handful of known planets and their published orbital parameters) and that the semimajor-axis calculation reproduces archival values within propagated uncertainties.","section":"§3, first bullet"},{"comment":"The derived-quantity workflow is described only in prose. Specifically, the semimajor axis is said to be calculated from P and M⋆ using Kepler's third law, with uncertainties propagated through astropy.uncertainty, but the manuscript does not state the input column names, the assumed mass units, the handling of missing stellar masses, or the treatment of non-Gaussian uncertainties. Without a documented formula and a sample of computed outputs compared against independent values, the correctness of this central feature cannot be assessed. Please provide the actual calculation function or a detailed specification with at least one worked example.","section":"§3, second bullet"},{"comment":"The six-line code example is presented as evidence of usability, but the figure is not reproducible from the manuscript alone. The example calls TransitingExoplanets() and SolarSystem() and then indexes e[\"HD209458b\"], but the manuscript never specifies how naming-based indexing is implemented, which archive columns back the planet name, or which version of the package produces the figure. Including the generating script with a pinned dependency environment and versioned package would make the figure a meaningful artifact rather than an unverifiable screenshot.","section":"Figure 1 and §3, sixth bullet"}],"minor_comments":[{"comment":"The author list contains 'Autumn Stephens' twice; one occurrence should be removed.","section":"Title page/author list"},{"comment":"The abstract and the first paragraph of §1 are nearly identical; consider condensing one of them.","section":"Abstract and §1"},{"comment":"The text reads 'Figure Figure 1'; the duplicated word should be corrected.","section":"§3, bullet 6"},{"comment":"There is a typo, 'acheivable' for 'achievable'.","section":"§3, bullet 4"},{"comment":"The sentence 'All these communities are encouraged try exoatlas' is missing 'to' before 'try'.","section":"§4"},{"comment":"The statement about indexing, slicing, and masking is clear in intent, but the manuscript does not give an example of how masked Population objects are created; a one-line example would make this feature concrete.","section":"§3, third bullet"},{"comment":"The documentation URL appears only as plain text and is not a clickable link; also, no license or installation instructions are given, which are important for a software paper.","section":"References and documentation"},{"comment":"The caption refers to 'Errorbars'; the standard spelling 'error bars' would be clearer.","section":"Figure 1 caption"}],"recommendation":"major_revision","confidential_remarks":"This appears to be a software-description paper rather than a research-advance paper. For a journal that publishes such contributions, the absence of a persistent archive link and the lack of any reproducibility test is the key editorial gate: the manuscript should not be considered until the package is publicly available under a stable version identifier and the authors provide a minimal verification suite. I would also ask the editor to consider whether the journal's scope requires an astrophysical result or demonstration beyond a usability-oriented software description, as the current text is largely a feature list."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThe one thing to know: this is a clean, modest software-description paper for a Python package that pulls exoplanet and Solar System data into a single Population interface. It is not a scientific discovery, and the authors don't claim it is. The useful part is real — for teaching and quick context plots, this kind of tool saves time, and the design choices (astropy units, astropy.uncertainty propagation, astroplan for observation planning) are sensible and familiar to the community.\n\nWhat's new: no prior tool cited offers this particular integration of archive APIs plus derived quantities plus built-in visualization gallery. That's a legitimate niche. The paper is also well written and the six-line figure example is convincing as a demo, assuming the code behind it exists and works.\n\nThe soft spot, which is big: the paper gives no repository URL, no DOI, no commit hash. It only mentions a documentation site. That means the central claim — that exoatlas works as described — cannot be checked by any reader. The stress-test note is right. A referee cannot rerun the example, cannot verify the Kepler-law fallback or the uncertainty sampling, and cannot confirm that the NASA Exoplanet Archive and JPL wrappers are correct. For a software paper, that is not a minor omission; it's the whole artifact. Also, the text appears to have a duplicated author name (\"Autumn Stephens\" twice) and a stray running header \"Probabilistic Cosmic Shorelines\" — editing not science, but sloppy.\n\nOn the plus side, the scientific claims are modest and internally consistent; there's no derived physics being over-sold, and the reliance on external archives is disclosed. I don't see a circularity problem, and the citations to archives and astropy are appropriate.\n\nBottom line: this deserves peer review, but only with the condition that the authors provide a versioned, public repository and ideally a test suite or at least a reproducible script for Figure 1. If that appears, the paper is a solid JOSS- or RNAAS-style contribution. If it doesn't, a serious editor should send it back, because right now the core claim is an act of faith.","headline":"A well-intentioned, clearly written software wrapper paper that is unverifiable as submitted because no code repository or version is given; worth refereeing only if that is fixed.","tokens_in":3475,"tokens_out":1804,"would_cite":false,"duration_ms":20733,"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":"exoatlas is a Python toolkit that wraps public planet archives behind a single `Population` class, so any exoplanet or Solar System object can be retrieved, analyzed, and visualized in population context with units, propagated…","keywords":["exoplanet populations","Python package","astronomical data access","uncertainty propagation","exoplanet visualization","observation planning","science education"],"falsifier":"In a clean environment, build a `TransitingExoplanets` population and compare every returned quantity (period, radius, derived semimajor axis, units) against the same entries queried directly from the source archive; if any value or unit disagrees, or if a download fails, the interface is not faithful.","tokens_in":2681,"feed_emoji":"🪐","tokens_out":8198,"duration_ms":89921,"temperature":0.7,"pith_summary":"This paper presents exoatlas, a Python package built around the idea that individual planets are best understood in population context. The package provides a `Population` class that pulls exoplanet and Solar System object data from public archives into a single standardized table, computes derived quantities with numerically propagated uncertainties, filters subpopulations, plans observations, and produces comparison visualizations. The authors argue this lowers the barrier for researchers, educators, and students who want to place a specific world next to its peers. If the package works as described, it turns a previously multi-step data-wrangling chore into a few lines of code.","feed_headline":"Six lines of Python place any planet in population context","feed_subtitle":"A Population class fetches archive data, computes derived quantities, and builds context plots with one call.","key_machinery":"The carrying object is the `Population` class: a standardized table of planet properties with physical units, plus attached methods for derivation, filtering, observation planning, and plotting. Its load-bearing pieces are fallback derivations for missing quantities (for example, semimajor axis from period and stellar mass via Kepler's Third Law, then from transit-derived $a/R_\\ast$), numerical propagation of uncertainties by carrying sample distributions through calculations, and a plotting language built from `Plottable` (how a quantity is scaled and labelled), `Map` (position, size, or color encoding), and `Gallery` (linked panels).","core_discovery":"The paper's central claim is that population context should be a routine, low-effort operation, and that exoatlas delivers it. The authors describe a `Population` class that retrieves uniform tables of exoplanet and Solar System properties, computes derived quantities such as semimajor axis from period and stellar mass when needed, propagates uncertainties numerically through all calculations, supports masking and slicing to build comparison subpopulations, estimates signal-to-noise for observables, and renders context plots. A six-line example places the first discovered transiting exoplanet HD209458b among other transiting exoplanets and the eight major Solar System planets. If the package performs as described, it makes the connection between an individual world and its population immediate for researchers, educators, and students.","pith_inferences":["A natural testable extension would be to validate the wrapper by comparing a downloaded `Population` table line by line with a direct query of the same archive, which would also catch upstream format changes.","The same `Population`/`Plottable`/`Map`/`Gallery` pattern could be applied to other astronomical catalogs, such as stellar or galaxy populations, giving the same low-effort context for different kinds of objects.","Because the package's value depends on current archive contents, adding versioned snapshots or data provenance stamps would make analyses reproducible after archives update."],"forward_implications":["A user can retrieve a uniform, unit-aware table of exoplanet and Solar System properties without learning each archive's query language.","Missing measurements are filled automatically from fallback formulas, so analyses keep working when catalogs are incomplete.","Subpopulations can be built by indexing, slicing, and masking, and custom calculations can be attached to the resulting `Population` objects.","The package can flag upcoming transits visible from a given ground-based telescope by combining predicted times with local altitude and azimuth.","A handful of lines is enough to generate a published-quality population comparison plot, as in the HD209458b example."],"supporting_citations":[{"why":"Supplies the default exoplanet population data through its public API.","marker":"J. L. Christiansen et al. 2025"},{"why":"Supplies Solar System object data through the Solar System Dynamics service.","marker":"JPL 2025"},{"why":"Provides the table, unit, coordinate, and uncertainty machinery the `Population` interface is built on.","marker":"Astropy Collaboration et al. 2022"},{"why":"Provides the observation-planning utilities used for altitude, azimuth, and upcoming transit windows.","marker":"B. M. Morris et al. 2018"}],"fun_headline_variants":["Six lines of Python: any exoplanet in population context","Connect a planet to its population in six lines","Exoplanet context for any planet in six lines","A Python class that puts planets in population context"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"Everything rests on the automatic downloads from public planet databases, and the unit and uncertainty calculations built on them, being implemented correctly and staying current as those databases change.","fun_headline_variants_meta":{"raw":{"variants":["Six lines of Python: any exoplanet in population context","Connect a planet to its population in six lines","Exoplanet context for any planet in six lines","A Python class that puts planets in population context"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001117,"raw_usage":{"total_tokens":4555,"prompt_tokens":755,"completion_tokens":3800,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":371,"completion_tokens_details":{"reasoning_tokens":3737}},"tokens_in":371,"tokens_out":3800,"duration_ms":33800,"temperature":1.0,"reasoning_tokens":3737,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T20:33:23.135805+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"In a clean environment, build a `TransitingExoplanets` population and compare every returned quantity (period, radius, derived semimajor axis, units) against the same entries queried directly from the source archive; if any value or unit disagrees, or if a download fails, the interface is not faithful.","supporting_citations":[{"cited_title":"2025, title Solar System Dynamics, https://ssd.jpl.nasa.gov","cited_arxiv_id":null,"evidence_quote":"Supplies Solar System object data through the Solar System Dynamics service."}],"review_version":1}