The context layer
A scan or CAD file can show what something looks like. Engineering still needs to know what it is, where it sits, what it connects to, what surrounds it, what can be trusted, and what remains unknown.
Structured engineering context is more than the shape of a machine. It records what the parts are, where they are, how they connect, what surrounds them, what has been measured, where that information came from, and what remains unknown.
Engineers often reconstruct that reality by hand from scans, CAD, measurements, drawings, and tribal knowledge—asking the same questions every project: What is this? Where does it connect? What is nearby? How much room is available? Can I trust this measurement? What was never captured? What matters for this job?
OpenMotive is being built to organize that evidence around the real machine so teams reuse it instead of rebuilding it.
A current development prototype supports a manual workflow: place a replacement assembly inside a scan, mark the space it needs, and save that placement. It does not yet automatically check clashes or verify clearances. Product direction is a shared model that also records part identity, connections, and unknowns—more than geometry alone.
Turn vehicle geometry into structured engineering context.
Beyond the file
If you’re designing a new intake, a 3D file of the engine bay may show shape. It often still doesn’t tell you what each object is, where it belongs, where the intake must connect, what sits nearby, which surfaces you can trust, which areas were never captured, or which vehicle setup the data represents.
Without that context, teams buy access to a car, measure mounting points by hand, clean and align meshes, guess at missing surfaces, and repeat the preparation on the next project.
The problem is not just getting 3D data. The problem is making that data reliable and reusable for engineering.
Make vehicle knowledge reusable.
A programmable vehicle
When we say a vehicle is programmable, we don’t mean the vehicle itself becomes software. We mean software can understand enough about the physical vehicle to work with it.
A computer should not only see 3D shapes. It should understand ideas like: this is the turbo inlet; these are its mounting points; this component is about 18 mm away; this measurement was verified; this area hasn’t been captured yet.
That is what structured engineering context aims to represent:
- geometry, and what each part is
- where parts sit and how they connect (their interfaces)
- nearby components and available space
- measurements, where they came from (provenance), and how trustworthy they are by region
- vehicle configuration and documented constraints where available
- what remains unknown or uncaptured
Progression: physical vehicle → geometry → structured engineering context → practical spatial checks → design and simulation tools → AI-assisted engineering.
Early operations are practical: retrieve the relevant region, locate interfaces, inspect neighbors, place a candidate part, check interference, measure clearance, and export what an engineer needs in CAD. Motion-aware checks and richer integrations come later, as the data and methods earn that scope.
Geometry alone does not answer structural, thermal, durability, or manufacturing questions. Those claims need the right physical properties, loads, tolerances, operating conditions, and validation.
Give engineering software the physical context to design against real vehicles.
First engineering outcomes
An engineer designing an intake does not need a perfect digital model of the entire vehicle. They need the relevant region: the turbo inlet, mounting points, nearby fan, hood envelope, wiring, available clearance, and confidence in the measurements that matter for that job.
The first useful outcomes are packaging and fitment for a defined vehicle region—starting with aftermarket engine-bay work such as intakes, charge pipes, cooling components, and brackets. With prepared context, an engineer should be able to:
- see where a new part must connect
- inspect what surrounds it
- check whether a candidate part interferes with neighbors
- measure clearances against named nearby components
- see which areas are missing or unmeasured
- bring the relevant subset into CAD
- produce an assessment that states its limits
The aim: less repeated geometry preparation between “I need to design this part” and “I have vehicle context I can design against.” Then compare that digital work with the physical vehicle.
Known and unknown
One part of a model might come from a verified measurement. Another might be reconstructed from incomplete data. Another area may never have been captured at all. OpenMotive should preserve those differences instead of labeling the entire model “accurate.”
We distinguish observed geometry (confirmed by direct measurement or capture), inferred geometry (completed from context or symmetry), and unknown regions (no data, or conflicting information). Confidence is assigned by region—not one blanket accuracy score.
Software can automate quality checks, alignment, dimension comparisons, and deviation analysis. It cannot prove a scan matches the physical machine without an independent physical reference or verified measurement—such as OEM drawings, trusted geometry, or a calibrated device. Without that reference, OpenMotive can say a model appears internally consistent. It cannot honestly claim absolute agreement with the physical part.
Uncaptured space is not free space. Not scanned does not mean empty.
Make what is known usable, and what is unknown visible.
How the library grows
The first project creates context for one engineering task. The next project can reuse it. Every verified component, interface, measurement, and region makes future work easier.
A scan of an engine bay might begin as geometry for one intake. Once parts are identified, positions aligned, connections documented, and measurements checked, that same information can support cooling, routing, packaging, or another component nearby.
The goal is not to collect as many CAD files as possible. It is to build a connected, increasingly useful understanding of the machine. Customer data, licensed geometry, partner scans, and OpenMotive measurements can all contribute when quality and usage rights allow.
Software and AI
OpenMotive does not need AI to be useful. The same structured engineering context that helps an engineer today can eventually give AI systems the physical grounding they need to work with real machines.
That context can also power fitment tools, assembly explorers, simulation workflows, and other applications through consistent identifiers and reusable geometry. As AI becomes more capable of generating and evaluating designs, it will need documented physical context—not an assumed vehicle.
Give AI a documented vehicle to design against, not an assumed one.
Where this leads
The long-term goal is not another library of 3D files. It is to make physical machines understandable and usable by software—while preserving the evidence and uncertainty behind that understanding.
Richer context could later support motion-aware fitment, automated packaging, routing, simulation, diagnostics, and education. That path is earned by making structured engineering context reusable in real engineering workflows first.
Less time reconstructing what exists. More time engineering what comes next.