2026 Comparative Analysis: Physical-Device Control Standards for AI Agents — Applied Technology Index

Executive Summary

Physical-device control infrastructure for AI agents is the set of drivers, capability models, communication protocols, safety boundaries, and execution controls that let a model-mediated system observe and operate real equipment. It is not one protocol layer. An agent-readable tool description can make a device easy to invoke while leaving identity, timing, interlocks, emergency stopping, command arbitration, and safe recovery unresolved.

Anthropic announced a research preview of the Model Hardware Standard (MHS) on 27 August 2026. The announcement describes a model-agnostic driver layer for programmable equipment, initially used with scientific and manufacturing partners. An MHS driver exposes simple read and write primitives, standardized discovery, natural-language tags about device characteristics, a generated reference file, and declared safety limits. Agents can reach devices through MCP, a command-line interface, or code APIs. For faster or long-running operations, an agent can package driver commands into deterministic code rather than reason online at every device step.

MHS is an important signal: agent infrastructure is moving below browsers and business APIs into laboratories, robotics, electronics, quantum systems, and production equipment. It is not yet a public, inspectable standard. Anthropic says the early version is being shared with selected partners to develop safety evaluations and best practices ahead of open-sourcing it. No public normative specification, conformance suite, threat model, wire schema, authorization profile, timing guarantee, or independent interoperability result was available in the reviewed materials.

Established device standards address adjacent layers:

OPC Unified Architecture (OPC UA) supplies a broad industrial information model, typed AddressSpace, discovery, methods, events, subscriptions, client-server services, PubSub, sessions, transport protection, application authentication, user authorization, and auditing. It is the strongest reviewed foundation for semantically rich industrial assets and governed operational-technology integration.
ROS 2 supplies a distributed robotics graph built around topics, services, and long-running actions. Actions include feedback plus cancellation or preemption; DDS-backed Quality of Service (QoS) controls reliability, durability, deadlines, liveliness, and history. DDS Security can add participant authentication, encryption, integrity, and graph-wide access controls, but ROS 2 documentation says security is off by default unless explicitly enabled and can fail open unless the strategy is set to Enforce.
SiLA 2 is purpose-built for laboratory automation. Its HTTP/2-based client-server design exposes device behavior as Features containing Commands and Properties. Its public materials cover discovery, data types, error handling, security and authentication, traceable command results, and a server-initiated connection method for instruments inside restricted laboratory networks.
SCPI provides a hardware-independent ASCII command language for programmable test instruments. It is transport-independent and widely useful for deterministic read/query/write operations, but it is a command vocabulary rather than a complete discovery, semantic modeling, authorization, safety, orchestration, or agent-governance system.

These approaches are not interchangeable competitors. MHS is an emerging agent-facing driver and metadata proposal. OPC UA is an industrial interoperability stack. ROS 2 is robotics middleware. SiLA 2 is a laboratory automation standard. SCPI is an instrument command language. A production system may compose them: an MHS- or MCP-facing adapter can sit above an OPC UA server, ROS 2 action server, SiLA 2 server, or SCPI instrument.

The central finding is that agent accessibility should terminate above the real-time and safety-critical control loop. The model can choose a validated procedure, set bounded parameters, inspect results, or request a state transition. A deterministic controller should enforce units, ranges, rate limits, sequencing, mutual exclusion, watchdogs, collision envelopes, interlocks, emergency stops, and fail-safe state. Safety must remain effective if the model, prompt, network, agent runtime, tool description, or adapter is wrong.

Key findings

