Project ProtoStar: Making Public Science AI-Ready
See how Project ProtoStar aims to make publicly funded research reusable for AI, and what its first climate forecasting challenge asks participants to do.
Project ProtoStar Wants Public Science to Work Better With AI
Publicly funded research can be open to everyone - and still be frustratingly hard to use. Data often ends up in a static file, models come with thin documentation, and code is sometimes tucked away somewhere that doesn't really tell you how to run it (or even how to interpret it). The result is friction for researchers. It also makes it harder for AI systems to locate, understand, and combine scientific resources.
Project ProtoStar is trying to close that gap. The partners want to publish selected scientific datasets, models, and code in formats that are easier for people and machines to work with. Then they plan to test whether others can actually reuse those releases through a series of open challenges. The first challenge - hosted by Carnegie Mellon University - asks participants to forecast urban climate conditions using historical weather data from 210 U.S. cities.
The idea is simple. The work isn't. Publishing a file is just one step toward true reusability. This article lays out what ProtoStar is trying to change, how the challenges are structured, what the first challenge involves, and what research organizations and participants should think about before signing on.
What problem is Project ProtoStar trying to solve?
The U.S. federal government spends about $190 billion per year on research and development. Public-access policies from agencies like the National Institutes of Health (NIH) and the National Science Foundation (NSF) increasingly expect results to be shared - including publications and plans for sharing underlying data.
But public access and practical reuse don't always overlap. A dataset can be out there and technically "available" while still being hard to find, difficult to interpret, awkward to combine with other data, or not really usable in a new project. Researchers run into legacy formats, missing metadata, unclear licenses or provenance, and documentation that doesn't explain how the dataset was collected or what each field actually means.
These aren't just "housekeeping" issues. Without context, someone can misread a variable, use the dataset outside the population it covers, or fail to reproduce the original analysis. For machine-learning work, inconsistent formats and incomplete descriptions make it harder to build data pipelines that don't break (or quietly fail). AI-ready doesn't mean an AI system will understand every scientific artifact on its own - it means the artifact is published in a way that makes discovery, inspection, and reuse easier for both people and software.
Why publication alone does not create reuse
Scientific materials are often scattered across repositories built for different disciplines and purposes. A paper might point you to data in one place, code in another, and a model somewhere else. Even if each piece is open, the connections between them can be hard to reconstruct.
Reuse also depends on details that are easy to miss: what the data is, how it's structured, where it came from, what it can't do, and the terms for using it. When those details are missing, the burden shifts to the next person who wants to use the resource. And that cost ramps up when teams try to scale the workflow across lots of datasets.
Why the timing matters
There's already strong demand for scientific resources that are easy to plug into open infrastructure. Hugging Face reports hosting more than 17,000 public datasets across core areas like genomics, protein design, chemistry, weather and climate, Earth observation, and astronomy. The count comes close to 29,000 when medicine and mathematics are included, along with a similar number of scientific models.
The pace of sharing is also accelerating. Hugging Face Hub data shows researchers shared more than three times as many new science datasets in the first nine months of 2026 as they did in the same period of 2025. The pattern held even after excluding the largest single uploader.
Download numbers suggest value in making resources discoverable - though downloads aren't the same thing as scientific impact. As of October 26, 2026, 18 public repositories maintained by NIH's National Center for Biotechnology Information had collectively received more than 11 million downloads on Hugging Face. NASA IMPACT's 27 repositories had received about 770,000. Hugging Face also reports that 90% of dataset downloads come from fully documented datasets. That's a strong hint that documentation is part of usability, not an optional extra.
How will Project ProtoStar make research more reusable?
Project ProtoStar brings together universities, research organizations, industry, and the open science community. The stated goal is to support releases of scientific datasets, models, and code in AI-ready formats on open infrastructure - and to test the value of those releases through hands-on challenges.
The founding partners include Carnegie Mellon University, Purdue University, Georgia Institute of Technology, Arizona State University, and The George Washington University, working through the Open Forum for AI as the university coalition partner. The Astera Institute is also a founding partner. Hugging Face provides infrastructure, and the Open Research Community Accelerator participates as the community partner through its Fostering Innovation Network.
The operating model: publish, test, learn
Participating organizations agree to their involvement through a memorandum of understanding that supports the release of suitable scientific artifacts. The challenge series then turns some of those releases into real tasks. A host institution selects specific research materials, defines a challenge, and invites participants to build and submit work using them.
This approach matters because it tests more than whether a repository can store a file. It gives researchers and developers a clear reason to inspect the resource, understand its limits, and try to use it. The projects and feedback should show which parts of the publishing process work well - and where infrastructure or documentation still causes friction.
ProtoStar also builds on existing efforts, including the National Cancer Institute's AI Data-Readiness Challenge and guidance on preparing public-sector data for AI. It's not trying to claim that every research dataset can - or should - be turned into one universal format. The practical aim is to make suitable resources easier to use while still letting specialist repositories do what they do best for particular domains.
"AI-ready" is a means, not a quality label
The term shouldn't be treated as a guarantee that data is accurate, representative, ethically straightforward, or appropriate for every model. "Readiness" is about whether an artifact can be found and worked with. Scientific validity and responsible use still depend on domain expertise and judgment.
That distinction matters for organizations deciding what to release. Good release practices include clear documentation, preserving relevant provenance, and spelling out limitations. Teams also need to consider privacy and permissions, and think through whether releasing the data could create risks for people or communities reflected in it. Open infrastructure doesn't remove those responsibilities - it just makes the process more visible and more testable.
So ProtoStar's real value will depend on the quality of the artifacts and the feedback loop around them - not just the volume of uploads. A well-documented dataset with a clear use case can be more useful than a large collection of files nobody can interpret with confidence.
What does the first ProtoStar challenge involve?
The first challenge is the CMU Climate Risk Intelligence Challenge, hosted by Carnegie Mellon University from November 2 to 13, 2026. It asks whether participants can use historical weather data to improve predictions of urban climate conditions - and whether those predictions can support a practical adaptation idea.
Teams will work with climate records through 2018 for 210 U.S. cities. They'll predict observed conditions from 2019 through 2026, so their forecasts can be checked against actual weather records rather than a hypothetical future scenario. This setup gives the challenge a clear evaluation target, but it also doesn't mean that a historical forecasting result automatically turns into a complete picture of future climate risk.
Four indicators, with simple baselines
Participants will forecast four indicators relevant to urban planning:
- Average annual temperature
- Total annual precipitation
- The hottest day of the year
- Cooling degree days, a measure related to air-conditioning demand
Performance will be judged using a public leaderboard that compares prediction errors against established statistical baselines, including historical averages and linear trends. The goal here is straightforward: a more complex model isn't automatically better just because it's more sophisticated. It needs to beat a simpler reference on the defined measure.
The challenge also asks teams to propose a short climate adaptation policy idea informed by their analysis. Possible topics include preparing for extreme heat, improving energy efficiency, and managing changes in precipitation patterns. This policy component is assessed separately from forecasting performance, so the challenge doesn't mash scientific scoring and policy recommendations into one score.
What teams submit - and what the results can show
Teams will submit a Hugging Face dataset containing their outputs. Forecasting results will be evaluated against the baselines, and policy ideas will be considered separately. Final forecasting results are expected in early 2027, after complete 2026 weather records are available.
For participants, this is more than choosing a model. They'll need to understand the input data structure, handle differences between cities, generate forecasts for the required indicators, and clearly communicate what their analysis does - and doesn't - show. A strong submission makes its assumptions easy to find, rather than presenting predictions like they speak for themselves.
The challenge can indicate whether teams can reuse the released materials for a defined task. It can't, by itself, prove that AI is generally better than statistical methods for climate planning, or that a specific forecast is enough to guide a city's investment decisions. Those conclusions require broader evaluation, domain review, and attention to local context.
What can research organizations and participants learn?
For universities and research organizations, ProtoStar offers a practical way to test whether sharing policies actually lead to work people can use. Carnegie Mellon's Open Source Programs Office, for example, is encouraging researchers to share suitable datasets, AI models, and other research outputs on Hugging Face - while still recognizing that domain-specific repositories remain important.
That balance makes sense. A general-purpose platform can make resources easier to discover and reuse across communities. Specialist repositories may provide features and workflows that certain disciplines depend on. This isn't necessarily an either/or decision. Organizations need to decide which artifacts are suitable for broader distribution, where they should live, and how users should understand the relationships between related data, code, models, and publications.
A practical checklist for institutions
Before releasing a resource or joining a challenge series, an organization can ask:
- Can a new user understand it? Include a clear plain description, field-level context where needed, and information about how the data was produced.
- Can someone assess its limits? State known gaps, intended use, relevant caveats, and provenance. Don't imply the dataset covers more than it does.
- Can it be reused lawfully and responsibly? Review permissions, privacy requirements, and potential harms before publication.
- Can it be connected to related work? Make relationships among datasets, models, code, and research outputs clear enough that a user can follow the trail.
- Can the organization maintain the release? Decide who will handle corrections, updates, and questions after the initial publication.
This checklist isn't a substitute for institutional policy or domain-specific review. It's a way to reduce avoidable friction before someone else treats your artifact like a dependency.
A useful test for participants
Researchers, students, independent developers, and companies can treat a challenge as both a modeling exercise and a test of the underlying research infrastructure. When a resource is hard to use, note where things break down: unclear fields, missing context, awkward formats, or assumptions that never get documented. Even if a model doesn't land at the top of the leaderboard, those observations can still be valuable.
At the same time, participants should keep their claims aligned with the evaluation. A leaderboard measures performance against specific data and baselines. It doesn't automatically measure usefulness in every city, and it doesn't prove a result should drive policy. For this climate challenge, a forecast and a policy idea are different outputs with different standards for interpretation.
Key takeaways: ProtoStar is testing whether public research can be made easier to reuse - not arguing that AI replaces scientific judgment. The first challenge gives participants a specific climate forecasting task, baseline comparisons, and a separate policy component. Success will show up in whether the releases produce reusable work and practical lessons for the organizations behind them.
Conclusion
Project ProtoStar targets a gap that's easy to miss in open science: publishing research doesn't automatically make it usable. The approach pairs institutional commitments to release useful artifacts with challenges that test whether people can actually find, interpret, and build on what's been released.
The CMU climate challenge provides a concrete first test, with defined forecasting targets, statistical baselines, and a separate policy component. The results will matter - but so will the lessons learned about documentation, formats, and reuse in practice. For research organizations, the central question isn't how many files get published. It's whether another researcher can understand what you released, judge its limits, and build on it responsibly.