Applied Intuition: Building the Simulation Infrastructure That Autonomous Systems Engineering Depends On
There is a specific engineering problem that every autonomous system program eventually confronts, regardless of domain: you cannot drive, fly, or deploy your way to sufficient test coverage. The space of scenarios that matter — edge cases, adversarial conditions, rare-but-fatal situations — is too large for physical testing to address at any reasonable cost or timeline. Simulation is not a shortcut. For autonomous system verification, it is the only path that scales.
Applied Intuition understood this early and has spent the last decade building the infrastructure that makes simulation-based verification operationally tractable. What started as tooling for automotive ADAS programs has evolved into something with broader implications: a platform that is reshaping how systems engineers think about verification, validation, and requirements coverage for autonomous systems across industries.
What Applied Intuition Actually Builds
The company’s core product stack addresses the full simulation lifecycle for autonomous systems. Simian handles scenario authoring and management — the structured creation and organization of the test cases that define what a system must handle. Basis is their data platform, ingesting, organizing, and surfacing real-world driving and operational data to inform scenario generation. Strada provides program management and fleet analytics. Their sensor simulation and world-building tools create the synthetic environments in which autonomy stacks execute.
The integration point matters. Applied Intuition is not selling a simulator in the legacy sense — a standalone tool that generates visualizations. They are building a connected workflow where real-world data informs synthetic scenario creation, scenarios are managed as structured assets with metadata and coverage attributes, and results feed back into program decisions. The workflow closes the loop between what happens in the field and what gets tested in simulation.
This architecture reflects a specific thesis: that the bottleneck in autonomous system V&V is not compute or rendering fidelity, but the engineering process of defining, managing, and tracking what needs to be tested and whether it has been covered. Scenario management is a systems engineering problem, not just a software engineering problem.
The Scenario Coverage Problem
To understand why Applied Intuition’s position matters, it helps to be precise about what makes autonomous system verification different from conventional embedded software verification.
For a traditional embedded control system, you can enumerate the input space, define boundary conditions, write test cases against requirements, and achieve coverage through a combination of unit testing, integration testing, and hardware-in-the-loop simulation. The state space is bounded. The requirements are decomposable. Traceability from requirement to test to evidence is tractable.
For an autonomous system — a vehicle, an aircraft, a ground robot — the relevant input space is the physical world. The system must respond correctly to an essentially unbounded combination of sensor inputs, environmental conditions, other agents’ behaviors, and system states. The failure modes that matter are not logic errors in individual functions; they are behavioral failures that emerge from the interaction between the autonomy stack and a specific scenario. A pedestrian stepping off a curb at a specific angle, in specific lighting, while the ego vehicle is executing a specific maneuver: that scenario either exists in your test library or it does not. If it does not, you do not know whether your system handles it correctly.
This is the scenario coverage problem. It is not solvable by writing more unit tests. It requires a fundamentally different approach to verification: one organized around scenarios as first-class engineering artifacts, with systematic processes for scenario discovery, generation, prioritization, and coverage tracking. Applied Intuition has built their platform around this framing.
The practical implication is significant. When scenario coverage becomes the organizing principle for autonomous system V&V, simulation infrastructure stops being a test execution tool and starts being a requirements management problem. What scenarios must the system handle? Which have been tested? What is the evidence of coverage? These are questions that belong in the systems engineering workflow, not just the software testing pipeline.
Automotive Origins, Hard-Won Lessons
Applied Intuition was founded in 2019 by former engineers from Google and Uber’s autonomous vehicle programs. The timing was deliberate: the automotive ADAS industry was scaling rapidly, OEMs were under pressure to validate increasingly capable driver assistance systems against both regulatory requirements and internal safety cases, and the existing tooling was inadequate.
The automotive domain provided a pressure-tested proving ground. Automotive safety standards — particularly ISO 26262 and the emerging ISO 21448 (SOTIF, Safety of the Intended Functionality) — impose rigorous requirements on the verification process. SOTIF specifically addresses the problem of functional insufficiency: situations where the system performs as designed but the design is insufficient for the scenario encountered. This is precisely the scenario coverage problem framed in regulatory language. Automotive customers forced Applied Intuition to build tooling that could support genuine safety cases, not just demonstration runs.
The OEM and Tier 1 customer list that Applied Intuition built through automotive work is not public in detail, but the company has been transparent about working with major programs across North American and European manufacturers. More importantly, the automotive work shaped the engineering depth of the platform. Simulating a highway merge scenario for a consumer ADAS feature requires sensor model fidelity, traffic agent behavioral realism, and scenario parameterization that is genuinely difficult to get right. Getting it wrong means a simulation environment that does not represent reality faithfully enough to support a safety argument.
Applied Intuition invested in that fidelity. It is now one of the primary reasons they can credibly expand beyond automotive.
The Defense and Aerospace Expansion
The company’s pivot into defense and aerospace is not a diversification gamble. It is the same bet, applied to domains where the scenario coverage problem is, if anything, more acute.
Defense autonomy programs — uncrewed aerial systems, autonomous ground vehicles, loitering munitions, AI-enabled decision support — face verification challenges that combine the complexity of automotive with the consequence severity of safety-critical aerospace. The operational environment is adversarial by definition. Adversaries actively try to create scenarios outside the training and testing distribution. The requirement is not just that the system performs correctly under normal conditions; it is that the system behaves appropriately under conditions specifically designed to defeat it.
Physical testing for defense autonomy is additionally constrained by cost, safety, classification, and the practical difficulty of replicating adversarial conditions. Simulating the electromagnetic environment of a contested battlespace, the behavioral patterns of adversarial actors, or the sensor degradation conditions of a GPS-denied environment requires exactly the kind of scenario authoring and management infrastructure that Applied Intuition built for automotive.
The company has made their defense orientation explicit. They have worked with defense primes, participated in programs connected to the Defense Innovation Unit (DIU) and related acquisition pathways, and have been vocal about treating military autonomy verification as a first-class use case. Their Strada program management tooling maps onto the milestone-driven, documentation-heavy defense acquisition process in ways that pure software development tools do not.
The aerospace dimension is similarly structural. Urban air mobility programs, autonomous cargo operations, and advanced air mobility (AAM) vehicles face certification requirements under evolving FAA frameworks that have no established playbook for autonomous system approval. The standard approach — demonstrating compliance through analysis, test, and similarity arguments — requires exactly the scenario coverage evidence that simulation can generate at scale.
Systems Engineering Implications
The rise of simulation-based V&V has specific implications for how systems engineers structure their workflows, and those implications are not yet fully absorbed by the industry.
The conventional requirements engineering workflow traces requirements to design elements to test cases to test results. The chain is document-centric: requirements live in a requirements management tool, test cases reference requirement identifiers, test execution records cite test case identifiers, and coverage is assessed by checking that each requirement has been exercised by at least one executed test.
This model does not translate directly to scenario-based autonomous system V&V. A scenario is not a test case in the conventional sense. It is a parameterized behavioral situation that exercises a set of system capabilities simultaneously. A single scenario may be relevant to dozens of requirements. A single requirement — “the system shall maintain safe following distance under all conditions” — may require thousands of scenario instances to cover meaningfully. The traceability structure is many-to-many, dynamic, and dependent on simulation results.
This means that requirements management tooling and simulation infrastructure need to be connected. Scenario metadata needs to reference the requirements being exercised. Coverage claims need to be grounded in simulation execution records. The safety case needs to be able to answer “for requirement X, what scenarios were executed, and what were the results?” across a scenario library that may contain hundreds of thousands of entries.
This integration is not yet standard practice. Most programs handle it through manual processes, spreadsheets, or disconnected tool stacks. The systems engineering community is beginning to grapple with what connected, simulation-aware requirements management should look like — and the tooling to support it is still maturing.
Position in the Autonomy Engineering Toolchain
Applied Intuition occupies a specific position in the emerging autonomy engineering toolchain: they own the simulation and scenario management layer. They are not a full-stack autonomy developer (they do not build the autonomy stacks they test), and they are not a requirements management platform in the traditional sense. They are the infrastructure that sits between the real world and the autonomy stack, making scenario-based verification operationally tractable.
This position is strategically valuable and defensible. Switching costs are high — scenario libraries, sensor models, and world assets built on Applied Intuition’s platform are not easily portable. Integration with autonomy stacks, data pipelines, and program management processes creates dependency. And the network effect of a large scenario library is real: programs that have invested in scenario authoring have an asset that compounds over time.
The competitive landscape includes Ansys, which has simulation tools with automotive and aerospace pedigree but a different architectural center of gravity. Cognata, RightHook, and other specialist simulation vendors address portions of the problem. The major cloud providers have simulation-as-a-service offerings that compete on compute economics. What Applied Intuition has that most competitors lack is the combination of simulation fidelity, scenario management workflow, and program management tooling under a single platform — and the automotive safety case credibility to back it.
Honest Assessment
Applied Intuition is genuinely important infrastructure for autonomous system programs. The problems they address — scenario coverage, simulation fidelity, scenario lifecycle management — are real and significant. Their expansion from automotive into defense and aerospace follows the logic of the technology, not just the logic of market opportunity.
The risks are real too. Defense programs operate on timelines and procurement cycles that are genuinely different from automotive product development. The company is betting that the verification workflow is similar enough across domains that a common platform serves all of them well. That bet may hold. It may also run into the friction of domain-specific certification requirements, classification constraints, and acquisition culture that makes defense harder to serve than automotive at scale.
The deeper systems engineering challenge — connecting simulation-based evidence to requirements traceability in a way that supports formal safety cases — is not fully solved by anyone in the ecosystem. Applied Intuition has built the simulation and scenario management layer. The requirements management layer, and the integration between them, remains an open problem. How the autonomy engineering toolchain develops to address that integration will shape whether simulation-based V&V matures into a rigorous engineering discipline or remains a sophisticated form of testing that stops short of full verification.
The direction is clear. The infrastructure is being built. Applied Intuition is building a significant piece of it.