OpenMHS 0.9 · specification set
The specification
The normative definition of OpenMHS: the contract plane, its wire protocol, the capability vocabulary, safety and fidelity semantics, adapters, the registry and executable conformance.
Core normative documents
OpenMHS Core
The short normative core: the object model, the read, write and action primitives, limits and their evaluation order, e-stop and reset, receipts, modes, the control surfaces, strict mode and persistence.
11,926 words core.mdOpenMHS Driver Profile
The per-repository driver package: layout, the Driver API, the acceptance gate G1 to G9, provenance and review, fakes and the sandbox.
4,342 words driver-profile.mdOpenMHS Optional Profiles
Which chapters belong to the core and which to an optional profile: sessions and permits, evidence, simulation, events, host, registry and governance.
920 words profiles.mdOpenMHS Architecture Overview (informative)
Informative: the design, the reasons for it and the adoption path for the 2,967-repository corpus. It wins no conflict.
8,314 words 00-architecture.mdConformance: Levels, Profiles, Test Suite and Claims
Levels CL0–CL5, five profiles, the executable suite, test identifiers and the report that backs a claim.
5,691 words 01-conformance.mdWire Protocol
JSON-RPC framing, the method table, receipts, operations, subscriptions, deadlines and the stable error vocabulary.
7,581 words 02-wire-protocol.mdCapability Registry and Core Capability Classes
Class identity and versioning, unit rules, and the catalogue of core capability classes.
13,748 words 03-capability-registry.mdSafety, Permits, Sessions, Audit and Threat Model
Risk classes, the endpoint-evaluated envelope, interlocks, permits, e-stop semantics, sessions and the evidence chain.
7,204 words 04-safety.mdTransports, hosts and governance
Modes, Fidelity Contract, Determinism and Replay
The dual-world rule, fidelity contract F0–F3, determinism, replay, hybrid authority and gap disclosure.
3,786 words 05-fidelity.mdAdapters, Bridges and Integration Recipes
Declarative adapter manifests, generic bridge runtimes, the mapping rules, integration tiers and recipes.
5,475 words 06-adapters.mdThe Registry: Records, Federation, Trust and Search
Package, device, adapter and conformance records; federation, trust levels, signing and search.
3,107 words 07-registry.mdAppendices
Transport Bindings and the MCP Projection
Transport bindings T1–T6: stdio, HTTP/SSE, WebSocket, the MCP projection, CLI and code API.
5,498 words 08-transports.mdMHS-Host Profile
What an agent harness must do to claim MHS-Host, and the normative OpenAI4S mapping.
4,542 words 09-host-profile.mdGovernance: RFC Process, Versioning, Deprecation, Disclosure and Licensing
The RFC process, versioning and deprecation, and the licensing of specification, code and registry data.
4,321 words 10-governance.mdCore Capability Catalogue
The generated, tabular presentation of every core capability class.
3,797 words appendix-a-capabilities.mdError Code Registry
The stable MHS.* code vocabulary, grouped by area, with retry and remediation semantics.
4,939 words appendix-b-errors.mdEnd-to-End Examples and Transcripts
Informative transcripts for a lab instrument, a robot, a simulator and a hybrid workcell.
4,201 words appendix-c-examples.mdThe Anthropic research preview: what is public, what it describes, and how this specification relates
What the Anthropic MHS research preview publishes, what it describes, and what this specification adopts, defines and refuses to claim.
1,883 words appendix-d-anthropic-mhs.mdReading paths
Read by role
The architecture document fixes the model. Every other document refines one section and must not contradict it.
Implement an endpoint
Write a driver for a repository
Write a host or agent harness
Review safety claims
Conventions
How to read the normative text
Requirement language
MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY and OPTIONAL are interpreted as described in RFC 2119 and RFC 8174.
Requirement identifiers
Requirements are numbered AREA-NNN (for example SAFE-012). The same identifier is the conformance test case id that checks the requirement.
Precedence
When two documents disagree the higher one wins: the schemas and registries, then the core, then the driver profile, then chapters 01 to 10, then the appendices. The architecture overview is informative and wins nothing. A conflict is a defect, fixed by an erratum to the lower document.
Versioning
The protocol is 1.0. Capability classes carry their own MAJOR version. Registry records validate against versioned JSON Schemas.