← Back to Essays

Scientific Discovery Pipelines as Governed Epistemic Systems

Published Apr 2026 synthesis Sandy Chaos Research Automation Scientific Workflow Epistemology Materials Science

Scientific Discovery Pipelines as Governed Epistemic Systems

One of the easiest mistakes in research automation is to confuse a pile of useful scripts with a real scientific workflow.

A script can be clever. A model can be accurate. A database can be large. None of that, by itself, guarantees that the path from evidence to claim is trustworthy.

What matters in serious scientific work is not only whether a system produces outputs, but whether those outputs remain intelligible under inspection. Where did the data come from? What was transformed, filtered, discarded, aligned, inferred, or assumed? Which parts are measured, which parts are cleaned, which parts are modeled, and which parts are still best understood as uncertain judgment calls?

That is why I increasingly think scientific discovery pipelines should be treated as governed epistemic systems, not just technical stacks.

This phrase sounds abstract at first, but the underlying idea is practical. A governed epistemic system is simply a workflow whose stages, handoffs, artifacts, and claims are organized so that a human can still trace what happened and decide what to trust.

Why this matters now

Research automation is becoming dramatically more capable. We can scrape and retrieve large document corpora, extract structured records from papers, align those records to reference databases, and train increasingly strong models on the result. In some areas, we can do all of this with a speed that would have seemed implausible only a few years ago.

The bottleneck is no longer just raw computation. It is increasingly the quality of the bridge between messy scientific reality and machine-usable representations.

Scientific papers are not written as clean datasets. Experimental records are incomplete, inconsistent, and shaped by local conventions. Labels drift. Units are mixed. Structures are missing. Entities that appear identical at one level of description split apart at another. Two rows that look compatible may in fact describe different states, phases, or preparation conditions.

If we want better models, we need better substrate. If we want better substrate, we need better workflow discipline.

That is where the larger architectural question enters.

What Sandy Chaos is really for

Sandy Chaos, in the broadest and least mystical sense, is not most interesting as a pile of ideas. It is most interesting as an attempt to formalize how a complex research workflow should remain legible while crossing multiple scales of abstraction.

Its value is not that it gives things dramatic names. Its value is that it keeps asking the right governance questions:

Those are not cosmetic questions. They are the difference between a system that merely produces outputs and a system that can support cumulative scientific judgment.

A concrete proving ground: ferroelectric materials research

This is where the ferroelectric materials workflow becomes important.

On the surface, it is a domain-specific pipeline: collect papers, extract ferroelectric property records, clean Curie temperature labels, align compositions to crystal structures, and train graph neural networks on the resulting dataset.

That is already useful. But the deeper significance is architectural.

This kind of pipeline is exactly the sort of workflow that reveals whether a research doctrine is real.

If a framework like Sandy Chaos cannot help govern a messy scientific pipeline of this kind, then it is probably too vague to matter. If it can help organize the stages, boundaries, and trust surfaces of this workflow, then it starts to become more than an aesthetic philosophy. It becomes an operating doctrine.

That is why I think the right relationship is not to force the ferroelectric project to become Sandy Chaos in name. The right move is to let the ferroelectric project serve as the first serious proof that Sandy Chaos can govern a real scientific discovery workflow.

What governance means in practice

In a workflow like this, the scientific work can be divided into a set of distinct but connected lanes.

1. Collection

A collection stage gathers papers, PDFs, metadata, and document artifacts.

This stage should answer questions like:

2. Extraction

An extraction stage turns unstructured documents into candidate records.

This stage should preserve:

3. Curation

A curation stage turns candidate rows into usable scientific labels.

This is where a great deal of invisible research labor often lives. Unit conversions, duplicate resolution, exclusion rules, plausibility windows, domain-specific edge cases, and the distinction between apparently similar but genuinely distinct records all belong here.

A good research system should not hide this stage. It should surface it.

4. Alignment

An alignment stage links curated records to the structural or relational substrate required by the model.

In materials science, this can mean matching composition-level records to crystal structures in a database like the Materials Project. The point is not only to find a match, but to understand ambiguity, failure modes, and what degree of structural confidence justifies downstream use.

5. Training

A training stage consumes a frozen dataset build, explicit model settings, and a defined split regime.

This stage should produce not just checkpoints and metrics, but a recoverable lineage: which dataset build, which code state, which configuration, and which evaluation procedure produced the reported result.

6. Analysis

An analysis stage turns run outputs into interpretable summaries.

This includes not only headline metrics, but error behavior, benchmark comparison, and signs that the whole system may be over-claiming what it has learned.

What matters here is not that these lanes exist in some perfect universal form. What matters is that they make the path from evidence to claim easier to inspect.

Why this is an epistemic problem, not merely a software problem

It would be easy to describe all of this as a data-engineering concern. That would be too narrow.

The real issue is epistemic. Scientific automation is not only moving bytes around. It is transforming the conditions under which claims become believable.

Every stage of a discovery pipeline changes the shape of the evidence.

A collection step decides what enters the world of possible inference. An extraction step decides what structure is legible enough to encode. A curation step decides what counts as usable signal rather than noise. An alignment step decides what can be joined and with what degree of confidence. A training step decides what optimization objective will stand in for learning. An analysis step decides what form of summary will be promoted as meaningful.

That entire chain is doing epistemic work.

If the chain is opaque, scientific confidence becomes fragile. If the chain is well-governed, confidence does not become certainty, but it becomes better grounded.

The point is not bureaucracy

There is an obvious danger here. The language of governance can drift into useless ceremony.

That would be a mistake.

The purpose of governance is not to add paperwork to research. It is to keep the system from becoming easier to admire than to audit.

A good doctrine should be lightweight where possible and strict where necessary. It should require artifacts rather than slogans. It should prefer local validation at stage boundaries over abstract claims of end-to-end reliability. It should not flatten domain-specific messiness into fake universal elegance.

In other words, the goal is not to eliminate ambiguity. The goal is to make ambiguity visible and manageable.

What should remain domain-specific

This matters just as much as the general architecture.

Not everything should be abstracted into a common doctrine. In the ferroelectric workflow, many of the most important scientific details remain domain-local:

If Sandy Chaos is useful, it should not erase these details. It should give them a better container.

That is the right division of labor:

A stronger way to describe the opportunity

The opportunity here is not simply to automate parts of science faster.

It is to build systems in which scientific knowledge formation becomes more inspectable, more reproducible, and more operationally sane.

That means workflows where:

If that sounds ambitious, it is. But it is also increasingly necessary.

The more powerful our extraction systems, retrieval systems, and models become, the easier it is to generate impressive-looking results whose trust basis is murky. That is not a reason to slow down into paralysis. It is a reason to build better doctrine around the acceleration.

A practical synthesis

The simplest useful synthesis I know right now is this:

Scientific discovery pipelines should be treated as governed epistemic systems, not just piles of scripts.

Under that framing:

One gives us scientific contact with reality. The other gives us a disciplined way to keep that contact from dissolving into confusion as the workflow grows.

That, to me, is the real promise of combining the two.

Not grandiosity. Not branding. Not a more ornate folder structure.

A better way to move from evidence to model, from model to claim, and from claim back to audit.

That is the kind of progress serious research automation should aim for.

Links

Source code repository for this project.

GitHub