OpenMHS 0.9 · executable conformance

A claim is a level, not a logo.

OpenMHS conformance names a subject, a profile and a level CL0–CL5, and points to a machine-readable report a third party can recompute. Prose, badges without a report, and “MHS-compatible” are not conformance.

Read MHS-001 Self-certification steps

Reference suite present (11 modules) with 3 self-issued reports (CL2–CL4). Reports are issuer-kind self, not third-party verified.

The ladder

Six levels, each with evidence

Each level adds behaviour that must be demonstrated, including negative behaviour. A skipped test is not a passed test.

CL0

Declared

Manifests and schemas validate; no runtime is required.

Valid device and adapter manifests against the OpenMHS schemas
Capability bindings reference known class MAJOR versions
Registry record validates if one is published

Evidence: A schema-validation report with at least one test result.

Requirements

CL1

Observable

A host can discover and read the device, with stable revisions.

T1 and/or T2 transport
hello, devices.list/get, schema.get
resource.read with state hash
subscribe and unsubscribe

Evidence: Transport transcript and stable revision/state-hash evidence.

Requirements

CL2

Actuating

Commands are idempotent, receipted and cancellable.

session.open/close
command with command_id and retained receipts
expected_revision conflicts
operations.get/cancel and deadlines

Evidence: Receipts proving completion, rejection, replay and cancellation.

Requirements

CL3

Governed

The endpoint refuses unsafe actions before any effect.

safety.status/estop/reset
envelope limits and interlocks enforced in order
risk classes and permits for gated capabilities
MHS.SAFETY.NOT_CERTIFIED disclosed

Evidence: Negative tests: open interlock, stale revision, missing permit.

Requirements

CL4

Reproducible

Outcomes can be reconstructed and evidence verified offline.

evidence.export and evidence.verify hash chain
deterministic replay for simulated/replay devices
same seed ⇒ identical state_hash sequence

Evidence: Exported bundle with a verifiable head digest and replay equality.

Requirements

CL5

Orchestrated

Compositions and multi-device sessions are evidence-bearing.

composition.run with child receipts
multi-device sessions
backpressure and gap semantics
published conformance report

Evidence: Child receipt tree and a published, digest-addressed report.

Requirements

Profiles

Five subjects, five profiles

A profile fixes what is being tested and which levels are defined. An endpoint subject cannot claim MHS-Host, and a host cannot claim MHS-Device.

Profile	Subject	What is tested	Levels	Note
MHS-Device	Endpoint	Hardware-backed endpoint and its devices	CL0–CL4	No replay requirement
MHS-Sim	Endpoint	Simulated or hybrid endpoint	CL0–CL4	Fidelity contract required; CL4 replay
MHS-Bridge	Package / adapter	Adapter manifest plus endpoints a bridge launches	CL0–CL5	CL5 needs a published report
MHS-Host	Host	Agent harness consuming OpenMHS	CL1–CL5	Discovery, approvals, evidence ledger
MHS-Registry	Registry	Records, trust and search	CL1–CL5	Digest reproducibility and federation

Test matrix

Requirement coverage by level

● every relevant test must run and pass · ◐ a subset defined by the level's mandatory suite · — not required.

Area	CL0	CL1	CL2	CL3	CL4	CL5
`ADPT`adapter and manifest	required	subset required	subset required	subset required	subset required	required
`CAP`classes and bindings	required	required	required	subset required	subset required	subset required
`REG`registry publication	required	not required	not required	not required	subset required	required
`PROTO`framing and methods	not required	required	required	required	subset required	subset required
`TPT`transports	not required	required	required	subset required	subset required	subset required
`SESS`sessions	not required	subset required	required	required	subset required	subset required
`OP`operations and idempotency	not required	not required	required	required	subset required	required
`MODE`mode declaration	not required	required	required	required	required	subset required
`EVT`subscriptions	not required	required	required	subset required	required	required
`SAFE`safety	not required	not required	subset required	required	required	subset required
`FID`fidelity and determinism	not required	subset required	subset required	subset required	required	subset required
`EVID`evidence	not required	not required	subset required	subset required	required	required
`COMP`compositions	not required	not required	not required	not required	not required	required
`CON`meta and report	required	required	required	required	required	required

Mandatory negative tests

The suite must include tests that prove refusal, not only success. A suite that only exercises the happy path cannot support CL3 or above.

Test	What must happen
`SAFE-050`	hello.features omits MHS.SAFETY.NOT_CERTIFIED
`SAFE-020`	A command proceeds while a required interlock reads open
`PROTO-040`	A command with a stale expected_revision changes state
`OP-010`	The same command_id with different input is accepted
`SESS-010`	A session survives its TTL without a heartbeat
`MODE-002`	A session opens with a mode other than the device's declared mode
`EVID-010`	A tampered evidence bundle verifies as valid
`FID-010`	A simulated device without a fidelity contract claims CL1+

