§ 01 — SAFETY

Physical AI
done right.

Physical intelligence in life-safety contexts carries a different risk profile than software. We take this seriously at every stage — in research, in field trials, and in our ongoing evaluation processes.

STANDING COMMITMENTS · THE LEDGER
01
Operators always override

Every deployed policy ships with a real-time human-override channel. Operators on scene can halt any action inside the control loop. Override cannot be disabled in software.

How it works
  • Hardware kill path. Override is wired as a physical interrupt, not a software flag. A handheld stop terminates the control loop independent of model state.
  • Always-on watchdog. A separate process external to the model continuously verifies override is responsive; loss of the watchdog itself triggers stop.
  • No software disable. The override path is the only thing on the robot that cannot be turned off from the operator console.
02
Learned safety layer

Our models operate behind a learned safety classifier that screens action sequences before execution. Trained on a separate corpus of unsafe and edge-case scenarios. Validated on held-out environments.

How it works
  • Separately trained from the policy. A classifier built on a corpus of known-unsafe rollouts plus adversarially-curated edge cases.
  • Calibrated to err on the side of refusal. False positives are acceptable. False negatives are not.
  • Versioned alongside the policy. Every policy ships paired with the safety classifier it was validated against.
  • Held-out validation suites. Each task family has a sealed evaluation set the policy and safety layer must pass before deployment.
03
Staged deployment

We do not ship capabilities directly from simulation. Every new task family undergoes structured real-world trials in controlled settings before broader deployment, with independent safety review at each gate.

The gates
  • Gate 1: Sim. Distribution-randomized rollouts at scale; held-out adversarial scenes.
  • Gate 2: Lab. Real-robot trials in a controlled bay. Independent safety reviewer present.
  • Gate 3: Field-controlled. Real environment, on the actual operator’s scene, with a dry-run scope. No live mission.
  • Gate 4: Live, monitored. Real mission, on-scene safety operator present, full session logged.

Independent review at every gate. Failure at any gate sends the task back. We do not skip gates under pressure.

04
Transparent limitations

We publish what our models can and cannot do. We do not overstate capability. If we do not know whether a policy is safe in a given environment, we say so.

What we publish
  • Per-task capability cards. What environments, what failure modes, what we have and haven’t evaluated.
  • Near-misses alongside successes. If a deployment got close to a bad outcome, that’s in the report.
  • Public posture lags shipped capability. We do not market what we have not deployed. We do not market deployments that are still in early gates.
  • Honest about unknowns. “We have not evaluated this” is a valid answer and the one we give when it’s true.
05
Responsible deployment

We work with lawful operators — fire services, EMS, search-and-rescue, and government partners under clear rules of engagement. We screen partnerships and contractually exclude downstream uses that conflict with our mission.

How partnerships are screened
  • Partner review before signature. Mission alignment, oversight regime, legal context.
  • Use-case clauses are contractual. Excluded uses are written into the license, not waved at on a slide.
  • Force decisions stay with humans. Not a marketing line; a license restriction.
  • Termination on misuse. We retain the right (and a documented process) to revoke deployment if downstream use diverges.
06
Red-team independent of model development

We’re building an internal red-team function staffed by researchers independent of model development. Findings are incorporated into model updates and disclosed in our safety reports on a rolling basis.

How red-teaming runs
  • Independent reporting line. The red team does not report to the people whose models they evaluate.
  • Adversarial scope. They look for the failure modes the model team didn’t look for. By design.
  • Disclosure cadence. Findings ship in safety reports on a rolling basis — not bundled into a launch announcement.
  • External access. We invite outside red-teamers under structured access when the work is mature enough to evaluate.
POLICY

Physical intelligence introduces failure modes that do not exist for language or vision models. A misaligned language model produces text. A misaligned physical model can apply force to the world — often in environments where the people around it have no margin for error.

Our safety work is not a separate team or a compliance exercise. It is embedded in how we build. Every capability is developed alongside an evaluation for that capability. We publish our findings regardless of whether they reflect well on us.

REPORTING

We commit to publishing a safety report once we begin field trials, covering deployment incidents, near-misses, red-team findings, and updates to our safety methodology.

If you observe a safety concern with any Vertex research or deployment, we ask that you contact us directly before public disclosure to allow time for investigation.

Questions about our safety approach, responsible disclosure, or deployment partnership screening?
Contact us →