OpenMHS 0.9 · Development draft 0.9 · not affiliated with Anthropic

An open contract between agents and equipment.

OpenMHS is an independent, open draft contract between AI agents and physical equipment — discovery, typed capabilities, an endpoint-enforced safety envelope and an evidence trail for instruments, robots, and the simulations that stand in for them.

2,967 packages indexed63 capability classesCL0–CL5 conformance

one call · one receiptsimulated

# request

mhs.command {
  "capability_id": "cap.fluid.transfer.v1",
  "input": {
    "source": "plate:A1",
    "target": "plate:B3",
    "volume": { "value": 50, "unit": "uL" }
  },
  "command_id": "01J8ZQ3V6X…"
}

# receipt

{
  "status": "completed",
  "state_revision_after": 43,
  "state_hash_after": "sha256:9f2c…",
  "effects": ["material.transfer"],
  "evidence": { "seq": 812, "digest": "sha256:4a1e…" }
}
endpoint mhs://lab-01:7331not a safety certificate

The same request shape moves a pipette, a robot joint or a simulated world. Mode and fidelity are declared, never inferred.

2,967packages indexed
explore the registry
63core capability classes
browse the catalogue
37bridge families
read the recipes
CL0–CL5executable conformance
the ladder

Device market

746 devices, one command each.

Every OpenMHS driver package that passed its gate: 299 hardware drivers served on their fake backends and 447 simulations, from oscilloscopes and liquid handlers to robot arms and UAV simulators. Each comes with an introduction and a copy-paste install command.

contract_checked on the fake backend, not a hardware qualification. Real hardware stays an explicit operator decision.

Try it in two commands

shell
git clone --depth 1 https://github.com/PKU-YuanGroup/OpenMHS.git && cd OpenMHS
PYTHONPATH=MHS/sdk/src python3 -m mhs serve labs/tiagocoutinho__julabo --port 7400

That serves a JULABO circulator on its fake backend at http://127.0.0.1:7400. Inspect it from a second terminal with PYTHONPATH=MHS/sdk/src python3 -m mhs describe --endpoint http://127.0.0.1:7400, or install any device into the OpenAI4S workbench with openai4s lab add <id>.

Why OpenMHS

Three failures the standard has to fix

Every lab and robotics stack has the same integration story: a bespoke translator, safety knowledge in a PDF, and simulators that share nothing with the machines they model. OpenMHS makes the contract explicit.

01

Integration is bespoke

Every instrument ships its own SDK, transport and vocabulary. Twelve instruments mean twelve translators that do not compose.

OpenMHS: one JSON-RPC contract, declarative adapters, and reusable bridge families. The cost of support is a manifest and a thin shim, not a new driver.

Adapters and bridges
02

Agents cannot know what is safe

A model can read a docstring and still not know that 500 mW will destroy a laser, that the door interlock is open, or that the arm already holds a plate.

OpenMHS: limits, hazards, interlocks and permits travel in-band, and the endpoint evaluates them before any physical effect — not the model.

The safety envelope
03

Simulation and hardware are separate universes

Most agent development happens in simulators, but drivers describe real devices. Two standards would double the work; treating them as identical would get someone hurt.

OpenMHS: one object model, one wire protocol, two declared worlds. Mode and a fidelity contract make the difference machine-readable.

Modes and fidelity

The contract plane

Three surfaces, one contract

OpenMHS standardises what a device is, what it will do, and what happened. Each surface is machine-checkable; none of them lives in prose or in the agent's prompt.

Read the conceptual model

01 · Discover

Declare the device and its capabilities

An endpoint publishes a device manifest: resources, bound capability classes, units, modes, safety declaration, fidelity contract. Schemas are addressable and versioned separately from the wire protocol.

  • Endpoint discovery via .well-known/mhs.json or explicit configuration
  • 63 typed capability classes with input and output schemas
  • UCUM units at the boundary; ambiguous fields are schema errors

02 · Govern

Refuse before the device moves

The endpoint checks the session, grant, schema, limits, interlocks, permits, revision and lease — in that order, fail-closed, before any effect. Violations are receipts, not exceptions.

  • Risk classes R0–R3 and per-capability limits
  • Hardware e-stop required independently of OpenMHS
  • Gated capabilities need a scoped, single-use permit