Self-certification

How to certify without a certification body

OpenMHS is designed for self-service. The registry claim plus a reproducible report is the starting point; third-party verification is an additional trust level, not a gate.

01
Choose the subject and the honest level
An endpoint, package, host or registry. Pick the profile that matches the subject and the lowest level that includes the behaviour you actually implement. CL0 is a valid, useful claim.
02
Validate every manifest and schema
Device manifests, adapter manifests, capability bindings and any registry record must validate against the published JSON Schemas. A simulator without a fidelity contract fails before runtime.
03
Run the suite against the endpoint
Use the same suite version you cite. Run the negative tests. Do not skip a mandatory test because the endpoint does not implement the failure path.
mhs conform --endpoint mhs://localhost:7400 --profile MHS-Sim --level CL3 --out report.json
04
Inspect the report and recompute its digest
The report lists every test id with pass, fail or skip. The report digest must be reproducible from the report bytes. A report without the mandatory tests for the claimed level is not a claim.
05
Publish the claim
Attach profile, level, suite version, report digest, issuer kind and timestamp to the registry record. Unsigned claims are displayed as unsigned; they are never presented as verified.
06
Re-run when identity changes
A new manifest, fidelity contract, capability set or device instance invalidates the prior report. Re-run, publish a new digest, and keep the old claim addressable.

Reference run

A real CL4 report, recomputable from this site

This is not a mock-up. The report below was produced by running the reference conformance suite against the deterministic conveyor endpoint, and the raw JSON ships with the site.

42passed

2failed

4skipped

36required

2026-11-05run date

Report digest

sha256:ff1c9817d28b88b1c17c35e701538c37076818233dbccb9db5eee8a84c77eb6e

This is the report body digest: SHA-256 over the JCS canonical form with report_digest removed, not the hash of the pretty-printed file. A claim without a matching digest is not evidence.

Download the raw report Report requirements

