The Anthropic research preview: what is public, what it describes, and how this specification relates

OpenMHS is an independent open-source project, not affiliated with or endorsed by Anthropic, and not a reimplementation or compatible dialect of Anthropic's MHS research preview.

This appendix summarises the public description of Anthropic's Model Hardware Standard (MHS) research preview and states precisely how this document set relates to it. It is informative: it creates no conformance obligation. The quotations of Anthropic material in this appendix are short citations for commentary and comparison; they remain the property of their owners and are not licensed by this project (LICENSE-docs). 00-architecture.md §1.4 repeats the relationship in the overview.

1. Status and publication boundary

Anthropic describes MHS as "a shared specification for AI agents to safely operate physical devices" and opened it as a research preview to selected labs and manufacturers in August 2026, "ahead of making the standard open source"[A]. Access is "by application during the preview"[L]. The standard is model-agnostic and "any agent harness can access it using standard protocols, such as the Model Context Protocol"[A].

Verified from the public sources: no wire format, manifest schema, message set, reference SDK, MCP tool naming, receipt/evidence format, error taxonomy, conformance levels, simulation story, versioning policy, licence, governance or open-source date has been published. Partner write-ups add detail but are descriptions of deployments, not specifications. Accordingly, OpenMHS 0.9 is an independent open specification, not a reimplementation or a compatible dialect of the preview.

2. How the preview describes MHS

The announcement describes a standardized driver: "software that translates between a computer's operating system and a hardware device", using "a simple set of primitives — commands like 'read' … or 'write'"[A]. Devices are "discoverable in a standard format, so that devices and agents can find each other and communicate across networks without needing a bespoke 'translator' program"[A].

Each driver carries natural-language tags. Users write them directly, or "by chatting to an agent that interviews them about their hardware setup". "With the information from these tags, the MHS driver then automatically produces a reference file with information about a device's general characteristics, such as what it can measure, what can be adjusted, and what safety limits will be enforced"[A]. The stated purpose is to make tacit physical knowledge — e.g. the weight of a robot arm — machine-readable.

Control is provided through three mechanisms: "MCP, the command line interface, and code files (APIs). These work together to enable orchestration across multiple devices via a single line of code"[A]. For long-running work the agent "can chain together driver commands from one or more devices in code files", so devices can run without the model reasoning at every step[A]. In the documented behaviour, an agent explores a device, then packages what it learned into a deterministic script so later runs need no per-step reasoning[A][B].

The origin is a collaboration between Alek Kemeny (Anthropic Beneficial Deployments) and Arco Bast (HHMI Janelia). For his multiphoton imaging rig, Bast "developed a shared memory dictionary that enabled the instruments to communicate with one another at memory speed"[A]. The short film describes devices communicating "at bare metal speed"[A-video]. The public sources do not state how that shared-memory substrate relates to the announced network-wide discovery and standard driver.

3. Safety: assertions, evidence and limits

The strongest written safety statement comes from QuEra: MHS "enforces device-declared bounds, interlocks, and emergency stops at the hardware interface, independent of the model"[Q]. The CMU case study reports pre-move blocking after "six different conditions" were artificially induced, including an active emergency stop[A]. The documentary shows an operator defining a robotic arm's "safe range" and an out-of-range command being "refused by MHS"[B-video].

Where the enforcement code lives, how interlocks are represented, whether e-stop is latching, and how code files are sandboxed are not stated. Anthropic states that safety evaluations are still being built and that a "physical safety roadmap" will follow[A]; Genentech reports that bubble-induced pipetting failures required human guidance because the model first treated them as software retries[A]. Expert oversight remains required.

4. Early ecosystem (as claimed, with modality)

5. What this specification adopts, defines, and rejects

Status vocabulary, for the OpenMHS column below: implemented means present in the 0.9 SDK and exercised by its tests; specified means described by this document set but not (fully) implemented by the SDK; planned means neither, and scheduled after the pilot of the driver handoff kit.

Adopted framing. The integration-cost argument; physical knowledge as machine-readable metadata; user-authored tags; a generated, model-readable reference view of each device; the three control mechanisms; and chaining commands into code files for long-running work.

Defined beyond the published description. These are choices of this specification, not claims about the preview's internals.

Deliberately rejected as normative mechanisms. A free-form writable global state dictionary (least privilege and auditability); a shared-memory bus as the core transport (MHS is supervisory, not a real-time bus); auto-published model-authored drivers (a model-authored hardware driver at R2 or above cannot start its hardware backend until a human has signed reviewed_by); model-side safety-evaluation claims.

6. Claims that must not be made

Given the publication boundary, no OpenMHS artefact may claim: compatibility with or endorsement by Anthropic/the preview; that it implements the preview's wire format; that it has received preview access; that MHS conformance equals a safety evaluation or certification; that the preview's described enforcement is verified; that any vendor listed above supports this specification; that simulation fidelity is validated by the preview; or that "memory-speed"/"bare metal speed" is an MHS guarantee.

7. Sources and verification status

Video-derived statements above are labelled [A-video]/[B-video]; visual-only claims (e.g. a 3-D safe-range viewer) are not asserted here. The detailed source notes, per-claim quotes and the gap analysis against this specification are kept with the project's private research material.

Video identity note: the short film is UxJZrCFzTHY; the documentary with the robot-arm safe-range demonstration, Leica microscope session, diatom tracking and Genentech liquid-handling loop is P1zBiAQU1IA.