---

In September 1969, Neil Armstrong’s flight suit was placed on public record at the Smithsonian. Every stitch, every zipper, every pressure seam — documented, catalogued, available to engineers, historians, and future designers who would need to build on what NASA had learned. This is how science is supposed to work. What you discover in public, you share in public. The knowledge compounds. Fifty-seven years later, a robot walks autonomously through a BMW assembly plant in Spartanburg, South Carolina. It moves with uncanny fluency, picking up sheet metal components, navigating around human workers, and executing repetitive tasks with a consistency that shrugs off fatigue. This is Boston Dynamics’ Atlas, and it is, without question, one of the most sophisticated engineering achievements in human history. But there’s a problem: not a single line of code, not a single actuator curve, not a single control policy from that robot will be shared with the scientific community. We are building extraordinary machines in the dark, and calling it progress.

The Demonstration Economy

The humanoid robotics field in 2026 operates what might fairly be called a demonstration economy. Value is extracted from public awe — from viral videos of backflips and factory tours — rather than from knowledge transfer. Boston Dynamics, Tesla, Figure AI, Agility Robotics, Apptronik: all have achieved genuine technical breakthroughs. None have made those breakthroughs reproducible.

Consider what reproducibility actually requires. When Figure AI’s Figure 02 achieves reliable pick-and-place in BMW’s body shop after ten months of operation, the scientific community wants to know:

• What sensor fusion architecture enabled reliable object detection under variable factory lighting?
• What torque control strategies prevented joint failure under repetitive loading at industrial duty cycles?
• How were safety margins defined for operations near human workers?
• What failure modes were encountered, how often, and how they were handled?
• What learning algorithms, if any, were used to adapt the grasp policy to new object geometries?

None of this is available. What is available is a press release and a demo video. The engineering knowledge that represents thousands of person-years of work — and that could accelerate every subsequent humanoid robotics project by a decade — exists behind corporate walls, protected by NDAs and competitive moats.

This is not a critique of Figure AI’s business model. Corporate IP protection is rational within the current incentive structure. It is, however, a systemic failure of the field.

graph LR
    subgraph Closed["Proprietary Robotics (Current State)"]
        direction TB
        R1[Engineering breakthrough] --> R2[Protected IP]
        R2 --> R3[Demo video + press release]
        R3 --> R4[Knowledge stays inside company]
        R4 --> R5[Next team reinvents same wheel]
    end
    subgraph Open["Open Science Model (Proposed)"]
        direction TB
        O1[Engineering breakthrough] --> O2[Published specification]
        O2 --> O3[Community validation]
        O3 --> O4[Forked improvements]
        O4 --> O5[Compound knowledge growth]
    end
    style Closed fill:#fee2e2,stroke:#dc2626
    style Open fill:#d1fae5,stroke:#10b981

---

The Cost of Closed Systems

The immediate cost of the demonstration economy is duplication. Every university lab, every startup, every national research programme building a humanoid robot in 2026 is, in some significant measure, solving problems that other teams have already solved. Actuator selection, gait control, sensor fusion, manipulation planning — the fundamental engineering challenges of bipedal robots have been encountered and solved (in some form) by every serious player in the field. But because the solutions are not shared, they must be rediscovered.

This is not simply inefficient. It is actively harmful to the pace of progress.

Consider the counterexample of language models. The architecture that underlies every major large language model in 2026 — the transformer — was published in a 2017 paper titled “Attention Is All You Need” by Vaswani et al. at Google. It was open. It was reproducible. Within eighteen months, researchers worldwide had implemented, extended, fine-tuned, and built upon it. The result: a decade of compounding progress compressed into five years.

What would have happened if Google had kept the transformer architecture proprietary? We would still have large language models. But we would have fewer of them, developed more slowly, by fewer teams, with less diversity of approach.

Robotics does not yet have its transformer moment. The Open Humanoid project is an attempt to create one.

---

What “First Principles” Actually Means

The phrase “from first principles” is overused in engineering discourse, often functioning as a rhetorical gesture toward rigour without the substance. In the context of the Open Humanoid project, it has a specific technical meaning.

Building from first principles means:

1. Starting with requirements, not components. We do not ask “what motors are available?” We ask “what performance envelope does a walking robot require?” and derive motor specifications from that. Requirements drive design; availability constrains implementation.

1. Explicit constraint propagation. Every subsystem carries a mass budget, a power budget, a volume allocation, and a cost target. These constraints propagate through the system: adding a sensor affects mass, which affects torque requirements, which affects motor selection, which affects battery capacity, which affects mass. The system is designed as a system, not as a collection of parts.

1. Falsifiable specifications. A specification that says “the robot should be stable” is not an engineering specification. A specification that says “the robot shall maintain balance on flat ground under lateral perturbations of up to 50 Newtons applied for 100 milliseconds, recovering full upright posture within 500 milliseconds, with a failure rate below 1% across 1000 trials” — that is testable, reproducible, and meaningful.

1. Documented failure modes. The specification includes not just success criteria but explicit definition of failure modes and acceptable failure rates. A robot that falls 0.1% of the time in controlled conditions and a robot that falls 0.1% of the time across all environmental conditions are very different systems. The Open Humanoid specification will distinguish them.

This methodology is not new. It is how aerospace systems are built. It is how nuclear facilities are designed. It is how any system where failure has serious consequences is engineered. What is unusual is applying this rigor to a research-grade open robotics project, in public, with every decision documented and justified.

