# OpenMotive — Company Thesis

## The physical vehicle. Made programmable.

**Designing around an existing vehicle requires geometry teams can trust. When suitable data isn’t accessible, engineers must capture and prepare it themselves. OpenMotive is building a shared library of verified, licensable vehicle geometry and component relationships to make that information easier to access and reuse.**

*OpenMotive is in early development. This thesis sets out the product, commercial strategy, and validation work. The current vehicle visuals are illustrative; measured datasets, engineering motion models, and CAD/API integrations are planned.*

## The Problem

Before designing around a vehicle, a team needs to know what is already there. That same starting point matters when preparing a simulation, building a teaching tool, or creating an interactive vehicle experience.

Suitable geometry can be difficult to access. Without OEM CAD, a manufacturer may reverse-engineer an assembly, a fabricator may measure mounting points by hand, and a simulation team may prepare another model of the same component. A file found online can still leave its configuration, dimensions, source, and usage rights unresolved.

Our central market hypothesis is that teams repeat this work because the geometry, evidence, and rights needed for their task are difficult to obtain together. The cost includes vehicle access, capture, manual measurement, reconstruction, and aligning the parts into a useful assembly.

Existing providers address parts of this need. OpenMotive focuses on making the geometry and its supporting information reusable together. Customer work must establish where this saves preparation, improves access, or supports a job the available alternatives handle poorly.

## Thesis

Our job is to make a measured vehicle useful beyond the team that captured it.

OpenMotive is developing a shared library of verified, licensable 3D geometry. Engines and their installed surroundings come first, followed by drivetrains and complete vehicle architectures as coverage and validation expand.

We treat automotive geometry as structured data infrastructure. A component record identifies the part, its shape, where it belongs, what connects to it, and how its measurements were checked. Source history, vehicle configuration, and usage rights stay attached as that record moves between projects and tools.

Our architecture extends these records to mechanical connections and movement, helping teams design around how a vehicle operates. Documented joints, movement limits, and relationships between moving parts add a new use for the same physical reference: understanding the space a component occupies throughout its operation.

The Subaru FA20DIT defines the first assembly model: block, heads, crankshaft, pistons, turbocharger, manifolds, sensors, and accessories. A turbocharger lookup brings together its geometry, documented connections, captured flow paths, nearby components, and evidence of compatibility with a specific configuration. The record gives the user the information needed to understand the part’s place in the system.

Our whole-vehicle development plan extends that representation across the engine bay, drivetrain, suspension, underbody, body structure, and interior.

The ambition is to become a canonical reference: a stable record of a documented physical configuration that retains its meaning across projects. That status has to be earned through measurement, adoption, and reliable maintenance. Coverage and verification limits remain explicit as the library grows.

The geometry becomes one layer of a larger automotive knowledge system. Its applications span engineering design, developer tools, education, games, simulation, and AI. Each use needs the appropriate representation and supporting context.

The central progression is:

**Physical vehicle → verified geometry → connected component records → reusable vehicle knowledge → designs, applications, and engineering tools.**

Whole vehicles are central to the architecture, even when the first commercial dataset covers only one engine or subsystem. Aftermarket development is the first commercial application of this broader foundation.

The first release needs enough trustworthy geometry to solve one specific engineering problem. That result establishes the next useful addition.

## Why Now

The tools to capture and deliver physical geometry are available today. Portable professional scanners such as Creaform’s HandySCAN 3D support component measurement and reverse engineering. Dataset quality still depends on preparation, capture conditions, processing, and validation.[^capture]

WebGL makes 3D assemblies explorable in a browser. glTF supports efficient delivery, and cloud APIs let applications retrieve assets. Together, they provide a path from a captured component to geometry that other software can display and use.[^webgl][^gltf][^cloud]

Engineering AI adds another use for that data. Neural Concept describes a design copilot that combines spatial reasoning, physics awareness, and CAD-ready geometry generation.[^nc]

PhysicsX similarly combines engineering data, numerical simulation, AI models, and engineering applications within its platform.[^px]

Our timing hypothesis is practical: reusable vehicle geometry can serve existing CAD workflows and give new software a physical reference to work against. The opportunity depends on making that reference easier to obtain and use. Customer results and acquisition economics will determine where the approach works.

## Initial Wedge

Our first application is **aftermarket packaging and geometric compatibility**, beginning with the FA20DIT and one clearly documented Subaru WRX configuration.

