Verification
Every stage is checked. Nothing is marked as passed when it did not pass.
A gate is a fixed set of checks with thresholds taken from your spec. Gates are deterministic: the same inputs always give the same result, and no language model decides a pass.
How a gate works
- 01
Thresholds come from the spec. The payload you asked for sets the factor-of-safety checks; the runtime you asked for sets the battery and power budget checks. If you change the spec, the thresholds change with it.
- 02
Checks run on real tool output. Structural analysis, thermal analysis, design rule checks on the board, sourcing lookups and simulation runs produce the numbers. The gate compares those numbers to the thresholds.
- 03
Evidence is kept. Each gate records its inputs, the tool outputs and the thresholds it used. In the workspace, “Show evidence” opens that record for any result.
- 04
A blocked gate stops the run. You see which check failed, in plain words, with a suggested fix you can apply as a change. The failure is never hidden or downgraded.
What verification is not
Anubis produces engineering verification evidence. It does not certify a design, and it does not make a design compliant with any standard. A robot that passes simulation is not thereby safe to deploy. Some gates can only close after a measurement on a built unit; they are shown as pending physical test until then.
Manufacturing files are released only after authorized human engineering review.
Gates by stage
Gate identifiers follow the Anubis specification. The same identifiers appear in the workspace evidence drawer.
| Stage | Specification stage | Gates | What they check |
|---|---|---|---|
| Design | |||
| 01 Spec | Stage A (research-first IR) | Gate 1 | Plain-English spec turned into a structured robot spec; every unstated value filled from research and listed as an editable assumption. |
| 02 Mechanical | Stage 2A, 5.5 and 5.6 | Gates 2 to 6 and 17 | Parts, assembly, STEP, URDF, MJCF and USD files, structural FEA, thermal and EM analysis. |
| 03 Electrical & power | Stage 2B | Gates 7 to 9 | Power tree, battery and BMS, harness, schematic. |
| 04 PCB | Stage 2C | Gate 10 | Placed and routed board, fabrication outputs. |
| 05 Custom silicon | Stage 2D | Stage 2D local gates | ASIC or FPGA path, triggered only when off-the-shelf parts cannot meet the spec. |
| Make | |||
| 06 Manufacturing | Stages 2E and 2F | Gates 14 and 15 | Process choice, DFM report, cost model, CNC and FDM toolpaths. |
| 10 BOM & sourcing | Stage 4 | Gate 11 | Full BOM, exact parts, availability, lifecycle, cost. |
| Simulate & control | |||
| 07 Whole-robot integration | Stage 2F.5 | Gate 18 | One packaged robot, assembly sequence, harness routing, digital twin. |
| 08 Control, autonomy & simulation | Stage 2G, with mission environments | Gates 12, 13 and A8 | ROS 2 workspace, controllers, closed-loop simulation, mission environment, and a learned policy only if the spec requires one. |
| 09 Edge deployment | Stage 2H | Gate 19 | Runtime package for the target compute board. |
| Verify | |||
| 11 Verification | Stage 3 | Gates 16 and 20, plus every stage gate | All gate results, safety and risk analysis, whole-system V&V. |
| Release | |||
| 12 Release | Stage 5 | Release state machine | Signed release package, review worklist, first-article handoff. |
Status meanings
- Pass
- The gate's checks ran and every check met its threshold.
- Blocked
- A check did not meet its threshold. The run stops at this gate and the reason is shown with a suggested fix.
- Failed
- The gate could not complete its checks, for example because an input was missing or a tool errored.
- Not applicable
- The gate does not apply to this design, for example custom-silicon gates when no silicon stage was triggered.
- Pending physical test
- The gate needs a measurement on a built unit before it can pass. Simulation results alone do not close it.