Project · process and licensing
How the standard changes, and how it is licensed
OpenMHS is a draft with a versioned change process. The rules are intentionally boring: one concern per proposal, testable requirements, no silent edits, and licences that let vendors and labs implement without asking permission.
RFC process
From proposal to amendment
The schemas win over the core, the core over the chapters, and a conflict is fixed by an erratum or an accepted RFC. A change that touches behaviour must touch requirements, schemas and tests in the same proposal.
- 01
Proposal
A written problem statement, the affected requirements, and the proposed change. One concern per RFC; no bundling.
- 02
Discussion
The editors publish the proposal with a review window. Implementers test the change against real endpoints and the conformance suite.
- 03
Decision
Accepted, rejected or returned for revision, with the rationale recorded. Silence is not acceptance.
- 04
Amendment
An accepted RFC amends the normative text, bumps the affected version, and updates schemas, capability classes and tests together.
What belongs in an RFC
Wire behaviour, capability classes, safety semantics, conformance tests, registry fields, versioning or licensing. Editorial fixes can be handled as errata, but they never change meaning silently.
What does not
Product announcements, driver-specific quirks that belong in an adapter manifest, or changes that make a safety claim without a test. Implementations belong in the registry, not in the standard.
Review evidence
A proposal that changes a requirement should include a failing test, an endpoint transcript, or a concrete adapter that cannot be expressed today. “It would be convenient” is not evidence.
Participation
Driver authors, instrument vendors, simulation maintainers, lab integrators and host authors are the reviewers that matter. The process is open; no membership tier buys a vote.
Versioning
Three clocks that must not be confused
The wire protocol, capability classes and registry schemas version independently. That is what lets the vocabulary grow without breaking a host.
| Artefact | Version | Changes when | Compatibility rule |
|---|---|---|---|
| Wire protocol | 1.0 | Framing, method semantics, error model, transport requirements change incompatibly. | MAJOR mismatch fails closed with MHS.PROTOCOL.VERSION_UNSUPPORTED. MINOR additions are negotiated. |
| Capability class | cap.*.v1 | An input is removed, retyped, made required; a unit or meaning changes; the verb changes. | The id carries its MAJOR. Additive changes keep the id; a new MAJOR is a new class. |
| Registry schema | 1.0.0 | Record fields or validation rules change. | Records validate against the version they cite; the registry publishes its index digest. |
| Conformance suite | 1.0.0 | Tests are added or corrected; a requirement's check changes. | A claim cites the suite version; a report cannot be recomputed with a different suite. |
Deprecation windows are stated in the RFC that deprecates an artefact. Of the 63 core classes, 44 stable, 13 experimental, 6 deprecated. A deprecated class stays valid and callable; its notes name the protocol method that replaces it.
Licensing
Implement without asking
The licences are chosen so a vendor can ship an adapter, a lab can mirror the registry, and a host can embed the schemas without a commercial negotiation.
| Artefact | Covers | Licence | What it means |
|---|---|---|---|
| Specification text | the core, the driver profile, MHS-000 to MHS-010 and the appendices | CC BY 4.0 | Share and adapt with attribution; no endorsement. |
| Schemas and code | JSON Schemas, examples, reference SDK, bridges, site source | MIT License | Permissive; redistribution with notice; no trademark grant. |
| Registry data | Package records, index files and claims | CC BY 4.0 | Attribution to the OpenMHS registry; preserve trust labels. |
Attribution
When you cite the specification, name “OpenMHS 0.9 (independent draft), The OpenMHS Authors” and link to the source repository. When you reuse registry data, preserve the trust level and evidence state; do not present an unsigned record as verified.
No trademark licence
Neither licence grants rights to any name or mark, including those of third parties such as Anthropic. Quoted third-party text, such as the Anthropic quotations in appendix D, is not licensed by this project. A conformance claim must be accurate; it is not an endorsement.
Contributions
Contributions to specification text, schemas or code are accepted under the inbound licence of the file being changed (CC BY 4.0 or MIT). No separate CLA is intended.
Decision log
Ten choices that shape the standard
Alternatives were considered and recorded. They are part of the normative context, not marketing.
JSON-RPC 2.0 rather than REST, gRPC-only or MCP-only. It embeds in stdio, HTTP and WebSocket and maps natively to MCP.
Sessions as leases rather than stateless calls. Simulators are stateful and cancellation needs a scope.
Receipts, revisions and state hashes rather than ok:true. Without them, an agent cannot distinguish “not done” from “unknown”.
Endpoint-enforced safety, not host policy. A host is the wrong trust boundary for a laser.
Simulation and hardware in one model, with explicit mode and fidelity. Two standards would double the work; silent conflation is unsafe.
Declarative adapters plus generic bridges, not a generated driver per repository.
Capability classes versioned separately from the wire. Vocabulary evolves faster than framing.
Executable self-conformance rather than a certification body as gatekeeper.
Natural-language tags attached to typed capabilities, not documentation alone.
A static, signed registry rather than a central live broker. Air-gapped labs need a mirror, not a dependency.