OpenMHS Optional Profiles

OpenMHS is an independent open-source project, not affiliated with or endorsed by Anthropic, and not a reimplementation or compatible dialect of Anthropic's MHS research preview (appendix D).

core.md is what every endpoint and driver must satisfy. An optional profile adds behaviour the SDK implements but that a driver author does not need to know about: a driver never declares a profile, and an endpoint, host or registry claims one by implementing its chapter. This page lists the profiles, the chapters that define them, the requirement areas they own and where the reference implementation lives. Do not confuse them with the conformance profiles MHS-Sim, MHS-Device, MHS-Bridge, MHS-Host and MHS-Registry of 01, which name what a conformance report is about. The key words of RFC 2119 and RFC 8174 apply in the chapters, not in this index.

1. The profiles

Composition is reserved. mhs.composition.run, cap.internal.composition_run.v1 and the COMP requirements (02 §15.1) describe a deterministic multi-step document executed by an endpoint. No 0.9 endpoint implements it: the reference endpoint answers MHS.PROTOCOL.METHOD_NOT_FOUND. The name and the requirements stay reserved so that a later profile can fill them without renumbering. Multi-step procedures in 0.9 are code files (core.md §10.3), which run on the client and cannot do more than the same calls made one by one.

2. Which layer is each chapter

README §1 orders the chapters below the Core and the Driver Profile. Each carries a Layer row in its header table; sections that belong to a different layer say so.

3. Sim, Fidelity and Replay in one page

These rules are kept here because the Core points at them (core.md §8):

• The twin rule. A simulator is a different device from the hardware it models: it has its own device_id and instance_id, mode simulated or hybrid, and models: [physical device_id] when it models a specific device; a physical manifest never declares models; trust, conformance and approvals are never transferred between them; and a call never silently crosses the sim and hardware boundary (FID-045 to FID-049).
• The fidelity contract. A simulated or hybrid device carries fidelity: engine, fidelity_level (F0 to F3), determinism (exact, seeded, statistical, none, with seed_control), timestep_ms, realtime_factor, reset, snapshot_restore, honest gaps, authority for a hybrid device, and validation for F3 (FID-001, FID-005, FID-006, FID-040 to FID-044). A fake backend is F0 with gaps.
• fidelity.clock. An optional member that says who advances simulated time: lockstep (only commands advance it; the Gymnasium and MuJoCo family drivers declare it), free_running (the simulator runs on its own clock) or external (an outside scheduler). A host does not assume wall-clock pacing from realtime_factor (FID-013, FID-014).
• Replay. A replay device is read-only and serves recorded state; it advertises the replay.seek feature (MODE-005, FID-022 to FID-029).