Anthropic Model Hardware Standard: A PDCAT Playbook for Safer AI Physical Device Control

Why a shared hardware interface does not make an unsafe command safe

Anthropic Model Hardware Standard gives labs and manufacturers a practical reason to revisit physical-device control. The useful starting point is blunt: a common interface can make devices easier for an AI system to find and command, but it does not make a bad command safe. That distinction matters the moment software output turns into motion, heat, pressure, liquid handling, positioning, calibration, or any other physical action.

Anthropic's Model Hardware Standard research preview moves the AI interoperability conversation from software tools into laboratories and manufacturing environments. Anthropic describes MHS as a shared specification for AI agents to safely operate physical devices, initially shared with scientific research labs and advanced manufacturers. The announcement names instruments such as microscopes, liquid handlers, and robotic arms.

That is useful early evidence. It is not a blanket production guarantee. Anthropic also says it is sharing an early version with partners to build safety evaluations and best practices before making the standard open source. So MHS should be read as a limited research preview, not a finished public standard that every team can treat as ready for plant-floor or wet-lab operations. Physical intuition and safety evaluation still have to be proven in the target workflow.

Optijara's contribution in this article is PDCAT, the Physical Device Control Acceptance Test. PDCAT is a readiness framework for deciding whether a shared driver and agent interface is ready for a bounded scientific or manufacturing workflow. The same discipline appears in the Optijara Newton Physics robot simulation acceptance test: simulated capability only matters when it becomes reproducible evidence.

What the Model Hardware Standard research preview covers

Anthropic frames MHS as a way to reduce bespoke hardware integration through shared drivers, schemas, and interfaces. The official announcement says many labs and manufacturing facilities spend weeks, if not months, integrating hardware because devices often do not communicate with each other and require specialist work. It also reports preview-context reductions to hours or minutes. Treat that as Anthropic-reported early evidence, not a benchmark that transfers automatically to every device fleet.

The public Model Hardware Standard site points readers to research preview access and links back to the announcement. Anthropic says MHS works with programmable devices and is model-agnostic, with agent runtimes able to access it through standard protocols such as the Model Context Protocol specification. MCP is an open protocol for connecting language-model applications with external data sources and tools. MHS extends that direction into hardware, where the harder questions are physical: what are the operating limits, what telemetry confirms action, what happens on timeout, and who can stop the machine?

HHMI Janelia Research Campus is named by Anthropic as an origin collaborator. This article attributes specific MHS collaboration claims to Anthropic's rendered announcement and uses the HHMI page only as public institutional context, because the HHMI page triggered bot verification during fact-checking.

The PDCAT Framework

PDCAT has three layers. Each layer should produce evidence before a team moves from integration to simulation, from simulation to dry run, and from dry run to controlled pilot.

Layer 1 starts with inventory. Every device needs identity, location, firmware, network path, driver version, calibration status, supported primitives, units, coordinate frames, operating envelope, hazards, dependencies, and manual fallback. A robotic arm primitive is not just move(x, y, z). It needs coordinate frame, speed, acceleration, collision zone, payload, timeout behavior, idempotency behavior, expected telemetry, and safe state on failure.

Layer 2 defines who or what can command the device. Discoverability should be scoped so an agent sees only approved devices and approved commands for the current workflow. A shared interface should not let a planning model browse every instrument on a network. Identity, network boundaries, role-based policies, signed driver packages where available, and explicit human approval should be mandatory for actions that move hardware, change temperature, alter pressure, dispense materials, change speed, or affect safety-critical equipment.

Layer 3 tests whether the workflow can fail safely. Simulation and dry run are evidence generators. The team should test normal operation, stale telemetry, network loss, command replay, calibration failure, emergency stop, and rollback. Stop-use criteria should be written before the pilot starts.

PDCAT Implementation Checklist For Bounded Workflows

Start with a bounded workflow, not a platform ambition. A useful first scope might be one instrument, one command family, one operator group, and one reversible task. The point is to learn whether the interface, safety controls, and evidence trail are strong enough before the surface area expands.

Comparison against bespoke integrations should be local and measured. Do not assume that MHS-style interoperability is faster, safer, or cheaper in your environment because a preview announcement reports promising integration reductions. Measure setup effort, failed commands, operator interventions, calibration drift, incident count, rollback time, and telemetry completeness against your current approach. For adjacent qualification discipline, see the Optijara HiPHI dataset acceptance test, which separates dataset promise from deployment readiness.