Discoverability is not permission. A machine-readable capability catalog tells an agent that an operation exists; it does not establish that this user, workload, experiment, time window, or machine state authorizes the operation.
Natural-language metadata is useful context but weak control logic. Weight, reach, temperature limits, hazardous materials, or calibration notes can help planning. Safety constraints that protect people or equipment should also be represented and enforced in deterministic, testable logic.
Read and write primitives are an integration floor, not a universal device model. Long-running operations need goal identity, progress, cancellation, completion, error state, timeout, and recovery semantics. Coordinated equipment also needs reservation and command-arbitration rules.
ROS 2 Actions have the clearest reviewed long-running robot-operation shape. They model a goal, feedback, result, and cancel or preempt behavior. That does not by itself make a motion safe or exactly-once.
OPC UA has the broadest reviewed operational-governance surface. Its specifications separate discovery, secure channels, sessions, subscriptions, methods, alarms/events, PubSub, information models, authorization, and audit. Deployment profiles and companion models still determine actual interoperability.
SiLA 2 is the closest established domain analogue for laboratory equipment. Feature definitions, commands, observable properties, traceable results, and cloud-oriented connection patterns solve more lab-specific interoperability than an untyped tool wrapper.
SCPI remains valuable at the adapter edge. Its simple ASCII vocabulary can control a large class of instruments over several transports. An agent platform must add inventory, identity, concurrency, validation, lifecycle, and safety around it.
Protocol security and physical safety are different. Authentication, encryption, and authorization can stop an untrusted caller. They do not prove that an authenticated command is safe for the current physical state.
A deterministic script is safer than token-by-token control only when its envelope is verified. Compiling a procedure can reduce model latency and variability, but the script must be validated, signed or versioned, simulated where appropriate, parameter-bounded, supervised, and stoppable.
The safest abstraction is a bounded capability, not unrestricted device I/O. Prefer run_validated_assay(protocol_id, bounded_parameters) or move_to_approved_pose(pose_id) over arbitrary register writes, shell access, or raw motion commands.

Methodology

This analysis reviewed public primary technical materials available on 4 September 2026. The live Applied Technology Index research index and the local public research collection were checked before topic selection. Existing research covered tool gateways, agent sandboxes, human approval, runtime policy, asynchronous tasks, persistent workspaces, attestation, and workload identity, but not the device-protocol boundary for agents operating physical equipment.

Recent public discussion was used only to identify Anthropic’s MHS announcement as a frontier signal. Claims about MHS were grounded in Anthropic’s dated announcement. Claims about adjacent standards were grounded in current OPC Foundation specifications, ROS 2 project documentation, SiLA standards materials and documentation, and the IVI Foundation’s SCPI overview. Marketing case-study outcomes were not treated as independently reproduced benchmarks.

The approaches were assessed on twelve criteria:

Primary domain: general physical devices, industrial automation, robotics, laboratory automation, or test instrumentation.
Abstraction: driver primitive, typed information model, robotics graph, behavioral feature, or command language.
Discovery: how clients find devices, endpoints, capabilities, types, features, topics, or commands.
Operation model: reads and writes, methods, actions, commands, properties, queries, or scripts.
Long-running work: goal identity, feedback, cancellation, preemption, completion, and recovery.
Telemetry: polling, subscriptions, topics, events, result streams, or instrument queries.
Semantics: types, units, capability descriptions, companion models, feature definitions, or natural-language metadata.
Communication controls: reliability, durability, ordering, deadlines, liveliness, sessions, and reconnect behavior.
Cybersecurity: identity, authentication, encryption, integrity, authorization, security policy, and audit.
Physical-safety boundary: declared limits versus deterministic enforcement, interlocks, fail-safe behavior, and emergency control.
Agent fit: direct model-facing description, adapter suitability, MCP exposure, planning context, and bounded execution.
Maturity: research preview, versioned public specification, implementation ecosystem, and conformance evidence.

This is a documented-capability analysis. No MHS preview access was obtained. No device driver, OPC UA stack, ROS 2 graph, DDS Security deployment, SiLA 2 server, SCPI instrument, MCP server, robot, microscope, liquid handler, laser, programmable power supply, or safety controller was operated. The analysis therefore does not measure integration time, command latency, jitter, maximum update rate, fault recovery, interoperability, certification, safety integrity, adapter correctness, or model performance.

The comparison deliberately evaluates architectural roles rather than declaring one universal winner. A manufacturing cell, mobile robot, automated assay line, and bench instrument have different timing, semantic, regulatory, and safety requirements.

Comparative Analysis Table

