Build with us ↗A proposed ecosystem for discovering, licensing, deploying, and improving robot capabilities.
We aim to organize software by the work it performs, the hardware it supports, and the evidence behind it. Each capability would include a defined scope, commercial terms, operating requirements, and support responsibilities.
A common commercial experience does not mean identical robot control. Our architecture vision depends on platform-specific integrations, manufacturer-approved interfaces, and validation for each supported machine.
The planned lifecycle layer would connect version history, authorized updates, compatibility records, and operational evidence. Physical safety controls remain part of the robot and deployment design.
This is a pre-product platform vision. No runtime, capability library, robot integration, or production service is currently released by this venture. Supporting one machine does not establish support for another.
A robot capability is not a model file. It is a model together with the conditions it assumes, the hardware it was tuned against, the envelope it is safe inside, the way it fails, and the evidence that it works. Today almost all of that lives in the heads of the team that built it, which is why capability does not travel.
A platform for physical artificial intelligence is, at bottom, an attempt to make that whole package portable: to let a capability be found, understood, licensed, put onto a machine, watched in operation, and improved, without being rebuilt each time.
Finding a capability is the easy-sounding part that is actually a specification problem. To be discoverable, a capability has to be described in terms an operator can match against a task and an engineer can match against a machine: what it does, on what hardware class, with what sensing, in what environmental conditions, at what reliability, with what human involvement required, and what it does when it cannot proceed.
Most of those fields have no agreed vocabulary today. Producing one that is honest rather than flattering is a large part of the work.
Capability built by one party and run by another raises questions that robotics has mostly deferred. What is being licensed: weights, a pipeline, a validated configuration, or an outcome? What happens when a capability is improved using data generated at a customer's site? Who may redistribute, and on what terms does attribution attach? What open-source obligations travel with components inside it?
These need answering before adoption rather than after, because terms applied retroactively to work people have already contributed tend to end badly.
Getting software onto a machine that moves is not the same as shipping to a server. Versions have to be known precisely, rollout has to be staged, rollback has to be immediate and tested, and the machine has to be able to refuse an update that would put it outside its validated envelope.
Deployment also has to carry the safety conditions with it. A capability that is correct in a laboratory and unconditioned in a workplace is not a capability; it is a liability with good benchmark scores.
The reason a shared layer is worth building at all is that improvement should compound. An exception handled better at one site should be able to reach the others, which requires the data to be collected, the change to be attributable, the regression risk to be measurable, and the operator to have a say in whether their data contributes at all.
Without provenance and consent this becomes extraction rather than an ecosystem, and operators are right to refuse it.
The four stages above are a conceptual architecture, not a product. Drawing them is easy; the part that decides whether any of it is workable is where responsibility sits at each stage — because a shared layer that leaves a boundary vague has not removed the work, only moved the argument.
This is the proposed division. It is a position to disagree with, not a specification, and nothing here has been validated by operating it.
| Stage | The capability author | The shared layer | The operator | Nobody yet |
|---|---|---|---|---|
| Discover | States what it does, on what hardware, within what limits, and what it does when it cannot proceed. | Holds the vocabulary those statements are made in, and refuses incomplete ones. | Decides whether the stated limits match the task in front of them. | Deciding whether a stated limit is true. No mechanism proposed. |
| License | Declares rights in code, weights, training data and configuration separately. | Carries those declarations with the capability so they cannot be lost in transit. | Reads them before agreeing, and names what the deployment produces. | Resolving a conflict between two declarations. That is a legal question, not a platform feature. |
| Deploy | Says which versions were validated together, and against what evidence. | Refuses a combination the author never validated, and makes rollback immediate. | Owns the risk assessment, the safety-rated equipment and the acceptance decision. | Re-validating after a firmware change nobody announced. Currently nobody watches for it. |
| Improve | Describes what an improvement changes and what it might regress. | Carries provenance, and makes contribution a decision rather than a default. | Decides whether their site's data contributes at all, and may say no. | Judging whether an improvement is safe on a robot it was not developed on. |
The fourth column is the honest one. Every row has something in it, and each of those gaps is a reason this is a proposal rather than a plan.
Not all of the above. The only sensible first move is narrow: one supported robot, one valuable workflow, integrated against interfaces the manufacturer already publishes, with acceptance criteria written in advance and results described in a way an outsider can check. Everything general has to be earned from something specific that worked.
None of this is built. There is no platform running, no capability catalogue, no licensing mechanism, no deployment system, no telemetry pipeline, no account and no software to download. The tabs, diagrams and labels on this website illustrate a vision; they are not screenshots of a system and no part of this site is a demonstration.
What exists is a considered position about where the leverage sits and what order the work should be attempted in. Testing that position against people who build robots, make robots, or run them is the current objective.
A proposal for how one capability would be described: the robot capability specification template.
Before agreeing to any of it: the software licensing checklist — what to collect, and what to take to a lawyer.
What the Deploy stage above would actually require of a release: the deployment and rollback checklist.