Test	Requirement	Status	Level	Detail
`ADPT-005`	device manifests validate against the MHS schema	PASS	CL0	1 device manifest(s) validate against device.schema.json
`TCON-001`	the profile matches the subject kind and every device mode	PASS	CL0	endpoint subject under MHS-Sim; device modes simulated
`CAP-035`	bound classes are catalogue classes or extensions	PASS	CL0	8 binding(s) name catalogue classes or extension namespaces
`CAP-017`	bindings do not lower their class risk floor	PASS	CL0	6 catalogue binding(s) respect their class risk floor
`CAP-016`	binding schemas do not drift from their class (advisory)	FAIL	CL0	mhs://localhost:7400/lab/conveyor-workcell: cap.actuation.valve.v1 property-not-in-class at input.gate
`TCAP-002`	bindings target a resource kind their class accepts (advisory)	FAIL	CL0	mhs://localhost:7400/lab/conveyor-workcell: cap.actuation.valve.v1 bound to resource kind 'world.sim'; mhs://localhost:7400/lab/conveyor-workcell: cap.motion.stop.v1 bound to resource kind 'world.sim'
`CON-031`	hardware is not actuated without allow_actuation (suite check)	PASS	CL0	no hardware or hybrid device: the actuation gate was not engaged
`CON-032`	e-stops are sent only to software/both e-stops (suite check)	PASS	CL0	mhs.safety.estop sent 3 time(s) and mhs.safety.reset 4 time(s), only to software/both e-stops
`TPROTO-901`	every mandatory CL1 method is implemented (dispatch-level probe)	PASS	CL1	8/8 CL1 mandatory methods reached dispatch; probes: mhs.hello=present, mhs.devices.list=present, mhs.devices.get=present, mhs.schema.get=present, mhs.session.open=present, mhs.session.close=MHS.SESSION.UNKNOWN, mhs.resource.read=present, mhs.evidence.export=present
`TPROTO-902`	every mandatory CL2 method is implemented (dispatch-level probe)	PASS	CL2	4/4 CL2 mandatory methods reached dispatch; probes: mhs.command=present, mhs.subscribe=MHS.PROTOCOL.INVALID_PARAMS, mhs.unsubscribe=MHS.SESSION.UNKNOWN, mhs.operations.get=MHS.OPERATION.UNKNOWN
`TPROTO-903`	every mandatory CL3 method is implemented (dispatch-level probe)	PASS	CL3	2/2 CL3 mandatory methods reached dispatch; probes: mhs.operations.cancel=MHS.OPERATION.UNKNOWN, mhs.safety.status=present
`PROTO-013`	mhs.hello negotiates the protocol and lists devices	PASS	CL1	hello ok: 1.0, 1 device(s)
`PROTO-021`	devices.list/get return complete manifests	PASS	CL1	devices.list/get ok for 1 device(s)
`PROTO-023`	resource.read returns a verifiable revision and state hash	PASS	CL1	read workcell@r0 hash verifies
`PROTO-024`	reads are stable without mutations	PASS	CL1	read is stable at revision 0
`SESS-001`	session.open returns a grant, mode and expiry	PASS	CL1	session opened with 8 granted capability(s)
`MODE-002`	session mode mismatch is rejected	PASS	CL1	mode 'hardware' rejected with MHS.SESSION.MODE_MISMATCH
`SESS-005`	session heartbeat refreshes the lease	PASS	CL3	session heartbeat refreshed the lease
`OP-001`	a valid command returns a completed receipt	PASS	CL2	cap.world.step.v1 (invoke, class example input) completed r0->r1; revision advanced; read-verb cap.world.state.v1 (class example input) completed and kept the revision at r1
`TCAP-001`	a completed command's output validates against its output_schema	PASS	CL2	cap.world.step.v1 output validates against the binding output_schema
`TCAP-003`	a probe command has an observable effect (writes change state)	PASS	CL2	invoke cap.world.step.v1 changed resource 'workcell' state
`OP-003`	command_id idempotency replays without re-execution	PASS	CL2	duplicate command_id with identical input replayed without a second effect
`OP-004`	command_id reuse with different input is a conflict	PASS	CL2	command_id reuse with different input rejected with MHS.CONFLICT.COMMAND_ID_REUSE
`OP-005`	expected_revision conflicts are rejected	PASS	CL2	stale expected_revision rejected with MHS.CONFLICT.REVISION
`PROTO-027`	schema-invalid input is rejected without effects	PASS	CL2	input with a wrongly typed 'ticks' rejected with MHS.CAPABILITY.INPUT_INVALID
`PROTO-014`	unknown capabilities are rejected	PASS	CL2	unknown capability rejected with MHS.CAPABILITY.UNKNOWN
`PROTO-030`	operations can be queried for commands	PASS	CL2	operations.get(op_01M6PPRAMG45TG86XXME6H5ZP4) returns the receipt snapshot
`PROTO-011`	deadlines surface as a timeout outcome	PASS	CL2	deadline exceeded on cap.world.step.v1 surfaced as MHS.OUTCOME.TIMEOUT (status 'unknown')
`OP-011`	cancellation resolves to a declared safe state	SKIP	CL3	endpoint does not declare a cancellable capability; OP-011 is not applicable
`OP-013`	unknown-outcome semantics survive a lost receipt	PASS	CL2	lost response surfaced as MHS.OUTCOME.UNKNOWN (status 'unknown'; observed r9)
`SAFE-001`	safety.status exposes risk, e-stop, interlocks and safe state	PASS	CL3	safety.status ok: risk R1, 1 interlock(s)
`SAFE-045`	hardware R2+ devices declare an independent stop path	SKIP	CL3	no hardware or hybrid device at R2/R3; SAFE-045 is not applicable
`SAFE-029`	safe_state.achieved_by resolves to bound, permit-free actions	PASS	CL3	safe_state.achieved_by resolves on 1 device(s)
`TSAFE-001`	e-stop latches, blocks commands and reset releases it	PASS	CL3	e-stop latched within its declared latency, blocked commands, reset released the latch without auto-resume, a new command recovered
`SAFE-028`	the e-stop reaches the device and its safe state	PASS	CL3	e-stop reached mhs://localhost:7400/lab/conveyor-workcell: latched, safe state achieved in 0 ms; driver estop() invoked
`SAFE-011`	open interlocks block actuation	PASS	CL3	refused with no bridge call: cap.world.step.v1 (door_closed open: MHS.SAFETY.INTERLOCK_OPEN)
`SAFE-012`	interlocks in an unknown state block actuation	PASS	CL3	refused with no bridge call: cap.world.step.v1 (door_closed unknown: MHS.SAFETY.INTERLOCK_OPEN)
`SAFE-041`	reset is refused while a hard interlock is open	PASS	CL3	reset returned 'rejected' MHS.SAFETY.RESET_REFUSED while 'door_closed' was open
`SAFE-031`	gated capabilities require a valid single-use permit	PASS	CL3	permit required, accepted for the bound input, rejected for a different input (MHS.SAFETY.PERMIT_INVALID)
`SAFE-014`	safety envelope bounds are enforced before effects	PASS	CL3	7 out-of-limit probe(s) refused with MHS.SAFETY.ENVELOPE_VIOLATION before any effect (0 inside the schema range), covering 4 limited path(s): cap.actuation.valve.v1 gate, cap.world.step.v1 ticks, x-cap.mhs-reference.feed.v1 count, x-cap.mhs-reference.start.v1 speed_mm_s; values gate='mhs-conformance-not-allowed', ticks=10001, ticks=0, count=33, count=0, speed_mm_s=201, speed_mm_s=-1
`SAFE-050`	MHS.SAFETY.NOT_CERTIFIED is disclosed in hello	PASS	CL3	hello advertises MHS.SAFETY.NOT_CERTIFIED
`EVID-015`	evidence exports and verifies offline	PASS	CL4	evidence bundle verified offline (15 receipts, head sha256:7e40e7047b696ed89937879884fb14767f67412b1b5e3414162302da58d6db97)
`EVID-016`	tampered evidence is detected	PASS	CL4	tampered bundle rejected: {'seq': 1, 'mhs_code': 'MHS.EVIDENCE.CHAIN_BROKEN', 'detail': "digest mismatch (recomputed sha256:cb24c8b396eeaa8e311366c0839d16e945b0517921ccc85dab562b05c2727f3e, receipt claims 'sha256:f8e7cd3359cdbcd3b5a332b561fbbe017e2edaa3f91a09321a3d3252551fe759')"}
`EVID-010`	receipt evidence links form a hash chain	PASS	CL4	evidence chain links verified across 15 receipt(s)
`FID-005`	simulated devices disclose a complete fidelity contract	PASS	CL4	fidelity contracts disclosed for 1 device(s)
`FID-016`	restore reproduces an identical state_hash sequence	PASS	CL4	restored snapshot reproduced identical state_hash sequence (2 commands)
`FID-025`	seeded replay reproduces identical sequences for the same seed	SKIP	CL4	primary device does not declare seeded determinism
`MODE-005`	replay endpoints are read-only but readable and snapshotable	SKIP	CL1	endpoint does not expose a replay-mode device

