Robots should fail in testing, not in the field.
Invariant is building the test and evaluation layer for physical AI, so teams can change robot software every day and still know exactly what they're shipping.
Robot software changes faster than it can be tested.
Robot software now changes almost as fast as web software. Models are retrained every week, stacks are updated every day, and coding agents write a growing share of the code. Testing hasn't kept up. Many teams still find out what a change did by putting the robot in the field.
The tools that exist cover the ends, not the middle. General-purpose CI doesn't understand logs, simulators or noisy results. Simulators can run a scenario, but can't tell you whether a change made things better. Everything in between gets built in-house, usually by one engineer, and quietly breaks with the next ROS or simulator release.
Invariant is that missing layer: one place to describe tests, run them anywhere, starting with recorded logs and growing to simulation and hardware rigs, and get verdicts you can check.
How we build Invariant.
Evidence, not guesses
Every verdict comes with an interval. "Not enough evidence yet" is an honest answer, and better than a coin-flip pass/fail.
Local first
If a test doesn't run on an engineer's laptop, it won't be used. The same spec runs locally, in CI and at scale.
Your data stays yours
Logs, models and outputs stay in your storage. We keep run records, metrics and verdicts, never your logs.
No lock-in
A test spec and local runner we plan to open source, and everything exportable as plain files.
Integrate, don't reinvent
Great simulators, viewers and CI systems already exist. We connect them instead of rebuilding them.
Built from the field
The most valuable test is the one that captures something that already went wrong. Every field failure should become a regression test.
Built by an engineer who has debugged autonomy in the field.
Aidan Reilly
Aidan is a robotics software engineer working on autonomy for vehicles that operate in the field. He spent two years at Komatsu Mining building perception, localization and navigation software for autonomous mining vehicles, including LiDAR perception for underground mines.
Debugging there meant replaying recordings one at a time at real-time speed, sometimes for a whole day per bug. Invariant is the tool he wanted then: every change tested against every log that matters, in parallel, with an answer you can trust.
Work with us.
We're looking for our first design partners. If your team ships robot software and testing can't keep up, we'd like to hear from you.
or email [email protected]