What Does Applied Intuition Do? Tools for Vehicle Software
Applied Intuition provides development tools, autonomy software and vehicle software infrastructure. Learn where each fits and what to ask when evaluating them.
Updated 5 min read
Applied Intuition builds software for developing, testing, deploying and operating intelligent vehicles and other physical systems. Its public product family (opens in a new tab) includes Tools for Vehicle Intelligence, Self-Driving System, Vehicle OS and Dana. To understand the company, separate tools used to develop a vehicle from software used within it. Tools like fenbs can keep your own research notes and the questions you want answered next.
A useful first conversation starts with where your team needs help: handling data, testing behavior, developing autonomy or managing onboard software. These are different jobs. Knowing which one you mean makes a product demonstration easier to follow and keeps broad claims about “physical AI” tied to a practical purpose.
What are the main product families?
The product names describe different parts of the work. Applied Intuition serves engineering and operational teams across automotive, trucking, defense and industrial uses. Its public descriptions are broader than a consumer self-driving app or a simulation tool for one kind of car.
| Product family | Role described by the vendor | Question to bring to an evaluation |
|---|---|---|
| Tools for Vehicle Intelligence | Data, training-related workflows, simulation and evaluation. | Which development or testing step needs better tools? |
| Self-Driving System (SDS) | Autonomy for physical systems. | Which behavior must the system support in the intended setting? |
| Vehicle OS | Onboard software infrastructure. | Where must software run and interact within the vehicle? |
| Dana | Connecting development and operational tools and workflows. | Which repeated workflow should the team examine first? |
Treat this map as an orientation, not a statement that every product is included in one account. The public pages do not publish a complete matrix of procurement terms, feature access or device requirements. Ask about the specific product and environment your team needs.
Where do the development tools fit?
Tools for Vehicle Intelligence (opens in a new tab) covers data ingestion and curation, training-related workflows, simulation and evaluation. In plain terms, the work includes organizing collected data, testing system behavior and examining the result. The vendor describes cloud, on-premises and air-gapped workflows, as well as bringing existing models, simulators and metrics.
For a hypothetical engineering team, the starting problem could be that useful sensor recordings are difficult to find when a test fails. Another team might have scenarios but struggle to compare behavior across software changes. Both are development problems; neither means the team is buying a finished autonomous vehicle.
Before evaluating tools, draw the current sequence on one page: where data comes from, how it is selected for a test, which software version runs and who reviews the result. Mark the step you want to improve. This makes it possible to discuss fit without assuming you must replace the entire existing toolchain.
What does simulation help you learn?
Simulation lets teams test algorithms and sensor interactions in virtual scenarios, including situations that are difficult or risky to stage physically. Applied Intuition’s simulation test-case explainer (opens in a new tab) discusses realistic scenarios, variation, evaluation metrics and pass/fail thresholds. It is explanatory material, not a current click-by-click application guide.
Imagine an evaluation centered on one ordinary traffic interaction. A useful test needs a clear question, a defined scenario and a way to judge the behavior. Adding many variants only helps if those variants remain realistic and continue testing the intended interaction.
- Purpose: which behavior does the scenario examine?
- Conditions: what changes across versions of the scenario, and why are those ranges appropriate?
- Measurement: which result is recorded and what would count as acceptable?
- Limits: what does the simulated setting leave out?
- Follow-up: which questions still require another kind of testing?
A simulation pass is not a safety certificate. The vendor’s overview also names real-world and track testing, so simulation should not be read as replacing every physical check. Our AI risk mitigation guide covers broader controls; the task here is to understand what evidence this particular tool can help you collect.
How are SDS and Vehicle OS different from testing tools?
Self-Driving System addresses autonomy, while Vehicle OS addresses onboard software infrastructure. Development and evaluation tools help teams build and examine systems. These distinctions matter because a testing requirement, an autonomy requirement and an onboard infrastructure requirement lead to different technical and procurement questions.
Ask the team to describe the intended role before comparing features. Is it evaluating a new behavior, selecting software that produces behavior or choosing the environment in which vehicle software runs? A demonstration can contain pieces of several categories, but the evaluation still needs a primary question.
Do not infer road-ready consumer availability from a product description. Equally, do not turn marketing statements about speed or safety into a guarantee for your own stack. Keep the exact question and the evidence you received in your research notes, so later discussions do not silently expand what was established.
What should you ask about Dana and integrations?
Dana (opens in a new tab) is described as an agentic platform, meaning software that connects tools and carries out multi-step workflows. Its public page names natural-language, API, SDK, custom-application and embedded access, with Request More Info as an entry point. No authenticated dashboard path is established by that public description.
The Tools for Vehicle Intelligence page also advertises MCP-ready interfaces. MCP is a standard way for AI apps to use outside tools. That description does not establish a workflow for registering an arbitrary outside MCP server inside an Applied Intuition product, or a native connection to fenbs.
Ask what can connect in the direction you need, which person approves it and what your deployment supports. Keep a demonstrated connection separate from a possible one. For a narrower simulation comparison, see Applied Intuition versus CARLA; avoid expanding a first product inquiry into a comparison of every tool.
What makes an evaluation useful enough to resume later?
Keep a short research record organized around the question you started with. Record the public source, the claim relevant to your workflow, what you actually saw and what remains unanswered. If you have not used the software, say so; reading a product page is not a completed technical test.
For an experiment you are authorized to run, record the software version, scenario definition, changed conditions, measurements and limits of the result. Keep sensitive engineering data in the systems approved to hold it. Your portable research summary should explain the finding without copying restricted inputs.
The AI at work hub, research workflow guide and product research guide cover the surrounding habits. Save the useful account in fenbs, and use documentation from verified work when you need a longer explanation.
Never lose the work you did in an AI session
After a useful AI session, save it in fenbs: the key observations, findings, research and context. Then carry on from exactly where you left off, on any device and in any other AI. The next AI you connect reads it at the start of the session, so you never have to explain the same problem again.
Create a free accountFree for up to 5 people and 50 open tasks · No credit card · Works with Claude, ChatGPT, Cursor and more
How to keep your vehicle-software research with fenbs
Keep your own research and experiment notes so you can carry on from exactly where you left off, on any device and with another AI. Start with one question and enough evidence that you can recognize the next useful step.
- Create a free account. Name the product question you are investigating.
- Save the public product links and write which part of the vehicle-development work interests you.
- Add the findings you can support, the questions still open and any permitted experiment summary. Keep restricted engineering material in its approved home.
- Write the next check before you stop. Ask your connected assistant to read the saved research when you return.
fenbs is useful for retaining that research and your next steps. It does not replace vehicle-development tools, run simulations or provide vehicle autonomy. Use the appropriate engineering system for those jobs and keep the explanation of what you learned alongside your own work.