Declared limitations

optional test failures (do not demote the level): CAP-016, TCAP-002
skipped tests: FID-025, MODE-005, OP-011, SAFE-045
requirement coverage (MHS-001 §5, SPEC-001): 582 normative ids; checked=52 tested=52 dispositioned=262 (out_of_profile=153, editorial=64, report_process=41, level_not_claimed=4) not_verified=268; the award covers only the executed checks and is not a claim of full normative coverage (inventory: mhs/conformance/applicability.json).

Skipped tests are displayed, not hidden. This run is self-issued by the reference suite; it is not third-party certification and not safety certification. Environment: Darwin 27.0.0 · Python 3.14.7.

Report

What a conformance report contains

The report is data, not a PDF. It validates against conformance-report.schema.json and is addressed by digest.

Report

conformance-report.json

{
  "report_version": "1.0",
  "suite_version": "1.0.0",
  "profile": "MHS-Sim",
  "endpoint_id": "mhs://localhost:7400",
  "level_claimed": "CL3",
  "level_achieved": "CL3",
  "tests": [
    {"id": "PROTO-001", "status": "pass",
     "evidence": {"request_digest": "sha256:…", "response_digest": "sha256:…"}},
    {"id": "SAFE-020", "status": "pass", "evidence": {"note": "interlock open ⇒ rejected"}}
  ],
  "environment": {"mhs_version": "1.0", "os": "linux", "date": "2026-10-20T00:00:00Z"},
  "report_digest": "sha256:…",
  "issuer": {"kind": "self", "key_id": null},
  "signature": null
}

Registry claim

claim.json

{
  "claim_type": "conformance",
  "subject": "gh.example/lab-endpoint",
  "profile": "MHS-Sim",
  "level": "CL3",
  "suite_version": "1.0.0",
  "report_digest": "sha256:…",
  "issued_at": "2026-10-20T00:00:00Z",
  "issuer_kind": "self",
  "trust": "unsigned"
}

conformance-report.schema.json registry-record.schema.json

Six levels, each with evidence

Declared

Observable

Actuating

Governed

Reproducible

Orchestrated

Five subjects, five profiles

Requirement coverage by level

Mandatory negative tests

How to certify without a certification body

Choose the subject and the honest level

Validate every manifest and schema

Run the suite against the endpoint

Inspect the report and recompute its digest

Publish the claim

Re-run when identity changes

A real CL4 report, recomputable from this site

mhs://localhost:7400

Declared limitations

What a conformance report contains

Report

Registry claim