Robustness for robotics

Bounded loops, timing and interlocks for control programs. Part of the guide to the Soma programming language.

These scenarios exercise Soma behavior relevant to robot controllers. They do not qualify hardware, real-time performance or a lunar system. Each scenario is a separate Rust integration test in compiler/tests/robotics_robustness.rs.

Results — Soma 2.8.3, 2026-09-20

• Robotics campaign: 100 passed, 0 failed, 0 ignored.

• Complete Rust suite: 523 passed, 0 failed, 0 ignored.

• Core CLI fixtures: 118 passed, 0 failed.

• Published corpus: 321 programs passed the website build checks.

Measured locally on macOS ARM64. Linux CI reruns the full suite on every push and pull request. This campaign confirmed the tested behavior without finding an additional runtime defect. The source of every scenario is in robotics_robustness.rs.

Scope and reproduction

Added in Soma 2.8.3 on 2026-09-20. This is a regression campaign for the language, with inputs chosen for robot-controller use. The motor and sensor values are simulated data; no physical hardware is driven.

Run all 100 independently named scenarios from the repository root:

cargo test --release --locked --manifest-path compiler/Cargo.toml --test robotics_robustness

Run them with every existing Rust test:

cargo test --release --locked --manifest-path compiler/Cargo.toml --no-fail-fast

IDs 001–080 cover numeric boundaries, sensor validation, mission transitions, storage invariants, rollback and collection/JSON boundaries. IDs 081–090 test the distinction between static rejection, proof, runtime checks and unproved distribution. IDs 091–095 run native handlers, including comparison with the interpreter. IDs 096–099 use fresh processes to check committed data and rollback persistence; 100 distinguishes recorded errors from returned data. verify_fail and check_fail mean the expected rejection is asserted, including its diagnostic. A refusal is a passing test, not a waived failure.

The separate existing compiler/tests/cluster.rs suite covers actual network replicas, seed failure, reconnect, stale updates, restart, and partition recovery. The 100 scenarios below do not add consensus or distributed safety proofs.

Limits

These are finite examples, not a proof for every input. They do not measure worst-case execution time, memory exhaustion, radiation tolerance, sensor or actuator faults, abrupt power loss, or hardware fail-safe behavior. Restart tests exit processes normally after a commit or a rejected handler; they do not inject power loss during a disk write. Local transaction rollback cannot undo a command already sent to a physical actuator. The cluster remains experimental and eventually consistent, with local reads and no fenced scheduler. Use the guarantees and cluster limits when assessing a design.