Pith. sign in

REVIEW 3 major objections 8 minor 62 references

AERO: An autonomous platform for continuous research

T0 review · 3 major / 8 minor · reviewed 2026-08-07 · deepseek-v4-flash

Pith's one-line read AERO is a distributed event-triggered research automation platform that runs ingestion and analysis flows on user-provided resources and appears to scale near-perfectly with concurrency.

desk verdict AERO is a real, open-source continuous-research automation platform with two working public-health workflows, undermined only by an overbroad 'arbitrary processes' claim and a thin benchmark. read the letter →

arxiv 2505.18408 v1 pith:LIVD2LAC submitted 2025-05-23 cs.CE

classification cs.CE
keywords researchautomationtrigger-actionprogrammingevent-drivenworkflowsdistributedcomputingprovenancescientificdatasharingpublichealthsurveillanceeffectivereproductionnumber
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper is trying to establish that the repetitive loop of research—fetching new data, validating it, transforming it, running analyses, and sharing results—can be delegated to an automation hub that watches for events and executes user-defined flows on the researchers' own computers, clusters, and storage. The authors argue that this fetch, compute, publish pattern is general across domains, not just the two public-health applications they demonstrate. They support the generality claim with a synthetic benchmark in which the platform's makespan stays nearly flat as concurrent flow runs increase from 1 to 20, i.e., near-perfect scaling. If the claim holds, researchers stop being the humans-in-the-loop who poll data sources and re-run pipelines, freeing time for interpretation and discovery.

What carries the argument

The load-bearing mechanism is the trigger-action flow: a user registers a flow with a rule, the rule is evaluated on periodic timers or on updates to monitored data, and a satisfied rule invokes a sequence of user-defined actions on remote compute endpoints the researcher controls. The property that makes the system more than a scheduler is the provenance tree: every monitored output is recorded with the function and inputs that produced it, and when an output is updated the platform checks whether any other flow depends on it, evaluates that flow's rule, and starts it. This gives a data-driven cascade of ingestion, analysis, and reporting steps. The platform's distributed storage model, in which data stay on user-provided storage and only metadata live centrally, is what allows private and sensitive data to be automated without the platform holding them.

What would settle it

Register a flow whose rerun condition depends on data content (for example, 're-run only when the latest wastewater measurement exceeds a threshold') using only AERO's built-in periodic and update rules. If such a condition cannot be expressed without moving the policy into the user's analysis function, the claim of automating arbitrary research processes fails. A second check: run the synthetic ingestion benchmark at 50 or 100 concurrent flows to see whether the near-flat makespan shown for 1 to 20 flows persists.

Watch

Extended reading notes

Core claim

The paper's central claim is that end-to-end research automation can be assembled from a small set of primitives rather than bespoke per-domain systems: rule-based triggers, flows made of modular actions, a centralized metadata registry, and user-supplied compute and storage. Its benchmark results show that this assembly scales: as the number of concurrent no-op ingestion flows grows from 1 to 20, makespan stays nearly flat, which the authors read as near-perfect scaling, and one execution backend finishes on average faster than the repository-integrated one. Two public-health deployments demonstrate the same machinery on lightweight and computationally heavy analyses: estimating the effective reproduction number $R(t)$ from clinical surveillance data and from wastewater pathogen concentrations. The paper argues that this fetch, compute, publish loop generalizes to any domain where data arrive on a schedule or on update.

Load-bearing premise

The platform's promise to automate arbitrary research processes rests on the assumption that rule-based triggers—timers and updates to monitored data—are enough to capture the decisions researchers would otherwise make; the paper itself notes that its rules are statically defined, so richer policies cannot be expressed.

Editorial extensions