03 · Account

Make the physical outcome reviewable

Every command has a caller-generated id, an input digest and a retained receipt: status, revision, state hash, effects, errors and the native code. Receipts chain into tamper-evident evidence.

  • Idempotent replay by command_id; reuse with different input fails closed
  • Unknown outcomes are first-class, never inferred
  • Offline-verifiable sha256 evidence chain

Capabilities, not drivers

Stop asking what a device is. Ask what it can do.

Device categories do not compose. A “plate reader” and a “microscope” share no useful interface until their actions are described in the same typed vocabulary.

OpenMHS describes a device as a set of capability classes bound to resources: cap.sensing.image.v1, cap.motion.joint_position.v1, cap.fluid.transfer.v1. Each binding carries units, limits, effects, hazards, determinism and risk. The driver becomes an implementation detail behind the binding, not the interface an agent has to learn.

Simulation and hardware

One contract. Two declared worlds.

OpenMHS is designed for the people who develop in simulation and deploy on equipment. The contract is identical; the truth claim is not.

The differences are declared, not discovered

Mode is not a trust flag. A session requests the device's declared mode; a mismatch is rejected. Switching from simulation to hardware is a different endpoint and device instance, never a flag flipped on a live session.

Fidelity is a contract. A simulator states its engine, fidelity level, timestep, determinism, replay support, validation record and — when non-empty — its gaps. Hiding a gap is a conformance failure.

ModeTruthMutations
hardwarethe machineyes
simulatedthe modelin the model
hybriddeclared per resourcewith authority
replaythe recordingread-only
F0 analyticF1 rigid bodyF2 sensor & actuatorF3 validated
Read the fidelity contract

Conformance

A claim is a level, not a logo.

A conformance claim names a profile and a level, and points to a machine-readable report that a third party can recompute. Prose claims are not conformance.

The suite includes negative tests: interlock open, revision conflict, duplicate command id, deadline exceeded, cancellation, mode mismatch. A skipped test is not a passed test.

  1. CL0DeclaredManifests validate against the OpenMHS schemas. No runtime.Static
  2. CL1ObservableTransport, discovery, reads and subscriptions with stable revisions.Read
  3. CL2ActuatingSessions, idempotent commands, receipts, cancellation, deadlines.Act
  4. CL3GovernedEnvelope enforcement, risk classes, permits, e-stop and reset.Govern
  5. CL4ReproducibleEvidence export and verification; deterministic replay for simulators.Prove
  6. CL5OrchestratedCompositions, multi-device sessions, gap semantics, published claim.Orchestrate

Adoption

Coverage, stated honestly.

Every indexed package states its ring, evidence state and next action. No repository is silently marked supported, and no claim is made about whether it runs.

Browse agent-read packages
Ring 0Reference endpoints, runtime-verified
0A handful of endpoints we can execute locally to prove the protocol end to end.
Ring 1Adapter manifests with code-level evidence
746Agent-read source, precise entry points, mapping sketch and safety profile.
Ring 2Declarative manifests from static analysis
0Bounded scans produce a manifest skeleton, family recipe, tier, blockers and next action.
Ring 3Family recipes and bridge code
2,221One recipe per family showing how any package in it becomes an OpenMHS endpoint.

Status

A complete draft, with the gaps labelled

This site is the public face of a standard under review. The specification, schemas and registry are real artefacts; the SDK, recipes and conformance suite are being built in the open. We would rather label a gap than paper over it.

Published

  • 18 specification documents in draft (18 mapped)
  • 63 machine-readable capability classes
  • 2,967 registry records from a 2,967-row catalogue
  • Eight JSON Schemas and two worked examples
  • 37 bridge-family recipe pages
  • Reference SDK source: 132 modules, 253 test files
  • 3 self-issued reference conformance reports (CL2–CL4)

In progress

  • Release packaging and independent verification for the reference SDK
  • Bridge implementations exercised against physical hardware
  • Registry evidence beyond bounded static scans

Not claimed

  • Safety certification or regulatory approval
  • Runtime-tested status for registry packages
  • Verified conformance claims by a third party
  • Fidelity validation for simulated devices

Get started

Implement the contract, or inspect it first.

Read the core, validate a manifest, connect the SDK, or explore what already exists in the registry.