Approach	Primary abstraction and transport	Discovery and semantics	Long-running work and telemetry	Security and safety boundary	Best fit	Main limitation for AI agents
Anthropic Model Hardware Standard research preview	Standardized driver with simple read/write primitives; exposed through MCP, CLI, and code APIs according to the announcement	Standard-format device discovery; natural-language tags and generated reference material describe characteristics, adjustable values, measurements, and safety limits	Agents can monitor operating data and sequence devices; generated code can chain commands for faster or longer-running execution	Announcement says drivers identify limits that will be enforced and the preview will develop safety evaluations; public normative security, authorization, fail-safe, timing, audit, and conformance details were not available	Rapidly making heterogeneous programmable lab and manufacturing devices legible to model-mediated workflows	Research-preview evidence is supplied by its developer; not yet open source; no public specification or independent interoperability and safety evaluation
OPC UA	Typed AddressSpace plus client-server Service Sets and PubSub; multiple standardized transport and encoding profiles	Discovery services, endpoints, Nodes, Objects, Variables, Methods, Events, types, Views, companion specifications, and metadata	Methods and Programs for operations; MonitoredItems, Subscriptions, Events, Alarms and PubSub for data; sessions and status codes support managed interactions	Secure channels, application certificates, sessions, user identity, authorization, transport and message security, and auditing are specified; machine safety remains a controller and system-engineering responsibility	Industrial assets, process equipment, manufacturing systems, and cross-vendor operational data with rich semantics	Large profile surface and deployment complexity; companion-model quality varies; an agent adapter still needs bounded tools, policy, prompt-injection defenses, and physical-state validation
ROS 2	Distributed graph of nodes using topics, services, and actions over an RMW implementation, commonly DDS	Automatic graph discovery; strongly defined message, service, and action interfaces; semantics depend on packages and conventions	Actions model long-running goals with feedback, result, cancellation, and preemption; topics carry streams; QoS covers history, reliability, durability, deadlines, lifespan, and liveliness	DDS Security can provide authentication, encryption, integrity, and access control through enclaves; official docs state security is off by default and non-enforcing configuration can launch without protection; functional safety is outside basic ROS 2 communications	Robots, autonomous machines, sensors, actuators, navigation, perception, and high-rate distributed systems	Dynamic graphs and powerful actions create a broad attack and failure surface; QoS mismatch can prevent communication; deterministic and safety-certified control generally needs separate components
SiLA 2	HTTP/2-based client-server standard organized as Core, Mapping, and Features	SiLA Discovery plus Feature definitions; Features expose typed Commands and Properties and emphasize device behavior rather than transport internals	Commands return complete, traceable results; Properties can be read or subscribed to; server-initiated connections support cloud access from isolated lab networks	Public Core scope includes security and authentication; certificates and deployment policy protect communication, while instrument safety and workflow validation remain implementation responsibilities	Laboratory instruments, LIMS and ELN integration, assay automation, sample handling, and multi-device lab workflows	Domain-specific rather than universal; Feature consistency and device support determine interoperability; no built-in reason to trust model-selected parameters or procedures
SCPI	Hardware-independent ASCII command language built on IEEE 488.2 concepts; messages can travel over GPIB, serial, VXIbus, LAN, and related instrument interfaces	Common hierarchical command vocabulary and instrument-specific command trees; little network-level discovery or rich cross-device semantic modeling in SCPI itself	Queries and commands support deterministic instrument interaction; operation status and instrument-specific mechanisms can report state, but workflow orchestration is external	Pure software command standard; transport, authentication, encryption, authorization, concurrency, audit, and physical limits must be supplied by the instrument or surrounding system	Programmable test and measurement equipment, especially where direct deterministic commands are already supported	Easy to wrap but easy to overexpose; raw strings give an agent little standardized information about units, hazards, permissions, reservations, or multi-device lifecycle

Observed Profiles

MHS: an agent-facing physical-device adapter in research preview

Anthropic describes MHS as a shared specification and standardized driver for AI agents operating physical devices. The driver translates between the host system and equipment, exposes simple operations such as reading a temperature or writing a temperature setting, and publishes devices in a standard format for discovery across networks.

The agent-facing context is distinctive. MHS tags can carry natural-language information that ordinary code may not reveal, such as a robot arm’s weight or other machine characteristics. The driver uses those tags to produce a reference file describing what a device measures, what can be adjusted, and which safety limits will be enforced. MCP, command-line access, and code APIs then provide three control surfaces above the driver.

This is a useful response to an agent-specific integration problem: a model needs both callable operations and context sufficient to select them. A conventional driver API may expose set_position(x, y, z) without explaining reference frames, payload, collision zones, calibration state, approach direction, or which states permit motion. Structured metadata can reduce that knowledge gap.

The same feature creates a trust boundary. Natural-language tags can be stale, ambiguous, incomplete, or modified by a compromised administrator or agent. A model may also interpret them incorrectly. A production design should separate:

descriptive metadata for planning and explanation;
typed operational constraints for validation;
enforced invariants inside the adapter, controller, safety PLC, or device;
independent physical protection such as interlocks, guarded zones, emergency stops, pressure relief, or hardware travel limits.

Anthropic’s announcement says MHS reduces integration from weeks or months to hours or minutes and describes early uses at partner organizations. Those are developer-reported preview observations, not controlled comparative measurements. The announcement also says MHS is being shared with an initial group ahead of open-sourcing. Until the actual specification and implementations are public, evaluators cannot independently determine whether two MHS drivers interpret discovery, units, limits, errors, cancellation, concurrency, or identity in the same way.

MHS’s deterministic-code path is architecturally important. A model can explore, then package a learned sequence into code that executes without online reasoning at each step. This can improve speed and repeatability, but it transfers risk into generated code. The execution gate should validate the exact script, device inventory, parameter envelope, dependencies, estimated duration, stop conditions, and code digest. A previously approved script should not silently gain authority over a newly mapped instrument.

OPC UA: a semantic and security-rich industrial foundation

OPC UA models an industrial system as an AddressSpace of typed Nodes and References. Objects can expose Variables, Methods and Events; types define reusable semantics; Views select relevant subsets. Companion specifications can standardize domain models above the Core specification. This is richer than presenting every device as generic reads and writes.

The service architecture also separates concerns. Discovery Services locate servers and endpoints. SecureChannel Services protect messages between applications. Session Services bind an application-level interaction and user context. Attribute, Method, MonitoredItem, Subscription, Query and NodeManagement services provide different operations over the AddressSpace. Status codes make failures machine-readable.

For telemetry, a client can create MonitoredItems and Subscriptions rather than continuously asking an agent to poll. OPC UA PubSub adds publisher-subscriber communication through brokerless or broker-based middleware and defines DataSets, metadata, network messages, security groups, message security and transport mappings. This is valuable when many consumers need machine data without establishing a separate model-mediated loop for each reading.

OPC UA’s security model is broader than a TLS wrapper. The reviewed specification includes application authentication, secure channels, user identity, authorization, transport security and audit concepts. That breadth does not make every server secure by default. Operators still choose profiles, certificates, trust lists, user mappings, permissions, endpoint exposure, audit destinations, patching and network segmentation.

For agent integration, the safest pattern is not to mirror the complete AddressSpace into a model tool catalog. An adapter should expose a risk-classified subset:

read-only state and alarms;
bounded parameter changes;
validated Methods or Programs;
privileged maintenance operations available only through a separate workflow;
raw node writes withheld unless an engineered use case requires them.

The adapter should preserve OPC UA identity and audit context rather than making every agent call appear as one shared service account. It should also bind units and data types before values reach the model. A plausible number without its engineering unit, timestamp, quality status, source, and calibration context is not a safe observation.

ROS 2: explicit actions and configurable communication behavior

ROS 2 divides interactions into topics for streaming data, services for shorter request-response operations, and actions for long-running remote procedures. The official Actions documentation defines an action as a long-running procedure with feedback and the ability to cancel or preempt a goal. An action server accepts the request, performs the work, emits progress, and returns a result.

That lifecycle is a strong fit for model-mediated robotics because a command such as navigation cannot be represented honestly as an immediate success. An agent can submit a goal, observe feedback, cancel when the environment changes, and wait for a terminal result. The action result still does not prove the intended physical outcome; safety sensors, controller state, and task-specific verification remain necessary.

ROS 2 QoS profiles let publishers and subscribers choose history, queue depth, reliability, durability, deadline, lifespan, liveliness, and lease duration. This is critical for physical systems. Camera frames may favor freshness over guaranteed delivery, while a configuration command may require reliable delivery. The official documentation warns that incompatible requested and offered QoS profiles can prevent any connection.

The service profile documentation contains an especially relevant warning: volatile durability is important because a restarted service server could otherwise receive old requests, and the server is not inherently protected from repeating side effects. An agent adapter therefore needs request identity and idempotency even when the middleware is reliable. Reliable delivery is not exactly-once physical execution.

ROS 2 Security uses DDS Security plugins to provide authentication, encryption, integrity and access controls. Policies are packaged into security enclaves that can map to processes, users or devices. The operational defaults matter: ROS security must be explicitly enabled, and the documentation says a participant with bad configuration can launch without protection unless ROS_SECURITY_STRATEGY is set to Enforce.

