Model Hardware Standard: What Is It? Seriously, That's What I'm Asking.

Anthropic, the company behind Claude, announced a new initiative called the Model Hardware Standard (MHS).  It's a way to enable intelligent agents to talk to laboratory instrumentation - well, that's what it's billed as.  But as first surfaced in a tweet by Sina Booeshaghi, if they want to be a standard they're taking a counterproductive path to it, as the announcement was only that.  A blogpost extolling the goals of MHS is given accompanied by testimonials from two early access sites , but no open and substantive description of MHS itself that would allow evaluating what it can and cannot do.  

Getting computer programs to talk to laboratory hardware is a decidedly non-trivial task, and we can't reasonably expect any one bit of software to cover everything. A common hierarchical division is into the following layers: device drivers, orchestration, scheduling, and experiment planning - but as with many human attempts to label a complex process one can easily have different divisions or at least subdivisions of those categories. 

Device drivers are the lowest level, the primitive commands to operate a device.  If we want to control an automation-friendly qPCR thermocycler, some basics would be "open drawer", "close drawer", "run program". 

Orchestration is going to control multiple steps on the same device or multiple devices.  For example, a complete thermocycling plan would be to "open drawer", "close drawer", "run program", "open drawer", "close drawer" - the two pairs of drawer operations are to load and unload a plate.  An orchestration package might tie those into other operations, such as the robotic arm to place the plate on the drawer and to remove the plate at the end.  

Schedulers are planning all those operations in time.  In an automated workcell, I might wish to prepare the next PCR reaction on the liquid handler while the current one is processing on the thermocycler - working all that out into a series of orchestrations is the job of the scheduler.  You certainly don't want to open the drawer for one plate when the other is still cycling!

Experiment planners are getting to the highest levels of thinking.  They're going to translate experimental intent to a protocol to feed to the scheduler.  

Each of those layers will have expectations of the layer below.  Some labs may not be building all the layers - maybe I use the device drivers to run a device from my phone but nothing more.  

MHS appears to be a proposed solution above device drivers but perhaps allowing intelligent agents to handle their own orchestration and above.  

The Anthropic blogpost mentions a bunch of partners and invites expressions of interest - but this is definitely inferior to simply releasing the current MHS spec.  Ideally a very large community of scientists - and their agents - would be able to review the standard and give constructive criticism.

I've recently been dabbling the problem of device driver writing in the context of our Catalyst environment which provides experiment planning, scheduling, and orchestration.  The biggest bottleneck to getting a new piece of hardware into our ecosystem is to having the appropriate device driver written.  Once those are written, attention can then be paid to building  "recipes" which form building blocks for larger orchestrations. 

So I've been pointing our Catalyst agent at the API documentation for a handful of automation devices and asking the agent to assess them.  The agent writes a pair of reports - one I can share with the device maker and a slightly more expansive one for internal use.  

I'll write soon a more extensive post on what this finds, but one pattern is that some of its suggestions could be reasonably said to be of universal interest, whereas others might be unimportant for many but very important for us.  In particular, for scheduling we must have estimates for how long a given action will take, but if you were just trying to have a link between your personal computer and a device that might not be critical.  It's unclear from the descriptions of MHS whether that sort of timing information is part of the standard. When I do get a copy of the MHS spec, I'll try my agent approach on it.

There have been prior attempts to standardize computer-instrument interfaces.  SILA2 is one such standard, with a strong information technology bent.  So SILA2 says "this requires HTTP2 as the transport layer".  It will be interesting once the MHS standard is available to compare it to SILA2 - a comparison which will be of particular interest to instrument makers who have built SILA2-compliant APIs to their instruments.

That points to a key downside to Anthropic's gatekeeping approach to MHS.  Ideally, a standard would be embraced by the instrument makers and they would start writing the necessary bits for MHS compatibility.  A truly open standard would encourage that - and encourage many hardware innovators to build their fit to the standard as they build their instrument.  If the MHS compatibility suites in turn were also open, then it would be possible to compare different MHS implementations for similar instruments.

Another question I don't see answered in the blogpost is to what degree the MHS standard will cover the issue of labware compatibility.  The compatibility of labware with instruments is very important - put the wrong type of plate in your thermocycler and you may meld the two together.  Deepwell plates can't go in shallow slots (I might know someone who tried to do that recently).  Acoustic transfer systems such as the Echo have one set of restrictions for source plates, a different one for destination plates.  Then there's other sorts of more subtle information such as aspiration heights, dead volumes, and well geometries  - but that could be itself a very long post.

A number of the frontier AI companies have been making noises about getting into working with laboratories.  I definitely welcome this - after all, we build laboratories intended for that purpose.  I wonder if the MHS announcement will trigger competing proposals from any of the other companies.   I'll probably get to see MHS specifications and examples soon, but I still think a fully open standard is a far better approach than releasing a teaser and then having a long line develop to get a full peek.