The phrase software-defined vehicle sounds like a category about cars. It isn't. It is a category about high-content, regulatory-bounded, multi-domain mechanical systems where the share of value moving from steel into software keeps rising. Tractors, harvesters, and combines are exactly that.
At a $2B-R&D agricultural-machinery OEM, dominant in autonomous tractors and precision-ag, SPREAD is running Product Explorer in R&D against the same data-fragmentation pattern that surfaced in automotive five years ago. The structural question: one engineering ontology travels across mechanical-systems verticals. The customer is the first agricultural test.
The transition isn't just for cars
The customer's fleet increasingly defines itself by software content: autonomy stacks, perception modules, AI-driven precision agriculture, a fleet-operations cloud platform, autonomy-team acquisitions absorbed into the autonomous-farming roadmap.
The transition is the same one that hit automotive five years ago, except the equipment is bigger, the operating environments are harsher (mud, dust, multi-week duty cycles, GPS-denied fields), and the regulatory regime around precision-agriculture data is still forming. The structural problem is not new. It is the SDV (software-defined vehicle) transition under a different brand of paint.
What the engineer's day looks like
Picture an R&D engineer at the customer preparing a flagship tractor series for a new vision module integration with a specific planter implement. Before integration, the verification list:
"Which sensor-fusion calibrations are certified for this tractor-and-implement combination? Which perception-stack revisions have been integration-tested with the new module? Which fleet-operations telemetry contracts does the module satisfy? What historical defect data exists for similar configurations?"
Today that verification spans five disconnected sources: CAD (computer-aided design), perception-stack lineage from the autonomy-team acquisitions, calibration archives, fleet-operations telemetry schemas, and tribal knowledge from the integration team. It is the same fragmentation pattern that produced the automotive diagnosis: "Software components, ECUs (electronic control units), signals and physical wiring lived in disconnected systems; engineers spent days tracing how a single change rippled across functional and physical architectures." Different vertical, identical structure, and one ontology ingests the ag-side five at the customer's scale.
The vision-module + tractor + planter scenario is illustrative of the customer's R&D scope; the specific use case under evaluation is not disclosed.
What Product Explorer's view surfaces
For the vision-module-on-tractor query, Product Explorer returns a single tractor-and-implement-scoped view containing:
- Certified sensor-fusion calibration set for the tractor + planter combination, ranked by integration-test history and field-condition coverage
- Perception-stack revisions integration-tested with the new vision module, with delta against the platform baseline and the autonomy team's regression results
- Fleet-operations telemetry contracts the module satisfies, with backward-compatibility flags against the existing deployed firmware
- Historical defect data on similar configurations, surfaced from integration records and indexed by failure mode
- Tribal-knowledge entries from the autonomy team, queryable in natural language ("how did the autonomy team handle this row-following edge case?")
The view is what Product Explorer returns inside the pilot environment; The deployment view scales with the customer's full ag-data shape, not a curated slice. One ontology ingests those five sources at the customer's scale; the multi-day senior-engineer search it replaces is the baseline.
The category bet underneath
The SDV transition is hitting machinery now and is on the curve toward energy, healthcare devices, defense, and aerospace. The underlying problem, domain-fragmented engineering data layered over high-content, multi-domain product transitions, looks structurally the same in each. SPREAD's structural argument: one engineering ontology addresses all of them. The agricultural pilot is the first cross-vertical data point.
Program shape
| Vertical | Agricultural machinery · dominant OEM in autonomous tractors and precision-ag |
|---|---|
| Product surface | Product Explorer in R&D |
| Engineering scale | ~$2B annual R&D spend, multi-domain mechanical systems |
| View composition | 5 elements · certified calibration set · integration-tested perception revisions · telemetry contracts with backward-compat flags · indexed defect history · NL-queryable tribal knowledge |
| Data sources unified | 5 sources · CAD · perception-stack lineage · calibration archives · fleet-operations telemetry · tribal knowledge |
| Engineering environment | Mud, dust, multi-week duty cycles, GPS-denied operating conditions |
| Regulatory backdrop | Precision-agriculture data regime still forming |
| Cross-vertical thesis | One engineering ontology travels from automotive into agricultural-machinery R&D, ag-data shape fits without bending the ontology |
| Comparable transition | Automotive SDV transition, five years earlier in the curve |