A perfect model can't stop your self-driving lab from running a doomed synthesis. I built the gate that does.

I keep getting asked the same question by researchers who see what we build, and for a long time I answered it the way they wanted me to. "What is your sample-efficiency multiple?" How many fewer experiments does your loop need than brute-force screening? It is a fair question. It is also, I have come to believe, the wrong one to lead with, and I did not understand why until I sat and watched a simulated robot cheerfully commit to a recipe that would have oxidised in the air before it finished mixing.

I am Ashutosh, and I run Veriprajna. We build the brain, the safety gate, and the provenance layer for self-driving labs, on the hardware a lab already owns. Not a hosted robotic facility. Not a replacement for the instruments a materials group spent a decade buying. The thin, load-bearing layer of software that decides what to run next, refuses the experiments that are doomed, and keeps the kind of record a regulator asks for. This demo, which you can open and drive yourself at veriprajna.com/demos/autonomous-lab-ai, is where I went to prove to myself that the layer, not the model, is the product.

The number everyone asks me about is the wrong one

I spent the first month of this build chasing the multiple, because that is what the field rewards. The self-driving-lab conversation right now is a race for a better surrogate and a bigger Bayesian-optimization-versus-screening ratio. I get it. It is a clean, quotable number. On our own hidden objective, the closed loop reaches a spec-meeting material in 75 experiments where random screening would need about 1,491, which the dashboard reports as 19.9 times fewer. That is a real result on a real, reproducible baseline, and I am glad it is there.

But here is the thing that stopped me. A perfect surrogate, one that predicts every property flawlessly, still cannot stop a charge-imbalanced synthesis from running. It cannot refuse a composition that will oxidise on contact with humid air. It cannot produce a record a drug regulator will accept. And it cannot, by itself, close the loop. The model is the part everyone competes on, and it is the part that holds the least durable value, because the moment your model is good, your problem is no longer prediction. It is control, safety, and proof.

A better model does not make an autonomous lab trustworthy. It makes it faster at running experiments you still cannot prove you should have run.

Berkeley's A-Lab, one of the most cited autonomous synthesis efforts we have, reported a 71% success rate, which means roughly 29% of its attempts did not yield the target (A-Lab, Nature, 2023). Read that number the way a lab director reads it. Nearly a third of the robot-time and reagents went to experiments that produced nothing. A better acquisition function does not fix that. Something else has to.

What does a doomed experiment actually cost?

I built the gate second, and it turned out to be the thing I should have built first. It sits outside the agents, in deterministic code, and every candidate the optimizer proposes has to pass through it before a single reagent is touched. It runs five checks, and every one of them is published chemistry, not a heuristic I invented: Goldschmidt tolerance factor outside the perovskite formability window, octahedral factor outside the stable-octahedra window, charge neutrality violated by an uncompensated B-site substitution, a Sn(II) oxidation hazard at process humidity, and annealing above the temperature where the organic precursors decompose. If a candidate trips any of them, the gate returns BLOCKED, names the rule, and reports the money and robot-hours it just saved.

The first time I clicked into one of these blocked cards, I felt the argument settle. Look at what the panel shows. A composition heavy in Sn(II), at process humidity, that the digital twin refuses because tin in that oxidation state oxidises in humid air. It is not a bad prediction the model should have caught. It is a physical fact the model was never the right tool to enforce. The gate saved 105 dollars and a little over two robot-hours on that one candidate, and it wrote a receipt for the decision. Multiply that across a campaign and you are no longer talking about a nice-to-have. You are talking about the 29% leak, closed on purpose.

I want to be precise about what this is, because the honest framing matters more to me than the impressive one. The "lab" behind this gate is a simulator with a SiLA-2-shaped interface, and the objective is a physically-motivated synthetic benchmark, not real DFT and not real bench data. I am not claiming we synthesised a material. I am claiming the mechanism, the deterministic refusal of doomed chemistry, is real, inspectable, and independent of how good any model happens to be.

I tried to let the model police itself. It lied to me with a straight face.

I did not start out believing the gate had to be deterministic. My first instinct, honestly, was the fashionable one: let the language-model agents reason about feasibility. I had a Lab Director agent narrating strategy and a Critic agent flagging drift, and it seemed elegant to just ask them, in effect, "is this candidate safe and sensible?" So for an afternoon I let the model's judgment stand in for the check.

It rationalised a charge-imbalanced composition. Confidently. It gave me a fluent paragraph about why the B-site substitution was probably fine, and the paragraph was wrong, and nothing in its tone told me it was wrong. That was the afternoon the design principle stopped being a slogan and became a rule I would not bend.

Agents advise, code decides. In a self-driving lab that is not a limitation. It is the only way autonomy earns the right to run unattended.