The first release centers on a bounded task: designing or checking an intake, charge-pipe route, or similar component against a defined region of the vehicle.

The dataset scope covers the relevant component geometry, mating interfaces, neighboring obstructions, reference coordinates, and verified measurements needed for that task. Missing surfaces and unverified relationships remain explicit.

The customer outcome is straightforward:

> Load the relevant vehicle context, position a candidate part, inspect interference and clearance, and export the evidence needed to continue engineering.

The first proof is a paid engineering project with results checked against the physical vehicle.

Success means demonstrating that OpenMotive reduces preparation or rework while producing results that agree with the measured vehicle within the stated limits.

Customer demand determines which internals, subsystems, and vehicle variants come next.

## Product Vision

The product has three connected layers: verified component records, operations that work on geometry and documented motion, and access through engineering software.

### Verified geometry and connected component records

Each record specifies the component, geometry, units, reference coordinates, installed position, vehicle configuration, source, usage rights, and limitations.

Verification applies to a particular dataset and use. A new scan or corrected measurement can improve the record while version history preserves the evidence behind earlier decisions.

Relationships describe what belongs to an assembly, what connects, and which parts occupy neighboring space. Measured properties, documented requirements, and inferred relationships remain distinguishable.

The platform could maintain captured meshes, optimized visualization models, and reconstructed CAD where that additional work is justified. Each representation has its own accuracy and intended use.

### Spatial operations

The first operations focus on retrieving a part, isolating a vehicle region, locating its documented connections, finding nearby geometry, and checking a candidate for intersections in that configuration.

For example:

> Return the compressor-outlet interface and surrounding geometry needed to evaluate a proposed charge-pipe route, together with the dataset version, measurement limits, and uncaptured areas.

Motion and clearance checks are the next extension of this packaging workflow. A motion envelope describes the space a part occupies across a documented range of movement. Checking that envelope against neighboring geometry helps identify interference that a single installed position can miss. Coverage expands as the movement data and checking methods are validated.

We treat unscanned space as unknown.

### Software access

The access architecture connects a browser-based explorer, CAD integrations, and developer APIs to the same versioned information.

A component lookup follows this path:

**2018 Subaru WRX → FA20DIT → Turbocharger**

The lookup returns the part’s geometry, checked dimensions, connections, nearby components, evidence, and usage rights. Its identifier, configuration, and version keep the browser and API tied to the same information. This example illustrates the product design; verified datasets and API access are in development.

Every assessment needs to retain the geometry, configuration, method, assumptions, and limitations behind its conclusion.

An engineer can inspect the record. A developer can use it in an application. Both need to know exactly which information a result depends on.

## Whole-Vehicle Architecture

An engine model describes a component system. Its installed position within a vehicle provides the context for designing around it.

The architecture extends from engines and transmissions to engine bays, cooling systems, subframes, suspension, steering, brakes, exhaust routes, underbodies, body structures, and interiors.

Our assembly model defines each assembly’s relationship to the vehicle reference frame. Where relevant, the model also specifies the vehicle state: installed equipment, steering position, suspension position, or another condition affecting the analysis.

Our coverage strategy moves from accessible surfaces to exposed interfaces and selected disassembled components. A complete engineering representation requires more than an exterior scan.

Vehicle identity rests on the configuration evidence needed to interpret the data. Compatibility across years, trims, and component revisions requires its own evidence.

Each version must identify the physical configurations it describes and the evidence supporting that coverage.

## Motion and Vehicle Behavior

A vehicle operates through connected movement. Pistons travel as the crankshaft turns. Steering changes wheel position. Suspension travel changes the space between a tire and the body. OpenMotive's architecture captures these mechanical relationships alongside component geometry, so the same assembly can support design checks, engineering software, and interactive explanations.

The first motion models focus on **kinematics: how connected parts move**. Engine examples include crankshaft rotation, piston travel, and valve timing. Vehicle examples include steering, suspension travel, and driveline rotation. Each model needs documented joint types, axes, dimensions, movement limits, and timing or drive relationships. Motion records retain their configuration, source, assumptions, and validation evidence.

The first engineering application extends geometric packaging into clearance throughout movement:

- Check a tire against the body across steering and suspension travel.
- Check a charge pipe against its surroundings through a measured or prescribed range of engine movement on its mounts.
- Find the space a mechanism occupies across its documented operating range.

