Big Auto One / Approach
How we build it
An uncrewed vehicle is a promise about behavior in conditions nobody is standing in. The only way to keep that promise is to decide the behavior in advance, write it down, enforce it somewhere it cannot be argued with, and then spend most of the effort trying to break it.
Principles
Five things
we don't trade
Practice
One stack, proven
before it moves
Same software, simulated edges
Simulation here does not mean a separate model of the vehicle that has to be kept honest against the real one. It is the vehicle's own software — the same planner, the same control, the same safety core, the same ground service — with its sensors, its radios, its drivetrain and its world replaced at the boundary.
Nothing in the simulation reaches into the vehicle stack. That rule is what makes a result in simulation worth anything, and it is enforced structurally rather than by discipline.
Ground that actually exists
Rehearsals are built on surveyed elevation and current imagery of real places, not on terrain drawn to make a demonstration succeed. Which street stays open in a flood, and how far a ridge masks a radio, are then decided by the ground rather than by us.
Weather and light are part of the scenario for the same reason. A hot afternoon reaches the vehicle through its cooling, not through a caption.
The full set runs on every change
The scenario library — link loss, interference, satellite denial, compute loss, network failure, command center failover, damage, terrain — runs automatically against every change to the software, on more than one deployment shape of the stack.
A capability is not finished when it works once. It is finished when it keeps working while everything else changes around it.
Written down first
The architecture, the message contracts, the safety behavior and the open questions live in design documents that are the source of truth, and the code is held to them. Decisions are recorded with their reasoning, including the ones we later reversed.
For a customer that matters in a specific way: what the system will do in a given condition is answerable from a document, before anyone runs anything.
Security is in the protocol
Every session between a command center and a vehicle is mutually authenticated and encrypted, and control authority is carried as a signed grant with a lifetime rather than as a flag someone can set. Keys roll over mid-mission without a gap in control.
Software reaches a vehicle as a signed, atomic, roll-back-capable update, over the mesh or by local media. A partly-updated vehicle is not a state that exists.
Maturity
What is real, and
what is not yet
Uncrewed ground is a field with a long history of confident demonstrations. We would rather be the supplier whose claims survive the follow-up question.
Two maturities, not one
The platform is built, tested by multiple governments and entities, and manufacturable today. The software on this site runs against it in simulation and has not yet met a hull. Both halves of that sentence are true, and we will always tell you which one you are looking at.
We separate proven from planned
Anything we show you is labeled: running against production software, running in simulation, or designed and not yet built. You will not have to work out which it was.
We will show you the failures
Every rehearsal is recorded and replayable. The interesting review is the run that went wrong, and we are happy to sit through it with you.
Open questions stay open in public
Decisions that are not yet made are tracked as decisions that are not yet made, with the evidence each one is waiting on. We do not close them by writing a brochure.
Ask the hard one
Bring the follow-up question
The conversation we most want is the one where you ask what happens in the condition you already know is the problem.