Shape Compiler

# From intent to geometry.

The Shape Compiler is the control layer. It is how a shape you want becomes thousands of cell states, and how those states become a form you can check.

Control layer

## Six stages between a request and a held shape.

1. **Intent.** What the surface has to do: support this part, take this curve, stow this way.
2. **Geometry model.** The target shape, expressed as a surface.
3. **Compiler.** Maps the target onto the cell grid, cell by cell.
4. **State map.** One commanded state for every ShapeCell.
5. **Proteus.** The dock drives and latches the cells.
6. **Verified form.** The physical result, checked against the target.

> **Architecture:** Describes the design. Not a measured Nanoshape result. Source: Nanoshape design specification, September 2026.

Operating principle

## Encode. Select. Actuate. Latch. Aggregate. Verify.

1. **Encode.** The compiler turns a target geometry into a map of cell states and a switching sequence, scheduled in passes. Cells are coupled through the sheet. Switching one shifts its neighbours’ switching thresholds, so the order of passes matters.
2. **Select.** The compiler selects a set of cells.
3. **Actuate.** An external magnetic field switches the selected cells.
4. **Latch.** Switched cells settle into their other stable geometry and hold it mechanically.
5. **Aggregate.** Local states add up to strain, curvature and folds across the connected sheet.
6. **Verify.** The formed shape is measured and compared with the target.

> **Architecture:** Describes the design. Not a measured Nanoshape result. Source: Nanoshape architecture specification, August 2026.

Interactive

## Dock it. Choose a shape. Watch it compile.

**What you are looking at**

- This is a visualisation of the operating principle, not a recording of hardware.
- The programs on this page were compiled ahead of time with a simplified forward model and a bounded local search.
- Pass order on this page is chosen so every intermediate shape is physically valid. Neighbour-threshold coupling is not modelled.
- Residual maps are simulated. They are not measured results.
- Cell internals are not drawn; the cell geometry is still a design variable.
- Calibrated state-to-shape mapping is in scope. Inverse design at large cell counts is open.

> **Visualisation:** Shows the operating principle. Not a recording of hardware. Source: Nanoshape architecture specification, August 2026.

R1 targets single-curvature forms: cylinders, wedges and folds.

**The saddle.** Double curvature needs the sheet’s in-plane lengths to change, not only to bend. That’s why in-plane strain is part of the cell design, and why double-curvature forms are a research target rather than an R1 commitment.

> **Open problem:** Not solved. Part of what the program is built to answer. Source: Nanoshape architecture specification, August 2026.

Today and next

## What runs today, and what is roadmap.

*Status of each part of the Shape Compiler*

| Capability | Status | Notes |
| --- | --- | --- |
| Target geometries to state maps | Runs today, in this visualisation | Each target is encoded into a map of cell states, compiled ahead of time with a simplified forward model. |
| Pass scheduling | Runs today, in this visualisation | The switching sequence is grouped into passes, and every frame of the path is checked, not only the end. |
| Calibrated state-to-shape mapping | In scope, current program | Measuring how commanded states become physical shape on real cells. |
| Verification against target | In scope, current program | Checking formed geometry against the geometry model. |
| CAD to state map | Roadmap | Arbitrary part geometry in, state map out. |
| Inverse design at large cell counts | Open problem | Finding the best state map for a target shape when there are very many cells. |

> **Open problem:** Inverse design at large cell counts remains open, and is one of the things the program is built to answer. Source: Nanoshape design specification, September 2026.

Questions

## Short answers.

### What does the Shape Compiler do?

The Shape Compiler is the control layer for Proteus. It is designed to take intent to a geometry model, then to a state map with one commanded state for every ShapeCell, then to Proteus on the Shape Dock, then to a verified physical form, and to schedule the switching in passes, because cells are coupled through the sheet and the order of passes matters.

### What shapes can Proteus form in R1?

In R1, Proteus targets single-curvature forms: cylinders, wedges and folds. That is a design target, not a measured result. Double curvature, such as a saddle, needs the sheet’s in-plane lengths to change, not only to bend, so double-curvature forms are a research target rather than an R1 commitment. R1, programmable surfaces, is the funded scope.

> **Design target:** What the design is built to do. Not yet measured on Nanoshape hardware. Source: Nanoshape engineering, October 2026.

### What is still an open problem?

Inverse design at large cell counts is an open problem for the Shape Compiler: finding a state map that produces a target shape when there are very many cells. It remains open, and it is one of the things the program is built to answer. Double-curvature forms are a research target, and R2 and R3 are research tiers outside the funded scope.

> **Open problem:** Not solved. Part of what the program is built to answer. Source: Nanoshape design specification, September 2026.

---

Canonical: https://www.nanoshape.ai/compiler  
Last updated: 2026-10-06

Figures on this site are design targets or architecture descriptions, not measured results. Inverse design at large cell counts is an open problem. No image on the site is a photograph of hardware. All pages: https://www.nanoshape.ai/llms.txt