So I moved the feasibility and safety decision permanently out of the agents and into deterministic code, and I made the optimizer independent of the language model too. The agents narrate and critique, and if you run the demo without an API key they fall back to deterministic narration and everything still works, because the gate and the optimizer never depend on the model at all. The optimizer itself is not exotic, and I would rather be honest than impressive about it: it is a Gaussian-process surrogate with a target-directed ParEGO acquisition, written in numpy and scipy. Mature method, deliberately un-flashy. The production swap is BoTorch and Ax. The point was never a clever optimizer. The point was that the part you trust with safety cannot be the part that speaks in confident paragraphs.

The scoreboard I actually care about

I look at this scoreboard differently now than I did when I started. Everyone's eye goes to the 19.9 times figure, and it is genuinely good. But the number I point to when a Head of R&D asks what we actually change is one over from it: 38 infeasible candidates blocked before synthesis, $4,419 of reagent waste and 90.1 robot-hours prevented, and zero doomed experiments executed. On the identical hidden objective, random screening did not just take longer. It would have burned through all of that.

The multiple gets less impressive as everyone's models improve. The waste the gate prevents, and the record it keeps, only get more valuable.

Notice what the loop did not do. It did not claim perfection. Across the multi-seed benchmark the closed loop solved 9 of 10 runs within budget, not 10 of 10, and the loop absorbs a 10 to 15% rate of injected robotic failures because real robots fail and pretending otherwise would make the demo a lie. One of the records in the audit trail is a synthesis that failed and was captured as negative data, because a self-driving lab that discards its failures is throwing away exactly the information that sharpens the boundary. I kept that visible on purpose.

And the multiple has a scope I will not let anyone strip off. The 75-versus-1,491 result, the 19.9 times, the $4,419, all of it is Bayesian optimization against baselines on one hidden synthetic objective. It is supporting evidence that the engine works. It is not an open-world guarantee, and if the loop had failed to beat the baselines, I would be reporting that instead. The value I lead with, waste prevented and provenance, holds at any model quality. The multiple is the part that depends on the benchmark, so it is the part I keep the caveat welded to.

Would a regulator believe your robot?

I did not expect the provenance layer to be the piece that convinced people, but it is the one that lands hardest with anyone who works under a regulator. The FDA and EMA's 2026 "Guiding Principles for AI in drug development" ask for provenance that is attributable and contemporaneous. In plain terms: for every automated decision, who or what made it, on what basis, at what moment, and can you prove the record has not been changed since. A better surrogate does not get you one inch closer to that. A record does.

A self-driving lab that cannot prove what it did last night is not autonomous. It is unaccountable, and no regulated lab will run it twice.

So every decision the system makes, both a synthesis and a block, becomes an append-only ALCOA+ record: a timestamp, the algorithm that chose, the predicted properties and their uncertainty, the rationale, the gate verdict, and the measured result. Each record carries a SHA-256 hash chained to the one before it. Across the seed-411 campaign that came to 113 records, 75 syntheses and 38 blocks, and you can export the whole thing as JSON and as a rendered report.

Here is where I have to be careful, and where I have watched other people overclaim. This is ALCOA+ provenance mapped, and it is not IQ/OQ/PQ-validated against a client's standard operating procedure. That validation is the engagement, it is not a checkbox I get to tick in a demo. What I can show you is that the property is real and inspectable, not decorative. So I built a Tamper test that edits one record and re-runs the chain check.

The first time I ran that test and watched it print "Chain broken at record #2: tamper detected. The filed audit is provably altered," I understood what I had actually built. Not a faster optimizer. A layer that lets a lab prove, after the fact, that its autonomous decisions are exactly what the record says they were. That is the thing you cannot buy with a better model, and it is the thing a regulator, an auditor, or your own future self will ask for.

What I think the self-driving-lab race is missing

I did not set out to argue against sample efficiency, and I want to be clear that I am not. Fewer experiments to a target is real value and our loop delivers it. What I came away believing, after building the whole thing and watching where my own trust actually lived, is that the field has fixed on the one number that gets less durable as the technology matures. When every group has a good surrogate, the multiple stops being a differentiator. The gate that refuses doomed chemistry, and the record that proves what ran, only get more valuable, because they are the parts autonomy needs before anyone will let it run unattended.

So the contrarian move, the one I would stake the company on, is to put the feasibility and safety decision in deterministic code, outside the agents, and to treat every automated decision as something you must be able to prove later. Not because models are bad. Because the questions that decide whether a self-driving lab is allowed to run overnight are not prediction questions. They are safety questions and provenance questions, and those want code and hashes, not confident paragraphs.

You can open the loop, block a doomed synthesis, break the audit chain yourself, and see whether you agree, at veriprajna.com/demos/autonomous-lab-ai.

And if you would rather see it than read me describe it, here is the whole thing running end to end.

The question I keep turning over, and the one I would genuinely like an answer to from anyone running real automation: if your lab ran a thousand experiments unattended tonight, which of those two things would you reach for in the morning, a better model, or a record you could prove?