A model-facing ROS bridge should therefore:

expose selected actions and read-only topics rather than arbitrary graph access;
launch inside a least-privilege security enclave;
require enforcing security configuration in production;
validate frames, units, joint and workspace bounds;
cap goal duration and velocity;
define cancel acknowledgment and safe-stop behavior;
separate high-level planning from real-time control;
record goal, feedback, result, cancel, controller and safety events under one correlation ID.

SiLA 2: domain behavior and traceable laboratory commands

SiLA 2 is designed around laboratory device behavior. Its public overview says the standard is based on HTTP/2 and concentrates on functionality rather than device type or underlying communications. The specification is organized into Core, Mapping and Features. A SiLA Server implements Features; each Feature exposes Commands with parameters and Properties that clients can read or subscribe to.

This is close to what an agent needs from scientific equipment: discoverable capabilities, typed operations, observable state and complete results. It is also closer to laboratory vocabulary than a generic industrial object model or robotics graph. A LIMS, ELN, scheduler or agent can coordinate a plate handler and reader through explicit device behaviors rather than reverse-engineering serial strings.

SiLA 2 version 1.1 adds a server-initiated connection method. The standards page describes use cases including cloud connection for lab instruments, access across isolated laboratory and corporate networks, and simpler certificate management. Outbound establishment can reduce inbound exposure, but it does not remove the need for mutual identity, authorization, tenant isolation, endpoint pinning, revocation and egress policy.

The public materials say command execution returns complete and traceable data describing what happened. Agent systems should preserve that structured result rather than converting it immediately into an uncited model summary. The authoritative result should be linked to sample IDs, protocol versions, instrument identity, calibration, operator or agent identity, timestamps and downstream records.

SiLA Feature definitions can also provide a safer agent surface than arbitrary low-level access. The remaining challenge is parameter semantics and workflow safety. A syntactically valid command can still contaminate a sample, exceed a validated method, use expired consumables, conflict with another reservation, or create an unsafe combination across devices. Laboratory policy, inventory, scheduling and instrument interlocks remain separate layers.

SCPI: deterministic instrument vocabulary at the adapter edge

The IVI Foundation describes SCPI as a common interface language between computers and test instruments. SCPI is an ASCII software standard built on IEEE 488.2 concepts, independent of hardware and transport. The same command strings can be used from common programming languages and carried over interfaces including GPIB, serial, VXIbus and LAN.

This simplicity is an advantage for deterministic adapters. A well-tested service can translate measure voltage on channel 2 into the exact SCPI sequence required by a supported instrument, parse the response, attach units and quality metadata, and return a typed value. Existing laboratories and test benches do not need to replace every instrument to become agent-accessible.

Directly exposing arbitrary SCPI strings to a model is a poor default. The model may select the wrong subsystem, omit termination or synchronization steps, confuse query and set commands, change output state, or issue a device-specific command that behaves differently from another vendor’s implementation. A safer adapter provides named, typed operations backed by allow-listed command templates.

SCPI also does not solve fleet discovery, reservations, command ownership, access control, encrypted transport, audit, long-running workflow state or physical safety by itself. Those controls belong around the command channel. Where a device supports only SCPI, the adapter becomes the policy enforcement point and should be treated as consequential infrastructure rather than a formatting helper.

A layered production architecture

A production physical-agent stack should make each layer explicit:

Asset and device layer. Maintain authoritative identity, model, firmware, calibration, physical location, capabilities, hazards and ownership for each instrument or machine.
Native control layer. Use OPC UA, ROS 2, SiLA 2, SCPI, a vendor API, PLC logic or another device-native interface appropriate to the domain.
Deterministic safety layer. Enforce interlocks, ranges, rate limits, units, state transitions, reservations, watchdogs, safe stop, emergency behavior and local operator priority without depending on model compliance.
Capability adapter. Translate native operations into a small set of typed, bounded capabilities. Version schemas and map every capability to its native command, controller and safety assumptions.
Identity and policy layer. Authenticate user and agent workload separately; authorize device, action, parameter range, environment, time and purpose; require approval where policy demands it.
Agent-facing layer. Publish descriptions through MCP or another tool interface. Treat all retrieved manuals, labels, sample text and device-generated strings as untrusted data rather than executable instructions.
Workflow layer. Persist operation identity, state, timeout, cancellation, retry and compensation. Never infer exactly-once execution from a lost response.
Evidence layer. Record request, normalized parameters, capability and adapter versions, identity, policy decision, approval, native command IDs, telemetry, alarms, terminal result and independently observed outcome.
Reconciliation layer. Compare the requested procedure with device state, sample records, inventory, quality checks and final business or scientific records.