Data lineage belongs in the checklist too. Experiment logs, sensor traces, images, operator approvals, model prompts, tool calls, and device outputs should be linked by command ID. If a device action affects a sample, batch, part, or calibration run, the evidence trail needs to survive review.

Decision Matrix

A blunt take: adopt is usually the wrong default verb for a research preview. Adopt should mean one bounded workflow, with named devices, trained operators, observed dry runs, and rollback proof. It should not mean every instrument in the facility is now fair game for agent control.

Pilot is often the more honest state. It lets a team test the integration and safety case without pretending the control plane is mature everywhere. Wait is not failure either. It is the right call when device risk, instrumentation, ownership, or manual override is not good enough.

Control Flow From Command To Rollback

Every proposed command should leave evidence at each gate. The scope check records whether the device and primitive are allowed in this workflow. Schema validation records parameter types, units, coordinate frames, bounds, timeout, and idempotency behavior. Authorization records the policy decision and any human approval. The physical-limit check records why a command sits inside the approved operating envelope. Simulation or dry run records expected device state without irreversible action. Canary execution records command ID, operator, timestamp, and telemetry.

Timeout and idempotency deserve special attention. Retrying a database write is not the same as retrying a liquid dispense, motor move, valve change, or heat cycle. A duplicate command can be physically meaningful even if the API call looks harmless. Schemas should state whether a command is safe to retry, requires reconciliation, or must be blocked until an operator verifies device state.

Stop-use criteria should be explicit. Good triggers include unexpected motion, telemetry mismatch, calibration failure, repeated timeout, authorization bypass attempt, interlock failure, emergency-stop uncertainty, and operator uncertainty. Once a stop-use trigger fires, the next step is rollback, incident review, and scope revision.

What teams get wrong with AI-controlled physical devices

The first mistake is treating API success as physical success. A 200 response or successful tool call does not prove a motor moved correctly, a valve closed, a sensor calibrated, or a sample remained valid. Physical systems need telemetry, observation, and sometimes independent confirmation.

The second mistake is skipping units, calibration, and coordinate frames. A syntactically valid command can be physically wrong if millimeters become inches, a coordinate frame is device-local instead of workcell-global, or calibration is stale.

The third mistake is testing only happy paths. Physical workflows need fault injection for network interruption, stale telemetry, driver crash, device busy state, command replay, emergency stop, and manual override.

The fourth mistake is confusing interoperability with governance. A shared interface helps devices communicate with an AI system. It does not assign accountability, define approval policy, guarantee observability, or perform incident response. Teams evaluating the control plane can also apply lessons from the Optijara AI in RAN route acceptance test, especially around bounded scope and route-level evidence.

Caveats, Measurement Plan, And Readiness Assessment

There are caveats worth keeping visible. MHS is a limited research preview. Anthropic says it is sharing an early version with partners ahead of making the standard open source, so it should not be treated as a finished public standard today. Device coverage and compatibility will vary. Physical intuition and safety evaluations remain incomplete until proven in the target workflow. Implementation cost can be material. Provider behavior can vary. Operational governance remains necessary even when the interface improves.

{
  "framework": "PDCAT",
  "status": "use for bounded readiness assessment",
  "mhs_status": "limited research preview, not yet open source",
  "required_gates": ["inventory", "schema", "authorization", "limits", "dry_run", "human_approval", "canary", "telemetry", "rollback"],
  "stop_use_triggers": ["unexpected_motion", "telemetry_mismatch", "calibration_failure", "repeated_timeout", "authorization_bypass", "interlock_failure", "operator_uncertainty"],
  "primary_sources": ["https://www.anthropic.com/news/model-hardware-standard-research-preview", "https://www.modelhardwarestandard.com/", "https://modelcontextprotocol.io/specification/2026-07-28"]
}

For teams evaluating AI-controlled lab automation or manufacturing equipment, the practical path is a bounded readiness assessment: define the workflow, build the PDCAT evidence plan, compare against the current integration using local measurements, and design a pilot that can be stopped safely. Shared device interfaces are useful when paired with acceptance evidence, safety boundaries, and rollback discipline. Without that, they are just a cleaner way to ask machinery to do the wrong thing.