Fleet onboarding: architecture for technical data and recalls

Design a record, not one giant response

Vehicle onboarding may combine classification, technical checks, and recall campaigns. Every capability has its own identity, date, and possible state. Merging every JSON object without a model creates a structure that is difficult to update and audit.

Create a vehicle record with independent modules. The record references the current result for each module and keeps only the history needed to explain changes.

Separate facts, signals, and decisions

A source response is an observation with context. The decision to enable a vehicle, request documentation, or send a case to review belongs to the company and should live in another layer.

This avoids presenting an API as legal authority and lets internal rules change without altering received evidence. It also supports human review before consequences are applied to ambiguous cases.

Model freshness and absence explicitly

Data observed yesterday and data queried six months ago should not look identical. Store observation date, capability, version, and request status alongside the result required by the operation.

No result does not mean non-compliance. It may indicate invalid input, an unavailable source, different coverage, or a contract that does not return that signal. The interface must distinguish these scenarios.

Build onboarding in stages

A first stage validates identifiers and creates the record. A second stage runs independent capabilities. A third evaluates company rules and separates approved, observed, and review cases.

For bulk uploads, this design prevents a problem in one capability from blocking the whole batch. It also lets teams refresh only the signal that expired, without rebuilding vehicle identity.

• Preserved vehicle identity.
• State and date per capability.
• Company decision separated from data.
• Human review for inconclusive cases.