This architecture lets MHS coexist with established standards. An MHS driver could describe and expose an OPC UA Method, a ROS 2 Action, a SiLA 2 Command or a bounded SCPI template. The adapter should not erase the stronger semantics and controls of the underlying system.

Evaluation checklist

Ask a physical-agent platform or device adapter:

Is the implementation based on a public MHS specification, a private preview, or only the announcement’s concepts?
What exact OPC UA release and profiles, ROS 2 distribution and RMW, SiLA 2 version and Features, or SCPI command set are supported?
How is every physical device identified independently of a user-editable display name?
Are units, frames, coordinate systems, valid ranges, uncertainty, calibration and data quality machine-readable?
Which constraints are descriptive metadata, which are validated in software, and which are enforced by independent hardware?
Can a model bypass the bounded adapter through shell, raw network, serial, vendor SDK, maintenance interface or another MCP tool?
How are user identity, workload identity, device identity and represented authority recorded separately?
Does each consequential request have a stable idempotency key and native-device correlation ID?
What happens when the request succeeds but the response is lost? Can a retry repeat physical work?
How are devices reserved, locked and released across multiple agents, humans and controllers?
How are stale telemetry, incompatible QoS, clock drift, network partitions and device reconnects represented?
Can long-running operations report progress, accept cancellation, confirm safe stop and produce a terminal result?
Which actions require human approval, and does the approval bind the exact device, parameters, code digest and expiry?
Are generated scripts statically checked, simulated, versioned, signed, bounded and independently stoppable?
How are prompt injection and malicious text handled in manuals, sample names, logs, labels and device metadata?
Is transport security enforced rather than optional, and does misconfiguration fail closed?
Which audit fields originate from the device or controller rather than the agent runtime?
How are emergency stop, operator takeover and local manual control prioritized over agent commands?
What independent interoperability, fault-injection, hazard-analysis and physical-safety testing has been completed?
Which claims are standards conformance, vendor testing, partner reports, certification or only design intent?

Limitations

This analysis reflects public materials available on 4 September 2026. MHS was a selected-partner research preview. Anthropic had announced an intention to make the standard open source, but the reviewed announcement did not provide a public normative specification, source repository, schema, protocol version, license, test vectors, driver certification process, security profile or independent safety report. Conclusions about MHS are therefore necessarily narrower than conclusions about the published standards.

Anthropic’s integration-time and partner-outcome statements were not independently reproduced. They may reflect selected devices, expert support, prepared environments, prototype drivers or task-specific conditions. This article does not use those statements as comparative performance evidence against OPC UA, ROS 2, SiLA 2 or SCPI.

The compared technologies occupy different layers and domains. OPC UA’s specification suite and companion ecosystem are much broader than the sections reviewed. ROS 2 behavior varies by distribution, RMW implementation, DDS vendor, package and deployment. SiLA 2 interoperability depends on supported Features and implementations. SCPI instruments commonly add vendor-specific commands and transport behavior.

No physical system was tested. Documentation cannot establish safe behavior under sensor failure, actuator saturation, stale state, network partition, duplicate command, race condition, controller restart, calibration error, corrupted metadata, malicious prompt content, adapter compromise, human intrusion, emergency stop, or simultaneous control by several clients.

Cybersecurity features are not functional-safety certification. This analysis does not determine compliance with IEC 61508, IEC 62061, ISO 13849, ISO 10218, ISO/TS 15066, IEC 62443, FDA requirements, good laboratory practice, good manufacturing practice, or any jurisdiction-specific safety or regulatory regime. Applicable obligations depend on the equipment, process, environment, risk classification and implementation.

The presence of a safety limit in metadata does not prove that the limit is complete, correctly encoded, enforced at the right layer, resistant to bypass, or sufficient for a hazardous operation. Independent hazard analysis and qualified engineering remain necessary.