These checks evaluate specified movement. Predicting that movement under load adds **dynamics: how systems respond to forces**. Acceleration, braking, body roll, vibration, and engine mount response require appropriate mass and inertia data, forces, spring and damping properties, tire or powertrain models, and comparison with physical results. Combustion, power output, and thermal predictions require additional models and calibration; geometry and mechanical motion alone do not establish them.

The integration strategy connects OpenMotive's documented assemblies and motion relationships to established simulation tools. Simscape Multibody supports assemblies with bodies, constraints, and joints. Project Chrono supports modular vehicle models covering suspension, steering, driveline, tires, powertrain, and terrain.[^multibody][^chrono] OpenMotive supplies reusable vehicle context and develops focused checking tools; solver integrations remain part of the development plan.

The sequence is deliberate: verified geometry, documented mechanical motion, clearance checks across that motion, then calibrated behavior models for specific applications. The current vehicle animations are illustrative. Engineering motion and dynamics capabilities require their own data and validation milestones.

## Competitive Position

OpenMotive enters an existing market with sophisticated participants.

A2MAC1 already brings geometry, materials, mass, images, and contextual component analysis into its engineering environment. Its published descriptions include measurements and sections for reverse engineering and concept validation.[^a2geometry]

A2MAC1 also explicitly describes integration with customer systems through open API frameworks. OpenMotive therefore cannot base its differentiation on a claim that incumbent vehicle-data platforms lack APIs.[^a2api]

Caresoft offers full-vehicle and component data, including CAD, CAE, and CFD models for engineering analysis and simulation.[^caresoft]

Neural Concept and PhysicsX also address geometry-aware design and engineering automation. Data access, geometry, and software capabilities already overlap across this market.

**Our differentiation must be demonstrated through the customer and workflow we serve.**

The initial aftermarket workflow puts this broader geometry foundation to a concrete test: load a specific vehicle configuration, introduce a candidate component, examine interfaces and surrounding space, and produce a reproducible geometric assessment.

Targeted coverage, reliable data, clear licensing, and integration into existing tools must make that workflow more useful or economical than the customer’s alternatives. That is the business hypothesis to test.

Existing providers could become competitors, integration targets, or licensed data sources. None should be assumed to be a partner—or to permit redistribution—without an agreement.

## Customers

Customers need vehicle geometry to design physical products or build software and digital experiences. Both uses depend on suitable data with clear rights.

Our initial customer focus is aftermarket manufacturers and engineering-led fabrication businesses with recurring vehicle-packaging problems. Intake, cooling, exhaust, and drivetrain projects provide candidate workflows to investigate.

The customer value comes from less preparation, fewer avoidable fitment iterations, or access to usable vehicle context without repeating acquisition work. Those benefits must be measured in customer projects.

CAD developers, simulation providers, engineering-AI companies, and tuning platforms need the same vehicle information inside their own products. Stable records and software access let them build on the library, with representations prepared for their specific use.

Motorsport teams, educators, repair-tool developers, and game studios could use suitable derivatives of the library to design, explain, or depict vehicles. Educational and game assets have different requirements from engineering and simulation datasets. Our approach to quality, preparation, and licensing reflects those uses.

The initial workflow should establish the quality, economics, and reuse of the underlying assets. Expansion into these additional markets follows demonstrated demand and the ability to serve their requirements.

## Business Model

The commercial plan starts with paid pilots and licenses for specific vehicle regions, assemblies, or datasets.

Recurring library access, updates, and collaboration become useful as customers return for more projects. Integration licenses can support software partners, with pricing tied to data access, operations, or agreed distribution rights.

Private workspaces could allow manufacturers to use the same representation and tools without contributing confidential geometry to the shared library.

Custom acquisition and preparation projects could fund reusable assets where the customer and source agreements permit it. Reuse requires an explicit agreement.

Licenses should separately address internal engineering use, embedded visualization, downstream geometry distribution, AI inference access, and model training.

Recurring revenue should follow recurring customer value. If customers primarily need isolated downloads, the commercial model should reflect that rather than forcing an artificial subscription.

## Acquisition Strategy

The acquisition strategy combines original capture with suitable data from professional scanning, manufacturers, customers, and permitted contributors. Each source needs the quality and rights required for its use.

Our operating principle is:

**Use suitable existing data when rights and quality allow; capture the gaps that matter.**

