Automotive Best Practices (EN)
Operational, design and compliance recommendations for developers and teams building AI/RAG/agent applications on the automotive domain.
---
Always cite the regulatory source for emission limits
When stating emission values (CO2 g/km, NOx mg/km, PN #/km), always cite the specific Regulation (e.g. Regulation (EU) 715/2007, Annex I) and the measurement cycle (WLTP, RDE). Do not state numbers without an attributable source: limits vary by vehicle category, Euro version and date of application.
Use VIN as the unique vehicle identifier
In any automotive data schema, use the VIN (ISO 3779:2009, 17 characters) as the primary key or reference identifier for individual vehicles. Do not use number plates, proprietary chassis codes, or internal codes as VIN surrogates in traceability systems.
Separate type approval artefacts from the vehicle's commercial record
Type approval data (COC, approved type, variants, versions) has a separate normative lifecycle from commercial data (price list, options, colours). Model these two sets as distinct entities to avoid unnecessary coupling.
Manage the temporal context of regulations (normative versioning)
Automotive regulations have application dates: a vehicle approved in 2020 complies with Euro 6d-temp, not Euro 7. In data models and RAG queries, always include the reference date or applicable normative version to avoid out-of-context answers.
Validate JSONL eval data with non-empty contexts
In automotive golden eval sets, every row must have a non-empty contexts field. Questions about regulations without a retrieval context produce unverifiable answers (high AI hallucination risk for this domain). Apply automated pre-commit validation.
Distinguish tailpipe emissions from well-to-wheel emissions in AI prompts
AI models tend to confuse "zero emissions" for BEVs at the tailpipe with zero total lifecycle emissions. In system prompts and Copilot/GPT instructions, explicitly specify that "zero emissions" refers to WLTP tailpipe emissions and not the well-to-wheel cycle.
Perform ASIL classification before implementing safety-critical logic
For any application interacting with safety-critical vehicle systems (brakes, steering, ADAS), conduct ASIL analysis (ISO 26262) before development. Do not implement ASIL C/D functionality using uncertified languages or frameworks.
Use past-tense naming for automotive domain events
Name domain events in the past participle (VehicleApproved, RecallIssued, EmissionMeasured) in line with the DDD Event Sourcing pattern. This makes it unambiguous that the event represents something that has already occurred, not a command.
Apply GDPR by design to telematics data
GPS location and OBD diagnostic data are personal data when linkable to an identifiable driver. Apply privacy by design (GDPR Art. 25): minimise data collected, anonymise where possible, define clear retention policies.
Version RAG corpora when regulations change
Automotive RAG corpora must be reviewed when new regulations come into force (e.g. transition from Euro 6 to Euro 7, new UNECE Regulations). Add a normative_version field to chunk metadata to filter outdated content in RAG pipelines.
Use CCS2 as the default charging standard for Europe
In applications managing charging infrastructure for the European market, use CCS2 (IEC 62196-3) as the default standard. CHAdeMO is declining in the EU; NACS is predominant in North America. Regulation (EU) 2023/1804 (AFIR) promotes CCS2 on the TEN-T network.
Do not mix WLTP and NEDC data in the same datasets
WLTP and NEDC range and CO2 values are not directly comparable. Always label data with the measurement cycle in the metadata. In ML regression models for range estimation, use only homogeneous measurement data.