Join the waitlistJoin

Thrust Your Deployments, Trust Your Robot

Thrust gives robotics teams the infrastructure to verify and maintain real-world robots. You think it, we make it faster and safer to ship.

The problem

Software development sped up.
Robot verification didn't.

Software teams ship fast because the machine under the code is disposable and identical every time.

A robot breaks both assumptions. It is one physical machine whose state changes under you: calibration drifts, someone edits a param over SSH, a sensor gets swapped, firmware gets flashed. Robotics teams use tools built for servers, so verification stays manual. Someone connects, launches, records, and manually writes reports, hoping nobody touched the robot.

The cost is glue, not physics. Teams stitch verification together by hand, and when the robot changes, it is hard to tell which results still apply.

  • Calibration drifts between campaigns.

  • A param gets edited over SSH and never written down.

  • A sensor gets swapped and the extrinsics move with it.

  • Firmware gets flashed and the old evidence stops applying.

State drift on one physical machine Side view of a warehouse robot with a stack of state tags — software, config, calibration, hardware. The config tag is marked as edited over SSH and the lidar as swapped, while a dimension line states that the state changes with no baseline to diff against. SOFTWARE · TB-AMR-V2 CONFIG · NAV2.YAML CALIBRATION · EXTRINSICS HARDWARE · TB-AMR-V2 PARAM EDITED OVER SSH SENSOR SWAPPED ONE PHYSICAL MACHINE STATE CHANGES UNDER YOU THRUST · DWG. 01 STATE DRIFT · NTS
One machine, several kinds of drift. Nothing diffs the current state against the state the evidence was recorded on.
The solution

Thrust Verify: Define the test. Know what still holds.

In development - Coming soon

Thrust Verify turns a team's physical tests into reusable scenarios with measurable pass conditions. Each run records the robot's state and the checks it actually used. When something changes, only affected checks go stale.

  1. 01 Define

    Set the mission, preconditions and measurable pass checks. Save them as a reusable, parameterized scenario.

  2. 02 Run

    Run a saved scenario on the robot, or capture a manual check to make it repeatable.

  3. 03 Maintain

    Record actual dependencies. A change stales only the checks that used it.

  4. 04 Gate

    Apply the team's release rules to the results. Missing proof blocks the rollout.

One test, traced to a release decision.

Illustrative example · acceptance limits are set by the team.

Test definition

Scenario
corridor_navigation
Mission
Navigate with the front lidar
Acceptance check
Obstacle clearance ≥ team-set margin

After a lidar remount

  • amr-01ValidResult still applies
  • amr-02StaleRe-run this scenario

Release gate · waits for a current result on amr-02.

How we build

A few constraints
we do not break.

Local-first.

The core runs on the robot, not on our servers. No internet, no account, no data leaving your network.

The logbook travels with the asset.

Deterministic, not generative.

No LLM in the core. Same observations, same verdict.

You can read the record and argue with it.

Wrap, don't replace.

Plugs into the scripts, CI and deploy tools you already have. One command to adopt, the rest untouched.

Your stack stays yours.

Opinion-free.

Applies your team's rules. It does not judge whether a test is good.

The verdict is yours.

Conservative when unsure.

If we cannot prove a result is still valid, we say so.

A false "still valid" is worse than a re-run.

Who it's for

You need Thrust Verify if

Shared robots

Several engineers share the same robots and nobody knows what changed since the last pass.

Blind re-runs

A change lands and nobody knows which tests to re-run, so the team re-runs everything or skips.

Fleet state

You deploy and nobody can say which robots ended up in a validated configuration.

Acceptance

You need acceptance evidence for a customer without hand-building a folder of PDFs.

Use cases

Where Thrust Verify
earns its keep.

Shared dev robots

Dev teams at robot makers · shared lab robots

Challenge

Three engineers share two ROS 2 robots running Nav2. Someone edits a Nav2 parameter over SSH to test a change, forgets to say so, and the next person spends a day chasing a failure that is not theirs. Nobody can say what state either robot was in when it last passed.

Outcome

Every run snapshots the robot's state and every change is logged. Before a run, thrust diff shows what moved since the last pass. A contaminated robot is visible before it wastes a day, not after.

Selective re-run after a change

ROS 2 development teams · active development

Challenge

A change lands and nobody knows which of the team's scenarios it affects. Re-running the full suite on scarce hardware costs hours; skipping it ships a regression.

Outcome

Each result records what it depended on. Change a controller param and only the scenarios that touched it go stale. The rest stay valid. thrust status shows exactly what to re-run before the release gate.

Re-verifying a deployed fleet

OEM release teams · deployed fleet

Challenge

A technician swaps a sensor or flashes firmware on one robot in the field. Now nobody knows which deployed units still run a validated configuration, and the customer needs a traceable record after every change.

Outcome

A pass on a few robots covers equivalent units by state. thrust gate blocks a rollout when a segment has stale or unproven results, and leaves the re-verification record behind. The team can see what was checked, on which units, and against which state.

Acceptance with evidence

Integrators · customer site

Challenge

Acceptance means proving a set of checks at a customer site and handing over evidence. Today it is a spreadsheet, a folder of bags and a hand-built PDF.

Outcome

Define the acceptance set once, run it on the site's robots, and export a record of what passed, on which unit, against which state. The evidence is the by-product of the run, not a document someone assembles afterward.

FAQ

Common questions

What is Thrust Verify?

Thrust Verify keeps, for every real robot, the answer to three questions: which scenarios are proven on it now, what changed, and what has to be re-run. Define reusable scenarios with measurable acceptance checks, then run them against the robot's current state and gate a release on the result.

Is it AI?

No. The core is deterministic: same inputs, same verdict. There is no LLM in the loop. AI is an optional interface on top, for agents that want to call Verify and read its structured output.

Does it replace my deploy tool?

No. Verify sits in front of your deploy step and applies your release rules. If required results are stale or unproven, it blocks the rollout. Your deployment tool stays in place.

Which robots and stacks does it work with?

ROS 2 first, because that is where the teams we work with build. Verify runs the commands and scripts you already use; Nav2 is one example of a ROS 2 integration, not a separate platform.

Does it work offline?

Yes. The core runs on the robot and the logbook lives on the robot. No internet, no account, no data leaving your network unless you choose to sync.

Where does the data live?

On the robot. A cloud sync for fleet-wide views is optional and comes later. Your raw data stays yours.

When is it available?

Under active development. Join the waitlist and we will reach out when the first version is ready.

How do I start?

Join the waitlist. When it opens, start from a launch file or capture a manual check as a repeatable scenario with measurable acceptance checks.

The team

We're building the tools we wish we had.

José González

José González

Co-Founder & CTO

GNC algorithms for unmanned systems in air combat programs. MSc in Systems and Control, Electrical and Electronics Engineering.

LinkedIn
Blai Morte

Blai Morte

Co-Founder & CEO

Guidance and swarm coordination systems. MSc in Aerospace Engineering and MSc in Applied Systems Engineering / Robotics.

LinkedIn
David Díaz

David Díaz

Co-Founder & COO

Big4 consulting and entrepreneurship, including founding a regional startup community. Aerospace Engineering degree and MBA.

LinkedIn

Built by engineers with 5+ years in real robotics at Indra, SENER, and FSUPV.

Design partners

Our design partners

ITI Technology centre in Valencia developing robotics, industrial automation and cyber-physical systems. iti.es YK-Robotics Barcelona-based startup building a brand-agnostic platform to design, simulate, program and operate robotic cells. yk-robotics.com
Coming soon A new design partner joining the programme. We'll announce it shortly.