If this is right

  • When an ingested dataset changes, all analysis flows that depend on it can re-run automatically, and outputs that other flows depend on propagate through the provenance tree without human initiation.
  • Research groups can keep private data on their own storage and still participate in automated cross-team pipelines, since compute and data transfer happen at user-held endpoints.
  • The same platform abstractions should transfer to other data-driven fields beyond epidemiology, wherever the repeatable cycle is fetch, validate, transform, analyze, and publish.
  • Every automated run leaves a metadata and provenance record, so results are reproducible and can be replayed or audited later.
  • Because two independent execution backends can drive the same flows, users can choose the automation style they already know without rewriting their analysis functions.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The phrase 'arbitrary research processes' is broader than what the current rule engine can express: only periodic and data-update rules are built in, so content-dependent rerun policies must be encoded inside user functions. A natural extension is first-class user-defined predicates over metadata or data samples as trigger conditions.
  • The near-perfect scaling result was measured on no-op ingestion flows with up to 20 concurrent runs; whether it holds for compute-heavy analyses or larger concurrency is an open question the paper does not test.
  • The OAuth-based consent model, with each flow as its own resource server, suggests the platform could support multi-institutional collaborations where sites share only curated outputs; the paper does not evaluate such cross-organization use at scale.
  • The fetch-compute-publish pattern maps directly onto continuous dashboards, model updating, and living papers, though the paper only claims public-health modeling and synthetic workloads.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 8 minor

Summary. The paper presents AERO, an open-source platform for automated scientific research workflows. AERO uses a trigger-action model: users register flows (via Globus Flows or GitHub Actions) that are executed on user-provided compute and storage resources when rules are satisfied. The rules are limited to periodic timers and state changes ('some inputs changed' or 'all inputs changed'); threshold- or value-based policies must be implemented inside user-supplied action functions. The paper reports a synthetic benchmark comparing Globus Flows and GitHub Actions at increasing concurrency, and two public-health use cases: R(t) estimation from Chicago hospitalization data and from wastewater data. All code and data are publicly available.

Significance. If the central claims are appropriately scoped, AERO is a useful contribution: it provides a working, open-source system that automates repetitive data ingestion and analysis steps across distributed resources, with provenance tracking and data sharing via Globus. The platform is built on widely adopted infrastructure (Globus, GitHub), and the authors provide public code, Docker setup, and real-world use-case implementations. The synthetic benchmark gives some indication of throughput, and the two use cases demonstrate that non-trivial epidemiological analyses (including Julia and R components) can be embedded in automated flows. The paper is not a theoretical derivation, so circularity is not a concern; the main risk is that the advertised 'arbitrary research processes' and 'near-perfect scaling' are stronger than what the implementation and evaluation support.

major comments (3)
  1. [Introduction (p.2) and Automation triggers (p.9)] The Introduction claims that AERO 'allows researchers to automate arbitrary research processes via a novel trigger-action paradigm,' but the implementation in 'Automation triggers' supports only three rule types: periodic, some monitored inputs changed, and all monitored inputs changed. The paper explicitly states that threshold- or value-based policies cannot be expressed as rules and must be embedded in user-defined action code ('an action containing a user-defined policy must be described by the user and executed alongside the analysis function'), and the Discussion concedes that 'The rules enabled by the system are statically defined, restricting users to define additional policies within their automated flows.' Because the trigger-action layer is the advertised paradigm, this overstatement is load-bearing; the paper should either scoped the claim to event-driven processes with timer/version-change triggers, or explain how user-delegated policies preserve the generality. The GitHub Actions execution mode, which 'delegates all automation (i.e., trigger definition) to GitHub Actions,' further narrows the platform's own automation semantics.
  2. [Evaluation, Synthetic application (pp.12-13, Fig. 5)] The synthetic scaling claim is based on only five repetitions with no reported error bars, confidence intervals, or per-repetition values, despite the text acknowledging 'variability was high between the individual runs.' The observed makespan is roughly constant (approximately 60-70 s) across concurrency levels 1-20, which does not by itself demonstrate 'near-perfect scaling.' The authors should report the full distribution of results (e.g., min/max or standard deviation), and either fit a scaling model or discuss how production-service overhead affects the makespan versus concurrency relationship.
  3. [Use case: R(t) estimation (pp.14-15)] The two real-world use cases are described narratively with example output plots, but no quantitative evaluation is provided: there are no reports of end-to-end execution times, number of automated runs, success rates, out-of-date data detection, or comparison with a manually executed baseline. Consequently, the statement in the Introduction that 'Our results demonstrate the performance and utility of AERO' is only partially supported. Adding quantitative metrics, even simple counts of automated invocations and timings, would strengthen the utility claim.
