About the project
A contract for the part between reasoning and matter.
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.
OpenMHS exists because the integration layer for physical AI is rebuilt by every lab, every vendor and every agent harness — and because the safety and evidence semantics that make that layer trustworthy are usually left out.
Mission
Make equipment legible to agents, and agents accountable to equipment
OpenMHS is an open, versioned, machine-checkable contract between agents that reason and equipment that acts. It lets an AI agent — or a plain Python program — discover a device it has never seen, understand what that device can do and what those actions mean physically, execute under an enforced safety envelope, and obtain verifiable evidence of what actually happened.
It is model-agnostic and harness-agnostic. It does not assume a particular agent loop, a particular model vendor or MCP. It composes with MCP rather than competing with it: MCP standardises how a model reaches tools; OpenMHS standardises what a tool that moves matter means.
For driver and bridge authors
A target to write against once, instead of a bespoke API per host. The adapter manifest is small; the bridge is reusable across a family.
For instrument vendors
A way to describe capabilities, units, limits and provenance without ceding control of the driver or the device.
For labs and integrators
A registry of what exists, what evidence backs it, and what the next concrete step is — with the gaps left visible.
For agent-harness authors
One client path, one safety model, one evidence format for every physical tool in the loop.
Design
The axioms that decide arguments
When two designs are both plausible, these are the tie-breakers. They are normative context for every other document.
One model for simulation and hardware
The same client, contract and capability vocabulary; mode and fidelity carry the difference.
Capabilities, not device types
A device is a bag of typed capabilities bound to resources, not a vendor category.
Fail closed
A component that cannot be evaluated is a rejection, never an assumption of safety.
Fidelity is declared
A model states what it models, what it does not, and how it was validated.
Wrap, do not rewrite
Existing SDKs join through declarative adapters and generic bridges.
Conformance is executable
A level is backed by a report a third party can recompute.
Adoption rings
Four rings, and a separate evidence label
The ring says how far a record has progressed through the adoption plan; evidence says how the record was produced. They are independent, and both are shown on every record. Neither is a quality score, a support commitment or a conformance level.
Runtime-verified
0 records. A person or agent executed the endpoint locally and captured a report. This is the only ring that can support a runtime claim.
adoption ring 0Agent-read source
746 records. The actual source was read and a precise entry point, mapping and safety profile were recorded. Still a declared manifest, not an execution.
adoption ring 1Static analysis
0 records. Catalog fields plus bounded scans produced a manifest skeleton, family recipe and next action.
adoption ring 2Family recipe only
2,221 records. The package is mapped to a bridge family and a recipe; individual records may still carry static-scan or agent-read evidence, and the explorer shows which.
adoption ring 3Ring and evidence are different axes: a ring-3 record can be agent-read, and a ring-1 record is not automatically conformant. Both labels are shown side by side in the registry explorer; neither implies conformance. Read the model in MHS-000 §13.
Status
Exactly where this build stands
The site is generated from the source tree; this table reflects the files present when it was built. It is a snapshot, not a roadmap promise.
| Artefact | State in this build | Claim |
|---|---|---|
| Specification | 18 of 18 mapped documents published | Development draft 0.9 |
| JSON Schemas | 60 schema files, plus worked examples | Published |
| Capability catalogue | 63 classes across 14 domains | Published |
| Registry | 2,967 records, 0 manifests detected | Static snapshot |
| Reference SDK | 132 source modules, 253 test files, 26 guides; no release package claimed | Reference source |
| Conformance suite | 11 suite modules; 3 self-issued reports (CL2–CL4) | Reference evidence |
| Family recipes | 37 of 37 published | Published |
| Runtime-tested packages | 0 registry claims | Not claimed |
| Safety certification | OpenMHS is not a safety-rated channel | Not claimed |
Disclaimers
What the standard deliberately leaves to others
Safety and regulation
OpenMHS does not provide safety certification, risk assessment, clinical validation or regulatory approval. It is a software interlock layer, not a safety instrumented function.
Fidelity and experiment validity
A simulator can be conformant and still be wrong for a particular experiment. Fidelity levels are ordinal claims qualified by declared gaps, not guarantees.
Registry accuracy
Records are assembled from a catalogue and bounded scans. Fields can be wrong, incomplete or stale. Evidence state is displayed precisely so you can judge it.
Real-time control
OpenMHS is a supervisory contract. It does not replace EtherCAT, CAN, ROS control or vendor real-time APIs underneath a bridge.
Colophon
How this site is made
Static by construction. The site is generated by a Python standard-library build script. No npm, no bundler, no analytics, no external fonts, no CDN. It works from a local file path and from any static host.
Accessible and responsive. System fonts, AA contrast, visible focus, landmarks, a skip link, reduced-motion support and a 360 px layout. The theme toggle stores one preference in localStorage; nothing else is stored.
Data-driven. Specification pages are rendered from the normative Markdown. The registry explorer is a static projection of the registry records. The capability viewer reads the same capabilities.json that ships in the schema bundle.
Written by PKU-YUAN-Lab. Questions go to the project's public issue tracker; security and safety reports follow SECURITY.md. Build date 2026-10-20; specification 0.9; wire revision 1.0.