In September 1999 the Mars Climate Orbiter burned up in the Martian atmosphere because one team supplied thruster impulse in pound-force seconds and the receiving software expected newton-seconds. No model was involved. No algorithm failed. A unit label was missing from a data interface, and $327 million of hardware became debris.
Every AI-for-science project sits on that same interface. The difference is that a model will not burn up. It will produce a clean, confident, entirely wrong prediction, and it will do so faster than a graduate student could produce a wrong prediction by hand.
That is the context for reading NSF's $83 million investment in integrated data systems and services, announced in July 2026. The number is not the story. The allocation is. A federal science agency with every incentive to fund headline-grabbing model work put its money into pipelines, provenance, and access layers instead.
What NSF Actually Bought
The Integrated Data Systems and Services awards fund the layer between an instrument and a trainable dataset. The National Data Platform's Category I award at UC San Diego is representative: the work is federated access, standardized metadata, and making distributed research datasets usable without a bespoke integration project per lab.
Notice what is absent. No new foundation model for chemistry. No GPU cluster branded as a scientific supercomputer. The compute side of the house is being handled through separate programs - the state and regional AI infrastructure hub solicitations run on a different track.
That separation is deliberate, and it reflects an accurate read of where scarcity actually lives. A materials scientist at a mid-tier research university can call a frontier model through an API this afternoon for the cost of a lunch. What that same scientist cannot do is get twenty years of synthesis results out of a shared drive, into consistent units, with enough provenance attached that a reviewer would accept a model trained on it.
Compute is a commodity with a price. Curated scientific data is a capital asset that takes a decade to accumulate and thirty seconds of careless export to destroy.
The Rate Limiter Is Instrument-to-Dataset Plumbing
Ten years ago a Google team published a NeurIPS paper called Hidden Technical Debt in Machine Learning Systems with a diagram that has aged better than most things in machine learning. The box labeled "ML code" is a small rectangle surrounded by much larger boxes: data collection, feature extraction, verification, configuration, serving infrastructure, monitoring.
Science has the same diagram with one extra box on the left, and it is the hardest one. Between the physical instrument and the first byte of digital data sits an analog-to-digital process with its own state: calibration date, ambient conditions, operator, consumable lot number, firmware version. Web companies do not have this problem because their instrument is a web server that emits structured logs. A mass spectrometer emits a vendor binary format that changes between software releases.
Here is the failure sequence we see repeatedly in industrial R&D:
- An instrument writes a proprietary file. Someone exports to CSV, dropping the header block that contained calibration metadata.
- The CSV goes into a shared drive with a filename encoding the date and the operator's initials. That filename is now the only provenance record.
- Six months later the instrument is recalibrated. Nothing in the file system marks the boundary.
- A data scientist concatenates three years of these files into a training set.
- The model learns the calibration shift as a physical signal.
Nobody in that sequence did anything unreasonable. Each step is locally sensible. The result is a model that has confidently learned an artifact of equipment maintenance and will generalize it to every prediction it makes.
The FAIR data principles, published in Scientific Data in 2016, were written for human reuse of research data, but they map cleanly onto this failure. Interoperable means units and schemas resolve without a human interpreting a filename. Reusable means the calibration boundary is in the record, not in someone's memory. The principles predate the current AI cycle by seven years and describe exactly what the current cycle needs.
The Data You Throw Away Is the Data You Need
The most useful demonstration of this point is a decade old. In 2016 a team at Haverford College published work on machine-learning-assisted materials discovery using failed experiments. They pulled 3,955 failed and partially successful hydrothermal synthesis reactions out of archived paper lab notebooks - reactions that had never been published because they did not work - and trained a model on them. The model predicted successful reaction conditions for new compounds at roughly 89 percent success, against about 78 percent for trained human intuition.
The signal was in the failures. It had been sitting in notebooks for years, and it was invisible to any model trained on the published literature, because the literature is a systematically censored dataset. Journals publish successes. A model trained on papers learns what worked and has no representation of the far larger space of what did not.
This is the single highest-leverage change most R&D organizations can make, and it costs nothing in compute. Capture negative results with the same rigor as positive ones. Give a failed run the same schema, the same provenance fields, and the same storage path as a successful one. Most organizations have an ELN or LIMS that technically supports this and a culture that quietly does not.
The same pattern shows up in closed-loop autonomous labs, where the system's own failed attempts become training signal for the next round - we walked through the mechanics of that feedback loop in AI materials discovery and the closed-loop lab. The lesson generalizes past materials. Failed drug candidates, out-of-spec manufacturing batches, and rejected process parameters are all high-information negative examples that most companies delete on a retention schedule.
What "AI-Ready" Actually Means
"AI-ready data" has become a phrase vendors put on slides. Here is a concrete definition you can test against.
The five-question readiness check. For any dataset, answer these from metadata alone, without asking a colleague:
| Question | What a passing answer looks like |
|---|---|
| Which instrument produced this? | A resolvable identifier, including serial and firmware version |
| What calibration state was active? | A timestamped calibration record linked to the run |
| What are the units of every column? | Machine-readable unit annotations, not a header string |
| Which version is this? | A content hash or immutable version ID that changes when bytes change |
| Who is accountable for it? | A named steward, not a team alias |
If you need a person for any row, the dataset is not AI-ready, and no model selection will change that. We have watched teams spend two quarters evaluating architectures against a dataset that failed question three.
Two practices make these answers cheap to produce rather than expensive to retrofit.
Write a datasheet for every dataset. Timnit Gebru and co-authors proposed Datasheets for Datasets as a standard disclosure document: how the data was collected, who collected it, what preprocessing was applied, what it should not be used for. In a research setting this is a half-page document per dataset, and it is the difference between a reviewer accepting your model and a reviewer asking a question nobody can answer.
Use a machine-readable metadata format. MLCommons' Croissant format encodes dataset structure and semantics in a way that loaders can consume directly. It is not a scientific standard, but adopting any machine-readable descriptor beats the current default of a README written in 2021.
Do not build the transport layer. Globus has solved authenticated bulk transfer between institutions. Rucio, built for the ATLAS experiment at CERN, manages replication and lifecycle across hundreds of petabytes distributed over dozens of sites, and it is open source. Physics solved the exabyte data management problem while the rest of us were arguing about data lakes. The custom work in your organization is narrow: instrument adapters and domain schema. Everything else is a procurement decision.
Why This Matters Outside a Grant Application
The reproducibility problem is not academic. A 2016 Nature survey of 1,576 researchers found that more than 70 percent had tried and failed to reproduce another scientist's experiments, and more than half had failed to reproduce their own. Adding a model to an unversioned dataset does not improve those numbers. It multiplies the throughput of unreproducible results.
For an industrial R&D team, the business consequence is specific. When a model recommends a formulation, a process parameter, or a candidate molecule, someone has to decide whether to spend real money acting on it. That decision requires knowing what the model was trained on. If the training set is a concatenation of exports with no version identity, the honest answer to "what did it learn from?" is "we are not certain," and the recommendation gets discounted to zero by anyone with budget authority. The model works. The organization cannot act on it.
This is the same failure we documented in commercial systems, where duplicate and conflicting records quietly corrupt agent behavior - see duplicate data breaks AI agents. Scientific data has the identical pathology with higher stakes and worse tooling.
The ordering that works is unglamorous:
- Instrument adapters that preserve native metadata rather than exporting to CSV
- Unit normalization at ingestion, with the original units retained
- Immutable, content-addressed dataset versions
- Negative and failed results stored under the same schema as successes
- A named steward per dataset with actual authority to reject a submission
- Only then, a model
Every team wants to start at step six. The teams that ship start at step one, and they finish faster.
How OpenNash Can Help
Most of the scientific AI work we get called into arrives framed as a modeling problem and turns out to be a plumbing problem. The audit is the same shape every time: trace one high-value prediction backward to the physical instrument that produced its training data and mark every point where provenance breaks. That exercise usually takes two weeks and reorders the roadmap.
From there the build is narrow. Instrument adapters and unit normalization at ingestion. Content-addressed versioning so a training run can be reproduced from an identifier. Capture paths for negative results. Human approval gates at the point where a model recommendation triggers physical work, because in a lab an unreviewed action costs reagents and calendar time, not just a bad API call. The general version of this groundwork applies to any agent system - we covered it in data and context engineering for AI agents.
We are not the right answer for everyone. If your data already lives in a well-governed platform with provenance and versioning, hire a domain modeler, not us. If you are a small lab with one instrument type, a graduate student and a disciplined naming convention will get you most of the way. If you are running a multi-site R&D organization with a decade of accumulated instrument output and a mandate to make it useful, that is the problem we build for, and the systems ship with full documentation and client ownership.
Book a call to map this to your workflow.
Pick your most valuable dataset this week. Try to answer the five readiness questions from metadata alone. Whatever you cannot answer is your actual AI roadmap, and it is probably shorter than the one currently on the slide.