Commission the machine boundary before an AI agent touches the controls

A hardware interface can turn a software request into motion, heat, pressure, flow, or another physical change. That makes write access an authorization decision about a deployed machine, not merely an API permission.

The canonical MHS project page identifies the Model Hardware Standard as a limited, application-based research preview for scientific research and advanced manufacturing. Participants are being invited to test the standard, build safety evaluations, and develop practices before it becomes open source. Preview participation does not establish that an agent-controlled installation is safe.

Anthropic’s preview announcement describes standardized drivers, device discovery, read/write primitives, natural-language hardware metadata, programmable interfaces, expert-oversight limitations, and planned safety evaluations. Ars Technica reports that the preview uses a common data interface, supports direct CLI and API control, can optionally connect models through MCP, and includes encoded physical constraints and safety limits.

Those materials establish an interface direction and a research program. They do not show that every driver represents every relevant device state, every encoded limit covers every hazardous condition, or every installation can recover from a failed action.

Write access needs a machine-specific case

An exposed command is not yet an authorized command. Before an agent can use it, the team needs a local account of the exact equipment and the controls that govern the operation.

That account begins with the manufacturer, model, hardware revision, firmware, driver version, and physical location. For each proposed write, it identifies the accepted parameters, units, range, preconditions, and applicable travel, load, temperature, pressure, timing, material, spatial, and environmental constraints.

The record must distinguish a described constraint from an enforced one. Natural-language metadata can explain a limit, while firmware, a driver, a controller, an interlock, an orchestration service, or a procedural control may enforce it. If the enforcement point and supporting evidence are unknown, the interface description cannot supply the missing assurance.

Observation belongs in the same account. A successful command response may show only that software accepted a request. A state read is also incomplete when its units, timestamp, freshness, or fault behavior is unknown. The commissioning case therefore identifies which independent observations can establish physical state and what missing, stale, or contradictory feedback means.

Separate the record from hazardous testing

The commissioning record should draw from manufacturer documentation, installed configuration, inspection records, prior qualified commissioning evidence, and observations obtained under an approved procedure. It is not permission to provoke a limit, interrupt live movement, defeat a safeguard, or inspect energized equipment.

Any physical test involving motion, energy, hazardous material, abnormal input, interruption, or recovery requires a prior hazard assessment and authorization under the site’s safety program. Qualified personnel must determine whether the manufacturer permits the procedure, what controlled test setup is required, which exclusion zones and protective measures apply, and whether the equipment can be placed in a safe condition before and after the test. If those conditions are absent, use documentation, simulation, an approved test fixture, or existing commissioning evidence—or leave the write disabled.

This boundary also applies to human override and recovery. The record can identify the authorized override, its documented physical effect, and the approved recovery procedure without instructing an operator to activate either on live equipment. “Stop” may have different implemented meanings, including blocking new commands, interrupting current motion, removing power, closing a valve, or leaving the device in place. Only qualified, site-authorized evidence can establish which meaning applies to the installation.

One artifact can hold the boundary together

The useful output is a compact machine-specific control record, not a generic declaration that a device passed commissioning. For each proposed write, it contains:

• the exact device and deployed software versions;
• the command, parameters, units, range, and preconditions;
• the applicable physical and environmental constraints;
• the enforcement point and supporting evidence for each limit;
• the observations used to determine physical state, including freshness and failure semantics;
• the authorized human override and its documented physical effect;
• the approved recovery path for timeout, partial execution, inconsistent state, or lost connectivity;
• the hazard assessment, qualified owner, approved procedure, test configuration, and inspection record supporting any physical commissioning evidence; and
• the conditions that keep the write unavailable.

This is an SGL-proposed commissioning artifact, not part of the announced MHS preview. It remains local to the installed equipment and proposed operation. Because the preview materials do not specify how every participating device enforces limits, the record cannot inherit an enforcement or recovery claim from the standard or a driver description.

Missing feedback deserves an explicit entry. A connection can be lost before execution, during a physical change, or after the target state is reached but before confirmation returns. The last successful software message does not resolve those possibilities. The record should instead specify what can be observed, who is authorized to assess the equipment, and which approved procedure governs the next action. Without that disposition, further writes remain unavailable.

Discovery does not confer control

Device discovery can expose an interface while its writes remain withheld. Read access, metadata visibility, and command authority are separate grants.

A write becomes a candidate for agent access only when the machine-specific record supports its constraints, enforcement, observation, override, and recovery under the deployed conditions. Where physical testing contributes to that evidence, it must come from the controlled, manufacturer-compatible, site-approved process described above. The resulting case applies only to the documented operation and circumstances; it does not establish that the standard, the device class, or another installation is safe.

Teams connecting these controls to a wider agent platform can build with Super Genius Labs. The immediate engineering task is narrower: make every physical write depend on evidence from the machine boundary, and keep control withheld wherever that evidence ends.