minor comments (8)
  1. [Global] Throughout the manuscript, there are many missing spaces after 'AERO' (e.g., 'AEROis', 'AEROand', 'automatedAEROworkflow'); a global pass to fix spacing is needed.
  2. [Figure 5] Figure 5 lacks error bars and a legend; the reader cannot tell whether the plotted points represent means, medians, or individual runs.
  3. [Figure 6] Figure 6 contains the misspellings 'exection' and 'T ask execution' in the caption and panel labels.
  4. [Figure 3] Figure 3's caption uses 'moniter' instead of 'monitor'.
  5. [Registering Automated Flows] The GitHub Action is referred to as 'CORRECT' in the text, but reference [31] lists 'CORRET'; the name should be consistent.
  6. [Automated science requirements] The requirement of being 'language-agnostic' (p.4) is not fully reflected in the implementation, which relies on Python functions for Globus Compute; the paper should clarify that external codes can be wrapped (as Julia and R are in the wastewater use case) and that only a Python shim is required.
  7. [Security Model] The security model section (p.11) says 'Globus Auth implements OAuth 2' without version; it should say 'OAuth 2.0'.
  8. [Data Availability] The data availability link to the Globus Collection (p.17) is a file-manager UI URL; a stable collection ID or a direct transfer endpoint would be more useful for reproducibility.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: AERO's central claims rest on a deployed implementation, public artifacts, and empirical benchmarks, not on equations that reduce to their inputs.

full rationale

This is a systems and evaluation paper, not a derivation with fitted parameters or predicted quantities. The central claims—that AERO automates ingestion and analysis flows through rule-based triggers on distributed user-provided resources and that the synthetic application exhibits near-perfect scaling—are supported by a publicly available implementation, deployment on Chameleon, and measurements against external production services (Globus Flows, GitHub Actions, Globus Compute). Citations to Globus, Parsl, funcX, and related prior work by the authors describe infrastructure that AERO builds on; they are background support, not a result being derived, and none is invoked to forbid alternatives or force the design. The manuscript itself flags a genuine limitation in the 'Automation triggers' section and Discussion: 'as AERO does not manage any data locally, an action containing a user-defined policy must be described by the user and executed alongside the analysis function,' and 'The rules enabled by the system are statically defined, restricting users to define additional policies within their automated flows.' This narrows the advertised 'arbitrary research processes' claim and is a correctness/generality concern, but it is not circularity: no equation or prediction is equivalent to an input by construction, and no fitted parameter is renamed as a prediction. The benchmark measures the actual implementation rather than a quantity defined by the benchmark's assumptions. Hence no significant circularity.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

AERO introduces no fitted parameters or new entities; it is an orchestration layer over existing services. Its central claims rest on domain assumptions about data accessibility, the sufficiency of rule-based triggers, and the stability of the Globus infrastructure.

assumptions (3)
  • domain assumption External data sources expose an HTTP(S) API for ingestion
    The ingestion flow design in the Methods section requires remote data locations to provide HTTP(S) APIs; sources without such APIs cannot be ingested.
  • domain assumption Rule-based trigger-action programming can express the needed automation logic
    The platform's automation model is built on this premise; the Discussion admits rules are statically defined, limiting expressiveness.
  • domain assumption Globus services provide the required security, execution, and metadata capabilities
    AERO relies on Globus Auth, Compute, Flows, Search, and Timers as the substrate for security, compute, and storage; if these services change or fail, AERO's guarantees change.

how reviews work

0 comments
Cite this review

Pith. "Pith review of AERO: An autonomous platform for continuous research." pith.science (2026). https://pith.science/paper/LIVD2LAC

@misc{pith2026250518408,
  author       = {Pith},
  title        = {Pith review of: AERO: An autonomous platform for continuous research},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/LIVD2LAC}},
  note         = {Machine review of arXiv:2505.18408}
}
read the original abstract

The COVID-19 pandemic highlighted the need for new data infrastructure, as epidemiologists and public health workers raced to harness rapidly evolving data, analytics, and infrastructure in support of cross-sector investigations. To meet this need, we developed AERO, an automated research and data sharing platform for continuous, distributed, and multi-disciplinary collaboration. In this paper, we describe the AERO design and how it supports the automatic ingestion, validation, and transformation of monitored data into a form suitable for analysis; the automated execution of analyses on this data; and the sharing of data among different entities. We also describe how our AERO implementation leverages capabilities provided by the Globus platform and GitHub for automation, distributed execution, data sharing, and authentication. We present results obtained with an instance of AERO running two public health surveillance applications and demonstrate benchmarking results with a synthetic application, all of which are publicly available for testing.

