Build the foundations together.

Why no single party can solve this

Physical artificial intelligence sits at an awkward intersection. The knowledge needed to make robots genuinely useful is distributed across organisations that do not usually build software together, and each holds a piece that the others cannot obtain on their own.

• Manufacturers know what their machines can actually do, where the envelopes are, and how they fail. None of that is fully written down.
• Operators know which tasks are worth money, what the real exception rate is, and what would have to be true to trust a machine with a job.
• Developers and researchers know how far the methods have come and, more usefully, exactly where they break.
• Safety and standards practitioners know what responsible deployment requires, which is frequently discovered late and expensively by everyone else.

A company that tries to hold all four positions ends up guessing at three of them.

The fragmentation problem

Today each robot is close to a silo. Capabilities are written against a specific machine, validated in a specific place and rarely survive either changing. Every integration is bespoke, every deployment restarts the learning, and improvements stay where they were made.

The cost of that is not only duplicated engineering. It is that evidence does not accumulate. Because there is no shared way to state what a capability does, under what conditions, and how reliably, nobody can build on anyone else's result — including on their own result from the previous site.

What shared foundations would mean

Not a standards committee, and not one company's platform renamed as an ecosystem. Concretely:

• Interfaces for describing a capability, its preconditions, its operating envelope and its failure behaviour, in a form more than one organisation can read.
• Evaluation conventions so "ready" means something comparable across robots and sites, rather than meaning "the demo worked".
• Safety conventions for declaring the conditions under which a capability must refuse to act, with authority left where it belongs.
• Portability so that capability developed for one platform can be attempted on another without starting over.
• Provenance so an improvement can be traced, attributed and, where appropriate, declined.

What the field already learned

This is not the first attempt at shared robotics foundations, and the honest lesson of previous ones is mixed. Common middleware solved a genuine coordination problem and made a generation of research possible; it did not by itself make capability portable, make reliability comparable, or resolve who is responsible when a machine does the wrong thing. Those remain open, and they are the harder half.

Any serious attempt now has to answer the governance questions early rather than after adoption: who decides what goes in, how contributions are licensed, what obligations attach to attribution and redistribution, and what happens to shared work if a commercial sponsor changes direction. Projects that defer those questions tend to resolve them badly under pressure.

What we would contribute, and what we would need

What a software-first venture can reasonably contribute is focus: a specific view of what the capability interface should look like, built against one real robot and one real workflow rather than in the abstract, and a commitment to describing results in a way that can be checked.

What it cannot supply is the hardware ground truth, the operational reality or the safety expertise. Those have to come from people who have them, which is the whole point of the position on this page.

Intended roles, and who is actually here

The three roles above — developers, manufacturers and operators — are intended participants. They describe who would need to be involved for any of this to work.

They are not a list of partners. There are no partners. No organisation has agreed to participate, no arrangement exists with any manufacturer or operator, and there is no logo wall on this page because there is nothing to put on one. Any page that implied otherwise would be describing a different venture.

How a first conversation would actually go

Four steps, in this order, with nothing skipped. The point of writing them down is that each one has an exit, and the first three cost nothing.

1. An initial discussion, non-confidentialWhat you have built or run, what broke, and where you think this framing is wrong. Nothing confidential — no source code, no credentials, no unpublished work under embargo, nothing your employer would object to. Most conversations are useful and end here, and that is a fine outcome.
2. Review of scopeIf there is something concrete worth doing, writing down what it actually is: which capability, on which hardware, measured how, and what would count as it having worked. The capability specification and the integration requirements checklist exist for exactly this step, and you can do it without us.
3. Review of rights and responsibilityWho owns what, what the dependencies oblige, who holds the risk assessment, and who answers the phone afterwards. The licensing checklist covers the questions; the answers belong with your own counsel, not with us.
4. A separate written agreement, if appropriateOnly if the three steps above produced something worth agreeing to. Confidential discussion needs an agreement in place first, not afterwards — so if a conversation needs to become confidential, that is the point at which it stops and the paperwork starts.

There is nothing to sign up to, no waitlist, no programme and no commercial relationship available, because there is no product. support@embodiedsoftwarelabs.com reaches a person.

Where this stands today

No ecosystem exists. There are no partners, no members, no working group, no governance body, no repository and no shared specification. Nothing has been agreed with anyone, and nothing on this website should be read as indicating that it has.

What exists is an argument that this is the right shape for the problem, and an interest in testing that argument against people who would have to live with it. If the argument is wrong, the useful thing is to find out from someone qualified to say so.

Rights, dependencies and data ownership, as questions rather than answers: the software licensing checklist.