EXPERIMENT_039 // MHS.MOCK.HARDWARE.CONTROLLER
This experiment demonstrates a full protocol cycle — device discovery, capability negotiation, and structured read/write commands — sent to a simulated kinetic installation of two motors and a light fixture, rendered live on a Canvas 2D viewport. It models the shape of Anthropic's Model Hardware Standard research-preview announcement, not an integration with the real MHS SDK.
LOADING EXPERIMENT...
Anthropic announced the Model Hardware Standard (MHS) as a research preview on 2026-08-27 — device discovery, capability negotiation, and a simple read/write command primitive pair for agents to control physical hardware, limited for now to a first group of scientific-research and advanced-manufacturing partners with no public SDK. This experiment reconstructs that protocol shape against a simulated kinetic installation: two turntable motors and a dimmable light ring. Type a plain-language intent, an LLM translates it into a structured command batch, and each command lands against the simulated installation's live capability manifest — including its safety limits — with the response rendered on a Canvas 2D viewport in real time.
HOW IT WORKS
There is no real hardware behind this experiment, so `devices.ts` plays the role MHS assigns to a device's own driver: three fixed capability manifests (two `kinetic_motor` devices, one `light_fixture`), each listing its parameters' access mode (read, write, or read_write), unit, min/max range, a `safetyLimit`, and a natural-language `description` — the announcement's "what it can measure, what can be adjusted, and what safety limits will be enforced," written directly into the manifest the way the announcement says a driver's natural-language tags do. `SimulatedInstallation.discover()` returns this list instantly and deterministically, standing in for hardware enumeration rather than an LLM call.
Typing an intent and clicking Send posts it, together with the current capability manifests, to `/api/experiments/mhs-hardware-controller/command`. The route calls OpenAI's gpt-5.4-mini via `@diabolicallabs/llm-client`'s `client.structured()`, constrained to `AgentCommandBatchSchema` — a short reasoning trace plus an ordered list of MHS's named "read"/"write" command primitives. The system prompt instructs the model to reference only device IDs and parameter names present in the supplied manifest and to stay under each parameter's safety limit, but the route treats that instruction as guidance, not a guarantee.
Every command the model returns is re-validated client-side against the live capability manifest before it touches the simulated installation, regardless of what the model claimed: an unknown device or parameter is rejected, a write against a read-only parameter (or a read against a write-only one) is rejected, a value outside `[min, max]` is rejected, and a value inside that range but above `safetyLimit` is rejected with a distinct "exceeds the driver-enforced safety limit" reason — the specific rejection class the announcement's safety-limit language implies a real MHS driver would produce. A valid write sets the parameter's target value; `applyCommand()` never trusts the model's output as pre-validated.
Accepted writes set a target value that the simulated device's current value chases at a fixed lerp rate each tick, rather than snapping instantly — visible spin-up and fade, not a jump cut. Motor angle integrates continuously from live speed and direction so the canvas shows real rotation, and each motor's read-only `position` parameter derives from that same angle. The `light_fixture`'s read-only `powerDraw` derives from its current brightness. `MhsHardwareControllerCanvas` owns the requestAnimationFrame loop and ticks the shared installation instance directly, matching the render-loop-outside-React-state pattern established by `SpatialTelemetryCanvas` and `CrowdFlowCanvas`; `prefers-reduced-motion` halves the tick timestep rather than freezing the scene.
WHAT THIS PROVES
A research-preview announcement with no disclosed wire format can still specify enough protocol shape to build a working, closed-loop demonstration against: discovery, a capability-manifest-with-safety-limits contract, and a two-primitive command set were sufficient to construct a full intent-to-visible-response cycle, while keeping the speculative/simulated boundary explicit throughout the code, the in-app copy, and this description rather than implying validation against the real MHS SDK.
The security posture a real agent-to-hardware bridge needs is visible in the command validation, not just asserted: the LLM's output is never treated as pre-validated. Every command — however well-behaved the system prompt makes the model — is re-checked against the live capability manifest's access mode, range, and safety limit before it can move an actuator, the same untrusted-input discipline this repo's other agent-facing routes apply to user text.