Beyond the scan file: vehicle context software can reuse

A scan or CAD file can show what something looks like. That is useful. It is often not enough.

Before an engineer designs an intake, charge pipe, bracket, or cooling part, they still need to know what the geometry represents: which vehicle and configuration it came from, where each part sits, what it connects to, which dimensions were checked, and which regions remain uncertain. Without that information, teams clean meshes, align assemblies, and rediscover mounting points—then do much of the same work on the next project.

OpenMotive’s near-term job is practical. We turn vehicle geometry into structured engineering context for a real design task. Over time, we believe the way that context is represented should be shareable beyond any one tool or company.

This article is about that longer idea. It is not a claim that an industry standard already exists, or that our current site visuals are measured engineering datasets.

What “reusable” actually means

It does not mean a prettier folder of meshes. It means vehicle information organized well enough to use again in future engineering work.

• 3D geometry
• part names and stable identifiers
• where each part sits in the vehicle
• mounting points and interfaces
• nearby components
• verified measurements
• vehicle configuration
• what was scanned, inferred, or left unknown
• dataset version and source

So instead of a loose file like wrx_engine_bay_final_v2.stl, the useful unit looks more like: this is a defined WRX engine-bay configuration; these are the components in it; these are their positions and interfaces; these dimensions were checked; these regions are still uncertain.

Once vehicle geometry has been organized and verified against available evidence, future projects can build on it instead of reconstructing the same information again.

Do not invent another CAD format

Existing standards already handle geometry well. STEP AP242 is designed for managed 3D engineering data, assemblies, configurations, and long-term product-data exchange, including automotive use. glTF handles efficient runtime delivery of 3D scenes.

The more interesting gap is the context around automotive geometry: identity, spatial reference, interfaces, relationships, motion where known, provenance, and configuration.

We are exploring an open schema for that layer. Working concept: Open Vehicle Context Schema (OVCS)—a vendor-neutral way to describe what a piece of vehicle geometry represents, where it belongs, how it connects, how it moves when that is known, and how trustworthy each region is.

The intent is not that everyone must use our proprietary geometry format. It is: keep using STEP, Parasolid, STL, OBJ, glTF, and related formats. OVCS would define how vehicle engineering context is attached to those assets—as a schema we build and use first, then open when it is stable enough to share.

Why this matters for trust

Software can automate quality checks, alignment, dimension comparisons, and deviation analysis. It cannot magically prove a scan is physically correct without an independent reference—OEM drawings, trusted geometry, or measurements from a calibrated device.

That limit is a product feature, not a footnote. A useful representation should distinguish measured mounting holes from surfaces filled during mesh cleanup, and from undersides that were never captured.

Layers worth standardizing over time

We are not publishing a finished specification today. Our immediate product work—building a packaging workspace for aftermarket engineers—forces these exact concepts into our internal data schema. Those concepts are candidates for an open schema later:

1. Identity — stable IDs for vehicle, market, powertrain, assembly, component, and revision.
2. Spatial reference — units, origins, frames, and transforms so datasets can share a spatial system.
3. Interfaces — flanges, bolt patterns, fluid ports, connectors, and drivetrain mates as addressable features.
4. Assembly relationships — contains, mounted to, connects to, adjacent to, compatible with.
5. Motion — joints, ranges, and envelopes where evidence exists (later).
6. Provenance and confidence — measured, captured, reference-checked, calculated, reconstructed, inferred, unknown—with method and limits.
7. Configuration and versioning — which physical configuration a package represents, and which revision an engineer designed against.

Conformance levels can make adoption gradual: identified geometry first; then spatial; then connected; then verified; then dynamic. That is more meaningful than calling something a premium scan.

How we intend to earn it

We will not start by declaring an industry standard from a long PDF. Build the engineering workflow and package schema for a real job. Use that schema in the workspace, reports, and APIs. Open the schema when it is stable enough for critique. Invite partners to produce compatible context where rights allow. Only then consider broader working-group or formal standardization paths.

Anyone should eventually be able to represent vehicle context using an open schema. OpenMotive’s commercial work remains the datasets, verification, tooling, and workflows around it.

What this means for software and AI

If compatible packages expose the same concepts—components, interfaces, neighbors, reference frames, verified measurements, unknown regions—engineering software and AI systems can work against documented vehicles instead of assuming them.

That only helps if the representation stays honest about uncertainty. A confident-looking model with invisible gaps is worse than a partial model with explicit unknowns.

Closing

OpenMotive’s near-term focus stays the same: prepare vehicle geometry for engineering work, mark what is verified and what is not, and help teams spend less time reconstructing the vehicle so they can spend more time engineering what comes next.

An open vehicle-context schema is the longer bet: that the way we represent physical vehicles in software can become shared infrastructure—not because we announce it, but because the workflow makes the schema real first.