---

The Twenty-Article Architecture

The Open Humanoid project will be documented across twenty articles, each addressing a specific subsystem or integration challenge. The structure follows a systems-engineering approach:

graph TD
    A[System Specification] --> B[Mechanical Architecture]
    A --> C[Actuation System]
    A --> D[Sensing Architecture]
    A --> E[Control Stack]
    B --> F[Structural Materials]
    B --> G[Joint Design]
    C --> H[Motor Selection]
    C --> I[Torque Transmission]
    D --> J[Proprioception]
    D --> K[Exteroception]
    E --> L[Gait Control]
    E --> M[Manipulation Planning]
    E --> N[Perception Pipeline]
    F & G & H & I & J & K & L & M & N --> O[System Integration]
    O --> P[Simulation Validation]
    P --> Q[Open Specification v1.0]

Each article will include:

• Formal requirements — the “shall” statements that define success
• Design decisions — why we chose approach A over approach B, with quantitative justification
• Simulation validation — every design claim validated in a physics simulator before inclusion
• Open Bill of Materials — for hardware subsystems, a costed, sourced BOM that reflects 2026 availability
• Failure mode analysis — what breaks, how often, and how to detect it

The final output is not a paper. It is a complete engineering specification that a competent team could implement — a robot they could actually build, with known performance characteristics and documented failure modes.

---

Why Now?

Three converging factors make 2026 the right moment for this project.

The simulation gap has closed. Physics simulation has reached the point where synthetic-to-real transfer is practical for rigid-body systems. MuJoCo, Isaac Sim, and Genesis (the latter achieving 430,000 simulation steps per second on a single GPU) can run thousands of parameter variations overnight. Design decisions that would have required months of physical testing in 2020 can be validated in hours.

The component ecosystem has matured. Frameless motors with torque densities above 100 Nm/kg, FOC motor controllers with sub-millisecond latency, depth cameras with centimetre-accurate point clouds at thirty frames per second — these are now off-the-shelf, affordable, and available in small quantities. The BOM for a research-grade bipedal robot is no longer a $2M enterprise; it is closer to $50,000.

The AI layer is ready. Whole-body control, sensor fusion, and motion planning were research-grade problems in 2020. In 2026, there are mature software stacks — ROS2, Drake, IsaacLab, Lerobot — that handle the signal processing pipeline well enough to be used as infrastructure rather than research objects. The interesting problems have shifted to higher levels of the stack.

The combination means that a small team with serious engineering rigour can do something that was not possible five years ago: build a complete, simulated, validated humanoid robot system in the open, at a cost and pace that makes public documentation practical.

---

The Simulation Room

The target deliverable for the Open Humanoid project is a simulation room: a physics-accurate virtual environment containing two autonomous humanoid robots.

These robots will:

• Walk at 1.5 m/s on flat ground with less than 2% gait irregularity
• Recover from lateral perturbations up to 50N within 500 milliseconds
• Navigate a 10×10 metre space with static and dynamic obstacles using onboard perception
• Manipulate objects between 0.1 and 5 kilograms using a 7-DOF arm with 40N grip force
• Communicate with each other to coordinate task allocation
• Operate continuously for simulated eight-hour duty cycles without performance degradation

Every one of these targets is specific, measurable, and derived from the requirements of a real-world factory-floor assistant operating safely near human workers.

The simulation room is not the end goal. It is the validation stage. A specification validated in simulation, with documented performance characteristics and failure modes, provides a foundation that physical implementation teams can build on — whether academic labs pursuing research, startups building commercial products, or national programmes developing domestic robotics capabilities.

---

What This Means for the Field

When the Open Humanoid specification is complete and published, it will represent something the field has not had: a fully specified, fully validated, openly reproducible humanoid robot system.

Researchers who want to study gait control will have a baseline robot with known locomotion characteristics to experiment on, rather than building one from scratch.

Students learning robotics will have a complete system to study — not a toy example, but a real-complexity engineering artifact — with every design decision documented and justified.

Engineers at startups will have a reference design they can fork, extend, and adapt — accelerating their development timeline and reducing the probability of basic engineering mistakes.

Policymakers developing national robotics strategies will have an open reference against which to assess commercial claims and set performance benchmarks.

The compounding effect of this kind of open infrastructure is well-documented in software. The Linux kernel, the Python ecosystem, the transformer architecture: each of these created platforms that multiplied the productivity of every team that built on them. The Open Humanoid specification aims to do the same for physical intelligence.

We cannot afford to keep building remarkable machines in the dark.

---

The First Step

The Open Humanoid project begins with a system specification — not a wish list, but a formal engineering specification with explicit constraints, testable requirements, and documented tradeoffs. That specification is the subject of the next article in this series.

What we are building is not just a robot. It is a body of knowledge, made permanent through documentation, made verifiable through simulation, made useful through openness.

The closed robot problem is solvable. The solution is to build in public.

Next in the series: “Specifying the Impossible: A Complete Engineering Specification for an Autonomous Humanoid Robot” — the formal requirements document that governs every design decision in the Open Humanoid project.

---

This article is part of the Open Humanoid series at the Stabilarity Research Hub. All specifications, simulation code, and design documents are published under CC BY 4.0 at hub.stabilarity.com.