Consumer humanoid robots are finally moving into people's homes.

Nearly every company demonstrates the same thing: folding laundry. Not because laundry matters, but because it's proof that an LLM is making decisions that move real objects around a house.

Once an AI can decide what to pick up, where to walk, and what appliance to use, we're no longer talking about software permissions. We're talking about delegated physical authority.

The problem is that we don't have an open standard for that.

Today every company is inventing its own answers to basic questions. When should a robot ask permission? What counts as consent? How is consent revoked? What should it refuse to do? What happens if it's wrong about who it's interacting with?

Most AI safety work ends at the digital boundary. We have benchmarks for agents using tools, but almost nothing for agents acting on the physical world.

I think that's about to matter.

This project builds the missing layer as an open standard.

The outputs are straightforward:

* A schema that defines what an embodied AI is allowed to do, what requires consent, and how that authority can be revoked.

* A proposed MCP profile for physical-world tools.

* A public harm taxonomy for embodied AI mapped to the NIST AI RMF.

* A validation showing an LLM-controlled household robot performing a normal task while every action is allowed, blocked, or consent-gated and logged.

What does an AI need to know, ask, remember, refuse, and escalate before we trust it to physically act inside someone's home?

## What the grant funds

The minimum budget publishes the authority standard, MCP profile, harm taxonomy, and a complete simulation validation using a digital twin.

The full budget adds validation on a shipping consumer humanoid. The current plan is Weave's laundry-folding robot, with a rented Unitree G1 as a fallback. Every run is pre-registered, fully logged, and published regardless of the outcome.

If the approach turns out to be incomplete, that's still useful. I'd rather publish exactly where the abstraction breaks than quietly adjust the design until it passes.

## Why me?

I've spent most of my career working on trust and safety problems before standards existed.

That includes platform security at the US Department of Justice, safety products at Uber (including Uber Teens), invited safety testing for Anthropic, and now robotics at Tethral.

Tethral already operates an MCP host used by more than 200,000 people and maintains a digital-twin testing platform with over 800 connected devices, so this project builds on infrastructure we already have rather than starting from scratch.

We've also published open safety research before. Our last project, Shapestate, used pre-registered predictions and published every result—including the ones that proved us wrong. This project follows the same philosophy.

## Risks

The biggest risk isn't that the project fails, it's that consumer robots become normal before there's an open, vendor-neutral way to describe what they're actually allowed to do.

If this standard never gets adopted, at least there will be something public for companies, researchers, and regulators to argue with and improve.

Right now there isn't, or what is there is held behind IP firewalls.

## Funding

Tethral has raised about $450,000 over the past year through debt financing and a SAFE. None of that funding supports this work. This grant would be used exclusively for the open standard, validation, and public deliverables.