Figures

Figures reproduced from arXiv: 2505.18408 by the authors.

Figure 1
Figure 1. AERO enables automated workflow execution by incorporating five core components. Users interact with the metadata server to register flows using rule-based triggers, which drive the automation. When rules are satisfied, they trigger user-defined actions that execute within predefined ingestion or analysis flows on user-provided compute and storage resources. As AERO leverages user-provided data and infrastructure, a… view at source ↗
Figure 2
Figure 2. AERO reference implementation event flow. Data is ingested from external sources via an automated timer-based ingestion flow that fetches, validates and stores the data on external storage at periodic intervals. The ingested data can then be queried through the centralized metadata server, and incorporated into automated analysis flows, which produce reports and visualizations that can then be shared with stakeholde… view at source ↗
Figure 3
Figure 3. AERO’s bring-your-own-resources model. Centralized services in AERO include a database for capturing metadata, the web services, and the user-specified rule-based triggers increasing number of users. Moreover, users can pre-configure their resources as necessary to run their flows and can easily perform access control to their data. Furthermore, the decentralized distributed architecture relieves AERO from requiring… view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: AERO Search web interface. Search Data in AERO must be discoverable, with their corresponding ID and version easily accessible to users. AERO leverages the Globus Search service to provide free-text search over managed data. Globus Search builds on ElasticSearch, provi…
Figure 5
Figure 5. Figure 5: Makespan of synthetic ingestion application using GitHub Actions and Globus Flows over 5 repetitions client be permitted to execute functions on that endpoint. This can be accomplished by deploying a Globus Compute single user endpoint and enabling sharing [34] or by d…
Figure 6
Figure 6. Figure 6: Synthetic application step and task execution. Top row: GitHub Actions step and task execution times. Bottom row: Globus Flows step and task execution times. Step execution denotes the step start and end times reported by the framework. Task execution denotes the start…
Figure 7
Figure 7. Figure 7: Example wastewater output report generated by AERO registered analysis. Discussion AERO addresses the requirements for automated scientific research with 1) rule-based triggers and automated flow execution on distributed, user-supplied compute and storage resources; 2)…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

62 extracted references · 53 canonical work pages

  1. [1]

    A notation and system for expressing and executing cleanly typed workflows on messy scientific data

    Zhao Y, Dobson J, Foster I, Moreau L, Wilde M. A notation and system for expressing and executing cleanly typed workflows on messy scientific data. ACM Sigmod Record. 2005;34(3):37–43

  2. [2]

    Parallel scripting for applications at the petascale and beyond

    Wilde M, Foster I, Iskra K, Beckman P, Zhang Z, Espinosa A, et al. Parallel scripting for applications at the petascale and beyond. Computer. 2009;42(11):50–60

  3. [3]

    Parsl: Pervasive parallel programming in Python

    Babuji Y, Woodard A, Li Z, Katz DS, Clifford B, Kumar R, et al. Parsl: Pervasive parallel programming in Python. In: Proceedings of the 28th International Symposium on High-Performance Parallel and Distributed Computing; 2019. p. 25–36

  4. [4]

    Pegasus, a workflow management system for science automation

    Deelman E, Vahi K, Juve G, Rynge M, Callaghan S, Maechling PJ, et al. Pegasus, a workflow management system for science automation. Future Generation Computer Systems. 2015;46:17–35

  5. [5]

    Nextflow enables reproducible computational workflows

    Di Tommaso P, Chatzou M, Floden EW, Barja PP, Palumbo E, Notredame C. Nextflow enables reproducible computational workflows. Nature biotechnology. 2017;35(4):316–319

  6. [6]

    From Desktop to Large-Scale Model Exploration with Swift/T

    Ozik J, Collier NT, Wozniak JM, Spagnuolo C. From Desktop to Large-Scale Model Exploration with Swift/T. In: 2016 Winter Simulation Conference (WSC)

  7. [7]

    Distributed Model Exploration with EMEWS

    Collier N, Wozniak JM, Fadikar A, Stevens A, Ozik J. Distributed Model Exploration with EMEWS. In: 2024 Winter Simulation Conference (WSC). Orlando, FL, USA: IEEE; 2024. p. 72–86. Available from: https://ieeexplore.ieee.org/document/10838848/

  8. [8]

    Linking scientific instruments and computation: Patterns, technologies, and experiences

    Vescovi R, Chard R, Saint ND, Blaiszik B, Pruyne J, Bicer T, et al. Linking scientific instruments and computation: Patterns, technologies, and experiences. Patterns. 2022;3(10):100606. doi:https://doi.org/10.1016/j.patter.2022.100606