Our acquisition standard requires identity checks, normalization, alignment, coverage review, and documented validation before a source becomes part of a commercial dataset.

Our capture requirements include assessing physical vehicles and donor components for modifications, damage, and configuration differences. A vehicle-family reference requires evidence that the sample represents that configuration.

## Data Flywheel

The library becomes more valuable when existing records support another useful task.

An FA20DIT dataset supports engine-level work. An aligned WRX engine-bay dataset adds installation context. Documented aftermarket components add candidate geometries and interfaces that can be evaluated against that context.

An engineer can locate the engine’s mounting points, inspect the parts around them, then bring in a candidate turbocharger to check how it occupies the same space. Each step reuses the preceding records to support a new assessment.

Customer projects could reveal missing coverage, improve measurements, and identify the next valuable configuration. With appropriate permission, those improvements could support subsequent customers.

The intended cycle is:

**Paid engineering use → better coverage and validation → more reusable context → additional projects and integrations.**

This only works when the assets are relevant, compatible, trustworthy, and licensable. More scans do not automatically create a network effect.

## Moat

Scanning hardware, a viewer, an API, and an AI interface are not sufficient defenses by themselves.

The lasting asset is the accumulated work behind a dependable vehicle reference: identified configurations, documented connections, aligned parts, checked dimensions, version history, usage rights, and comparison with physical results.

A second source of defensibility could be integration into recurring engineering workflows. Customers need to trust that a dataset revision, component identifier, or query has a stable meaning across projects.

OpenMotive must demonstrate that reuse increases while acquisition, preparation, and support costs per customer project become more favorable.

The test is whether the platform makes repeated work materially easier.

## Relationship to Automotive AI

A design system needs to know the parts and space it must work around. Supplying that physical reference is OpenMotive’s role in engineering AI.

An engineer might ask:

> Propose a charge-pipe route between these verified interfaces, avoiding the captured neighboring geometry and respecting the requirements supplied for this project.

A connected design system could generate candidates. Geometry tools could check interference. Additional engineering tools could evaluate relevant performance requirements. Engineers review the results and determine the next validation steps.

OpenMotive could provide its own assistant for selected workflows, without training a general-purpose engineering model or building every solver.

The access architecture supports work across CAD systems, simulation tools, and AI providers. Vehicle knowledge needs to remain portable as those tools change.

Over time, OpenMotive could add constrained design assistance for specific component classes. That application depends on building and validating the physical-context layer.

An engine or vehicle simulator can serve as an application of the same records. Its geometry, motion relationships, and behavior models must retain separate evidence and validation status. Demonstrating movement does not establish predictive accuracy.

## From Signals to Physical Components

Follow a documented signal to its sensor, locate it within the vehicle, and inspect the surrounding assembly. This workflow connects the library to diagnostic, tuning, repair, and training tools. The same component identity can tie a measurement in a chart to a part in a spatial view.

These mappings require evidence for the relevant vehicle configuration and control system. Our model distinguishes direct sensor readings from calculated values, with units, transformations, source documentation, and unresolved relationships recorded. Service access and removal sequences require their own documentation in addition to geometry.

## Trust and Engineering Limits

Trust must be part of the data model and the product contract.

Each dataset should disclose its source, capture method, reference frame, configuration, coverage, processing history, validation method, and intended use. Measurement claims should describe the resulting dataset, not merely repeat the scanner’s advertised specifications.

Each important fact or relationship should be identifiable as measured, documented, calculated, assumed, or unknown.

A geometric check should report its actual scope:

> No interference detected in the tested configuration against the available geometry.

It should not silently become:

> This part is safe, installable, and compatible with every vehicle of this model.

Load capacity, operating temperature, material performance, and allowable clearance require appropriate sources and review. Surface shape alone cannot establish them.

Where a decision depends on motion, tolerances, heat, tool access, installation sequence, or structural behavior, the workflow must include that evidence or identify the missing assessment.

The platform’s role is to support engineering judgment with explicit evidence—not replace physical validation or represent an unchecked AI proposal as production-ready.

## Expansion and Validation

Our development path starts with one useful FA20DIT/WRX workflow and expands to connected subsystems, broader vehicle coverage, additional verified configurations, and external software integrations.

Expansion into transmissions, suspension, body structures, interiors, EV powertrains, battery packaging, and complete vehicle architectures follows demonstrated customer demand.

