Product
The pipeline, stage by stage.
Anubis runs twelve stages from a plain-English description to a release package. Each stage has defined inputs, defined outputs and a set of deterministic gates that check the result before the next stage can use it.
One sentence becomes a structured spec, then the mechanics, the electronics, the board, the manufacturing plan, the simulation and the bill of materials. Every stage is checked by deterministic gates. Anything that fails is shown with its reason.
What one run produces
- 3D model
- Parts and assembly as STEP, URDF, MJCF and USD.
- robot.urdf
- Schematic
- Power tree, battery and BMS, harness, schematic.
- schematic
- Board
- Placed and routed PCB with fabrication outputs.
- pcb_layout.kicad_pcb
- Simulation
- Closed-loop run of the robot in its mission environment.
- simulation
- Bill of materials
- Exact parts, availability, lifecycle, cost.
- bom_full.csv
One motor change should not cost five teams a week.
What usually happens
Swap a motor on a conventional project and the change ripples outward. The bracket moves. The power budget changes, so the driver and its board change. The harness changes. The bill of materials and the cost change. The simulation no longer matches the hardware. Each ripple lands on a different team, and each team finds out late.
What Anubis does
Anubis records which stages depend on which values. When you change the motor, it plans the revision first: which stages re-run, which gates re-check, and what it will cost. Nothing runs until you apply the plan. Stages that are unaffected keep their results.
Five stages from sentence to release.
Twelve pipeline stages, grouped so you can see where a design is at a glance.
- 01
Design
A plain-English description becomes a structured spec, then a mechanical design, electrical and power design, a routed board and, only when off-the-shelf parts cannot meet the spec, custom silicon.
How it works - 02
Make
Process choice, a design-for-manufacturing report, a cost model, toolpaths, and a full bill of materials with exact parts, availability, lifecycle and cost.
How it works - 03
Simulate & control
One packaged robot with an assembly sequence and digital twin, a ROS 2 workspace with controllers, closed-loop simulation in a mission environment, and a runtime package for the target compute board.
How it works - 04
Verify
Every gate result, safety and risk analysis, and whole-system verification and validation, with the evidence behind each result.
How it works - 05
Release
A signed release package, a review worklist and first-article handoff. Manufacturing files are released only after authorized human engineering review.
How it works
01 Design
A plain-English description becomes a structured spec, then a mechanical design, electrical and power design, a routed board and, only when off-the-shelf parts cannot meet the spec, custom silicon.
- What goes in
- A plain-English description of the robot: what it does, where it works, what it must carry, how long it must run. Anything you leave out is filled from research and listed as an assumption you can edit.
- What comes out
- A structured spec, a mechanical design with STEP, URDF, MJCF and USD files such as robot.urdf, structural and thermal analysis, a power tree, battery and harness design, a schematic, and a placed and routed board such as pcb_layout.kicad_pcb with its fabrication outputs.
| Stage | What you get | Checked by | Workspace tab |
|---|---|---|---|
| 01 Spec | Plain-English spec turned into a structured robot spec; every unstated value filled from research and listed as an editable assumption. | Gate 1 | Overview |
| 02 Mechanical | Parts, assembly, STEP, URDF, MJCF and USD files, structural FEA, thermal and EM analysis. | Gates 2 to 6 and 17 | Mechanical |
| 03 Electrical & power | Power tree, battery and BMS, harness, schematic. | Gates 7 to 9 | Electrical |
| 04 PCB | Placed and routed board, fabrication outputs. | Gate 10 | PCB |
| 05 Custom siliconOnly when needed | ASIC or FPGA path, triggered only when off-the-shelf parts cannot meet the spec. | Stage 2D local gates | Electrical, Silicon sub-tab |
02 Make
Process choice, a design-for-manufacturing report, a cost model, toolpaths, and a full bill of materials with exact parts, availability, lifecycle and cost.
- What goes in
- The mechanical and electrical designs, the target production volume, and your sourcing constraints.
- What comes out
- A manufacturing process per part, a design-for-manufacturing report, a cost model at your volume, CNC and FDM toolpaths, and a full bill of materials such as bom_full.csv with exact parts, availability, lifecycle status and alternates.
| Stage | What you get | Checked by | Workspace tab |
|---|---|---|---|
| 06 Manufacturing | Process choice, DFM report, cost model, CNC and FDM toolpaths. | Gates 14 and 15 | Manufacturing |
| 10 BOM & sourcing | Full BOM, exact parts, availability, lifecycle, cost. | Gate 11 | BOM |
03 Simulate & control
One packaged robot with an assembly sequence and digital twin, a ROS 2 workspace with controllers, closed-loop simulation in a mission environment, and a runtime package for the target compute board.
- What goes in
- The packaged robot, the mission the robot must perform, and the environment it will work in.
- What comes out
- An assembly sequence and digital twin, a ROS 2 workspace with controllers, closed-loop simulation results, and a runtime package for the target compute board. A learned policy is trained only if the spec requires one.
| Stage | What you get | Checked by | Workspace tab |
|---|---|---|---|
| 07 Whole-robot integration | One packaged robot, assembly sequence, harness routing, digital twin. | Gate 18 | Mechanical, Assembly view, and Simulation |
| 08 Control, autonomy & simulation | ROS 2 workspace, controllers, closed-loop simulation, mission environment, and a learned policy only if the spec requires one. | Gates 12, 13 and A8 | Simulation |
| 09 Edge deployment | Runtime package for the target compute board. | Gate 19 | Simulation, Deployment sub-tab |
Mission environments
Build the place your robot will work in, from your photos or video, from public sources, or from a stand-in environment when none exist. The closed-loop simulation runs the robot in that environment.
04 Verify
Every gate result, safety and risk analysis, and whole-system verification and validation, with the evidence behind each result.
- What goes in
- Every stage output and every gate result from the run.
- What comes out
- A gate matrix with the status and evidence for each gate, safety and risk analysis, and whole-system verification and validation. Gates that need a measurement on a built unit are shown as pending physical test.
| Stage | What you get | Checked by | Workspace tab |
|---|---|---|---|
| 11 Verification | All gate results, safety and risk analysis, whole-system V&V. | Gates 16 and 20, plus every stage gate | Verification |
05 Release
A signed release package, a review worklist and first-article handoff. Manufacturing files are released only after authorized human engineering review.
- What goes in
- A design whose gates pass, and a request for manufacturing release.
- What comes out
- A review worklist for authorized engineers, a signed release package once review is complete, and a first-article handoff. Until then, review copies can be viewed and downloaded, but manufacturing formats stay locked.
| Stage | What you get | Checked by | Workspace tab |
|---|---|---|---|
| 12 Release | Signed release package, review worklist, first-article handoff. | Release state machine | Release |
Every stage is checked by deterministic gates.
A gate is a fixed set of checks with thresholds taken from your spec. No language model decides a pass. If a gate blocks the run, you see which check failed, in plain words, with a suggested fix you can apply as a change. The evidence behind every result is one click away.
How the gates workBuilt for agents as well as people.
The same workspace actions are available as a REST API and as an MCP server, so an agent can create a design, propose a change, read the gate report and fetch the bill of materials. Actions that spend credits or request a release are marked as consequential, so clients ask the user first.