Show all 62 references
  1. [9]

    Globus automation services: Research process automation across the space–time continuum

    Chard R, Pruyne J, McKee K, Bryan J, Raumann B, Ananthakrishnan R, et al. Globus automation services: Research process automation across the space–time continuum. Future Generation Computer Systems. 2023;142:393–409. doi:https://doi.org/10.1016/j.future.2023.01.010. September ...

  2. [10]

    The hubverse: open tools for collaborative modeling; 2023

    Consortium of Infectious Disease Modeling Hubs. The hubverse: open tools for collaborative modeling; 2023. Available from: https://hubdocs.readthedocs.io/en/latest/

  3. [11]

    FluSight: Forecasting for Influenza Prevention and Control; 2023

    Centers for Disease Control and Prevention, National Center for Immunization and Respiratory Diseases (NCIRD). FluSight: Forecasting for Influenza Prevention and Control; 2023. Available from: https://hubdocs.readthedocs.io/en/latest/

  4. [12]

    Efficient and Secure Transfer, Synchronization, and Sharing of Big Data

    Chard K, Tuecke S, Foster I. Efficient and Secure Transfer, Synchronization, and Sharing of Big Data. IEEE Cloud Computing. 2014;1(3):46–55. doi:10.1109/MCC.2014.52

  5. [13]

    A modeling pipeline to relate municipal wastewater surveillance and regional public health data

    Leisman KP, Owen C, Warns MM, Tiwari A, Bian GZ, Owens SM, et al. A modeling pipeline to relate municipal wastewater surveillance and regional public health data. Water Research. 2024;252:121178. doi:10.1016/j.watres.2024.121178

  6. [14]

    Modeling robust COVID-19 intensive care unit occupancy thresholds for imposing mitigation to prevent exceeding capacities

    Runge M, Richardson RAK, Clay PA, Bell A, Holden TM, Singam M, et al. Modeling robust COVID-19 intensive care unit occupancy thresholds for imposing mitigation to prevent exceeding capacities. PLOS Global Public Health. 2022;2(5):e0000308. doi:10.1371/journal.pgph.0000308

  7. [15]

    The Value of Environmental Surveillance for Pandemic Response

    Lima PNd, Karr S, Lim JZ, Vardavas R, Roberts D, Kessler A, et al. The Value of Environmental Surveillance for Pandemic Response. Santa Monica, CA: RAND Corporation; 2024

  8. [16]

    A population data-driven workflow for COVID-19 modeling and learning

    Ozik J, Wozniak JM, Collier N, Macal CM, Binois M. A population data-driven workflow for COVID-19 modeling and learning. The International Journal of High Performance Computing Applications. 2021;35(5):483–499. doi:10.1177/10943420211035164

  9. [17]

    Impact of changes in protective behaviors and out-of-household activities by age on COVID-19 transmission and hospitalization in Chicago, Illinois

    Hotton AL, Ozik J, Kaligotla C, Collier N, Stevens A, Khanna AS, et al. Impact of changes in protective behaviors and out-of-household activities by age on COVID-19 transmission and hospitalization in Chicago, Illinois. Annals of Epidemiology. 2022; p. S1047279722001053. doi:1...

  10. [18]

    Mobility network models of COVID-19 explain inequities and inform reopening

    Chang S, Pierson E, Koh PW, Gerardin J, Redbird B, Grusky D, et al. Mobility network models of COVID-19 explain inequities and inform reopening. Nature. 2021;589(7840):82–87. doi:10.1038/s41586-020-2923-3

  11. [19]

    Multiple models for outbreak decision support in the face of uncertainty

    Shea K, Borchering RK, Probert WJM, Howerton E, Bogich TL, Li SL, et al. Multiple models for outbreak decision support in the face of uncertainty. Proceedings of the National Academy of Sciences. 2023;120(18):e2207537120. doi:10.1073/pnas.2207537120

  12. [20]

    Assessing COVID-19 pandemic policies and behaviours and their economic and educational trade-offs across US states from Jan 1, 2020, to July 31, 2022: an observational analysis

    Bollyky TJ, Castro E, Aravkin AY, Bhangdia K, Dalos J, Hulland EN, et al. Assessing COVID-19 pandemic policies and behaviours and their economic and educational trade-offs across US states from Jan 1, 2020, to July 31, 2022: an observational analysis. The Lancet. 2023;401(1038...

  13. [21]

    Global impact of the first year of COVID-19 vaccination: a mathematical modelling study

    Watson OJ, Barnsley G, Toor J, Hogan AB, Winskill P, Ghani AC. Global impact of the first year of COVID-19 vaccination: a mathematical modelling study. The Lancet Infectious Diseases. 2022;22(9):1293–1302. doi:10.1016/S1473-3099(22)00320-6. September 22, 2025 19/22

  14. [22]

    Ensemble Forecasts of Coronavirus Disease 2019 (COVID-19) in the U.S

    Ray EL, Wattanachit N, Niemi J, Kanji AH, House K, Cramer EY, et al. Ensemble Forecasts of Coronavirus Disease 2019 (COVID-19) in the U.S. Epidemiology; 2020. Available from: http://medrxiv.org/lookup/doi/10.1101/2020.08.19.20177493

  15. [23]

    Modeling of Future COVID-19 Cases, Hospitalizations, and Deaths, by Vaccination Rates and Nonpharmaceutical Intervention Scenarios — United States, April–September 2021

    Borchering RK, Viboud C, Howerton E, Smith CP, Truelove S, Runge MC, et al. Modeling of Future COVID-19 Cases, Hospitalizations, and Deaths, by Vaccination Rates and Nonpharmaceutical Intervention Scenarios — United States, April–September 2021. MMWR Morbidity and Mortality We...

  16. [24]

    Reopening California: Seeking robust, non-dominated COVID-19 exit strategies

    Lima PNd, Lempert R, Vardavas R, Baker L, Ringel J, Rutter CM, et al. Reopening California: Seeking robust, non-dominated COVID-19 exit strategies. PLOS ONE. 2021;16(10):e0259166. doi:10.1371/journal.pone.0259166

  17. [25]

    Practical considerations for measuring the effective reproductive number, Rt

    Gostic KM, McGough L, Baskerville EB, Abbott S, Joshi K, Tedijanto C, et al. Practical considerations for measuring the effective reproductive number, Rt. PLOS Computational Biology. 2020;16(12):e1008409. doi:10.1371/journal.pcbi.1008409

  18. [26]

    Tracking changes in SARS-CoV-2 transmission with a novel outpatient sentinel surveillance system in Chicago, USA

    Richardson R, Jorgensen E, Arevalo P, Holden TM, Gostic KM, Pacilli M, et al. Tracking changes in SARS-CoV-2 transmission with a novel outpatient sentinel surveillance system in Chicago, USA. Nature Communications. 2022; p. 5547. doi:10.1038/s41467-022-33317-6

  19. [27]

    Semiparametric inference of effective reproduction number dynamics from wastewater pathogen surveillance data; 2024

    Goldstein IH, Parker DM, Jiang S, Minin VM. Semiparametric inference of effective reproduction number dynamics from wastewater pathogen surveillance data; 2024. Available from:http://arxiv.org/abs/2308.15770

  20. [28]

    The FAIR Guiding Principles for scientific data management and stewardship

    Wilkinson MD, Dumontier M, Aalbersberg IJ, Appleton G, Axton M, Baak A, et al. The FAIR Guiding Principles for scientific data management and stewardship. Scientific data. 2016;3(1):1–9

  21. [29]

    Flask web development

    Grinberg M. Flask web development. O’Reilly Media, Inc.; 2018

  22. [30]

    Globus platform services for data publication

    Ananthakrishnan R, Blaiszik B, Chard K, Chard R, McCollam B, Pruyne J, et al. Globus platform services for data publication. In: Proceedings of the Practice and Experience on Advanced Research Computing: Seamless Creativity; 2018. p. 1–7

  23. [31]

    CORRET; 2025.https://github.com/globus-labs/correct

    Hayot-Sasson V. CORRET; 2025.https://github.com/globus-labs/correct

  24. [32]

    Practical trigger-action programming in the smart home

    Ur B, McManus E, Pak Yong Ho M, Littman ML. Practical trigger-action programming in the smart home. In: Proceedings of the SIGCHI conference on human factors in computing systems; 2014. p. 803–812

  25. [33]

    Globus Online: Accelerating and democratizing science through cloud-based services

    Foster I. Globus Online: Accelerating and democratizing science through cloud-based services. IEEE Internet Computing. 2011;15(3):70–73

  26. [34]

    funcX: A Federated Function Serving Fabric for Science

    Chard R, Babuji Y, Li Z, Skluzacek T, Woodard A, Blaiszik B, et al. funcX: A Federated Function Serving Fabric for Science. In: Proceedings of the 29th International Symposium on High-Performance Parallel and Distributed Computing. ACM; 2020.Available from: http://dx.doi.org/1...

  27. [35]

    Enabling Remote Management of FaaS Endpoints with Globus Compute Multi-User Endpoints

    Ananthakrishnan R, Babuji Y, Baughman M, Bryan J, Chard K, Chard R, et al. Enabling Remote Management of FaaS Endpoints with Globus Compute Multi-User Endpoints. In: Practice and Experience in Advanced Research September 22, 2025 20/22 Computing 2024: Human Powered Computing. ...

  28. [36]

    Lessons Learned from the Chameleon Testbed

    Keahey K, Anderson J, Zhen Z, Riteau P, Ruth P, Stanzione D, et al. Lessons Learned from the Chameleon Testbed. In: Proceedings of the 2020 USENIX Annual Technical Conference (USENIX ATC ’20). USENIX Association; 2020

  29. [37]

    Estimation and worldwide monitoring of the effective reproductive number of SARS-CoV-2

    Huisman JS, Scire J, Angst DC, Li J, Neher RA, Maathuis MH, et al. Estimation and worldwide monitoring of the effective reproductive number of SARS-CoV-2. eLife. 2022;11

  30. [38]

    epyestim; 2021.https://pypi.org/project/epyestim/

    Hilfiker L, Josi J. epyestim; 2021.https://pypi.org/project/epyestim/

  31. [39]

    A New Framework and Software to Estimate Time-Varying Reproduction Numbers During Epidemics

    Cori A, Ferguson NM, Fraser C, Cauchemez S. A New Framework and Software to Estimate Time-Varying Reproduction Numbers During Epidemics. American Journal of Epidemiology. 2013; p. 1505–1512. doi:10.1093/aje/kwt133

  32. [40]

    Reconstructing influenza incidence by deconvolution of daily mortality time series

    Goldstein E, Dushoff J, Ma J, Plotkin JB, Earn DJD, Lipsitch M. Reconstructing influenza incidence by deconvolution of daily mortality time series. Proceedings of the National Academy of Sciences. 2009;106(51):21825–21829. doi:10.1073/pnas.0902958106

  33. [41]

    Semiparametric inference of effective reproduction number dynamics from wastewater pathogen surveillance data

    Goldstein IH, Parker DM, Jiang S, Minin VM. Semiparametric inference of effective reproduction number dynamics from wastewater pathogen surveillance data. Biometrics. 2024;80(3). doi:10.1093/biomtc/ujae074

  34. [42]

    A survey of extract–transform–load technology

    Vassiliadis P. A survey of extract–transform–load technology. International Journal of Data Warehousing and Mining. 2009;5(3):1–27

  35. [43]

    The story of AWS Glue

    Saxena M, Sowell B, Alamgir D, Bahadur N, Bisht B, Chandrachood S, et al. The story of AWS Glue. In: VLDB 2023; 2023.Available from: https://www.amazon.science/publications/the-story-of-aws-glue

  36. [44]

    Introduction to Azure Data Factory

    Rawat S, Narain A, Rawat S, Narain A. Introduction to Azure Data Factory. Understanding Azure Data Factory: Operationalizing Big Data and Advanced Analytics Solutions. 2019; p. 13–56

  37. [45]

    Whole Tale

    Brinckman A, Chard K, Gaffney N, Hategan M, Jones MB, Kowalik K, et al. Computing environments for reproducibility: Capturing the “Whole Tale”. Future Generation Computer Systems. 2019;94:854–867

  38. [46]

    EBRAINS live papers–interactive resource sheets for computational studies in neuroscience

    Appukuttan S, Bologna LL, Schürmann F, Migliore M, Davison AP. EBRAINS live papers–interactive resource sheets for computational studies in neuroscience. Neuroinformatics. 2023;21(1):101–113

  39. [47]

    Enabling LivePublication

    Ellerm A, Adams B, Gahegan M, Trombach L. Enabling LivePublication. In: 18th International Conference on e-Science (e-Science); 2022. p. 419–420

  40. [48]

    NeuroCI: Continuous Integration of Neuroimaging Results Across Software Pipelines and Datasets

    Sanz-Robinson J, Jahanpour A, Phillips N, Glatard T, Poline JB. NeuroCI: Continuous Integration of Neuroimaging Results Across Software Pipelines and Datasets. In: 2022 IEEE 18th International Conference on e-Science (e-Science). IEEE; 2022. p. 105–116

  41. [49]

    Data and tools integration in the Canadian Open Neuroscience Platform

    Poline JB, Das S, Glatard T, Madjar C, Dickie EW, Lecours X, et al. Data and tools integration in the Canadian Open Neuroscience Platform. Scientific Data. 2023;10(1):189. September 22, 2025 21/22

  42. [50]

    Sage App Catalogue; 2024.https://portal.sagecontinuum.org/apps/explore

  43. [51]

    PegasusHub; 2024.https://pegasushub.io

  44. [52]

    HuggingFace; 2024.https://huggingface.co

  45. [53]

    Kaggle; 2024.https://www.kaggle.com

  46. [54]

    The OpenNeuro resource for sharing of neuroscience data

    Markiewicz CJ, Gorgolewski KJ, Feingold F, Blair R, Halchenko YO, Miller E, et al. The OpenNeuro resource for sharing of neuroscience data. Elife. 2021;10:e71774

  47. [55]

    The international Genome sample resource (IGSR): A worldwide collection of genome variation incorporating the 1000 Genomes Project data

    Clarke L, Fairley S, Zheng-Bradley X, Streeter I, Perry E, Lowy E, et al. The international Genome sample resource (IGSR): A worldwide collection of genome variation incorporating the 1000 Genomes Project data. Nucleic acids research. 2017;45(D1):D854–D859

  48. [56]

    Chicago Data Portal; 2024.https://data.cityofchicago.org/

  49. [57]

    FAIRly big: A framework for computationally reproducible processing of large-scale data

    Wagner AS, Waite LK, Wierzba M, Hoffstaedter F, Waite AQ, Poldrack B, et al. FAIRly big: A framework for computationally reproducible processing of large-scale data. Scientific Data. 2022;9(1):80

  50. [58]

    DataLad: Distributed system for joint management of code, data, and their relationship

    Halchenko Y, Meyer K, Poldrack B, Solanky D, Wagner A, Gors J, et al. DataLad: Distributed system for joint management of code, data, and their relationship. Journal of Open Source Software. 2021;6(63)

  51. [59]

    CBRAIN: a web-based, distributed computing platform for collaborative neuroimaging research

    Sherif T, Rioux P, Rousseau ME, Kassis N, Beck N, Adalat R, et al. CBRAIN: a web-based, distributed computing platform for collaborative neuroimaging research. Frontiers in neuroinformatics. 2014;8:54

  52. [60]

    Tapis: An API platform for reproducible, distributed computational research

    Stubbs J, Cardone R, Packard M, Jamthe A, Padhy S, Terry S, et al. Tapis: An API platform for reproducible, distributed computational research. In: Future of Information and Communication Conference, Volume 1. Springer; 2021. p. 878–900

  53. [61]

    Management and preservation of research data with iRODS

    Hedges M, Hasan A, Blanke T. Management and preservation of research data with iRODS. In: Proceedings of the ACM first workshop on CyberInfrastructure: information management in eScience; 2007. p. 17–22

  54. [62]

    Ripple: Home automation for research data management

    Chard R, Chard K, Alt J, Parkinson DY, Tuecke S, Foster I. Ripple: Home automation for research data management. In: 37th International Conference on Distributed Computing Systems Workshops. IEEE; 2017. p. 389–394. September 22, 2025 22/22

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.