Motion coverage follows the same rule: establish a documented movement range, check the resulting clearance assessment against the physical assembly, and expand where it supports a recurring customer task. Calibrated dynamics and performance models follow application-specific validation.

AI-assisted design should expand as the supporting context and evaluation methods become dependable—not merely because a compelling demonstration can be generated.

Progress should be measured through time to usable engineering context, agreement with physical measurements, repeat purchases, dataset reuse, and successful use by external tools.

The decisive early question is:

> Will a customer pay to use this context on a real project, trust its stated limits, and return for the next one?

A small dataset that repeatedly supports paid work is stronger evidence than a large catalog that nobody integrates into engineering decisions.

## Long-Term Vision

Start with an engine and a specific engineering task. Map the vehicle around it, adding verified components, mechanical connections, and documented movement as they support useful work. The resulting reference helps teams understand how vehicles fit together, how they move, and how a proposed change affects the surrounding space.

The long-term ambition is access as straightforward as a mapping service: request the part of the vehicle your project needs and build on the information returned. An engineer gets a starting point for a design. A developer gets data for an application. An educator gets an assembly to explain. Simulation and AI tools get a physical reference, alongside the additional evidence their task requires.

The work of understanding the vehicle carries forward, with its configuration, evidence, and usage rights attached.

**Understand the vehicle once. Build on that knowledge across every project.**

---

### Source notes

The September 6, 2026 editorial revision incorporates the founder-supplied framing of repeated digitization, verified and licensable geometry, persistent component records, and a broader automotive knowledge system. The acquisition problem and commercial opportunity are hypotheses to validate through customer work.

The follow-up expands the timing argument, component lookup, reuse example, signal-to-component relationships, and developer-access analogy. Capture, browser graphics, asset delivery, cloud API, and Neural Concept capability descriptions were checked against primary sources on September 6, 2026. These sources support the existence of the described capabilities; the business timing and economics remain OpenMotive’s hypotheses.

The motion extension adds mechanical relationships, movement envelopes, and clearance checks to the product direction, with calibrated dynamics as a later application. Simscape Multibody and Project Chrono documentation was checked on September 6, 2026. These references establish available modeling approaches, not completed OpenMotive integrations or validated vehicle behavior.

This revision builds on the supplied company thesis, including its engine-first strategy, expansion into whole vehicles, and developer-accessible spatial data model. Competitive statements below were checked against the companies’ own published descriptions on September 5, 2026. These descriptions establish advertised offerings, not independent validation of performance or access to private capabilities. OpenMotive’s positioning and proposed roadmap are strategic hypotheses.

[^nc]: Neural Concept, “Neural Concept Introduces a Physics- and Geometry-Aware AI Design Copilot,” January 7, 2026. https://www.neuralconcept.com/press-release/neural-concept-ai-design-copilot
[^px]: PhysicsX, “The AI-Native Engineering Platform.” https://www.physicsx.ai/platform
[^a2geometry]: A2MAC1, “Unlocking the Potential of Plastic Parts,” June 23, 2025. https://www.a2mac1.com/newsroom/unlocking-the-potential-of-plastic-parts/
[^a2api]: A2MAC1, “Driving Speed and Precision in Automotive Development,” May 16, 2025. https://www.a2mac1.com/newsroom/driving-speed-and-precision-in-automotive-development/
[^caresoft]: Caresoft Global, “Award-Winning Full Vehicle Digital-Twins,” including Deliverables and Packages. https://www.caresoftglobal.com/digital-twins/
[^capture]: FARO Creaform, “HandySCAN 3D BLACK Series: Metrology-Grade Laser Scanner.” https://www.creaform3d.com/en/products/portable-3d-scanners/portable-3d-scanner-handyscan-3d
[^webgl]: Khronos Group, “WebGL — Low-Level 3D Graphics API Based on OpenGL ES.” https://www.khronos.org/webgl/
[^gltf]: Khronos Group, “glTF — The 3D Asset Delivery Format.” https://www.khronos.org/gltf/
[^cloud]: Google Cloud, “Cloud Storage JSON API overview.” https://docs.cloud.google.com/storage/docs/json_api
[^multibody]: MathWorks, “Model Import — Simscape Multibody.” https://www.mathworks.com/help/sm/cad-import.html
[^chrono]: Project Chrono, “Overview of vehicle modeling and simulation.” https://api.chrono.projectchrono.org/vehicle_overview.html