Skip to content

AI for Automotive

Warranty cost down. The recall caught before the news catches it.

We engineer AI for OEMs and connected-vehicle platforms: fleet-wide DTC monitoring, OTA targeting and verification, warranty analytics that surface recall-worthy patterns in your telemetry, dealer service decisioning, and production integration of ADAS perception stacks.

Built on your vehicle data, your campaign tools, and the regulatory posture type approval requires.

Discuss your warranty and telemetry workflowSee how the system works

The operational reality

Your fleet streams millions of signals a day. Warranty is in them. The next recall is in them.

Engineers read the slice they have time for. The rest ships to the dealer.

The recall is in last month's data. Someone just has to read it.

Felt by Chief Engineers, Heads of Powertrain and ADAS, the Head of Connected Services, the Head of Warranty, and the dealer operations teams holding the customer in the service bay.

  1. 01

    Telemetry ingest

    Connected vehicles stream DTCs, signal snapshots, and ride-quality data back to the OEM platform through the TCU. Volume is high, cadence varies by trim.

    Friction · The platform holds the data; no one has time to read it at the fleet level.

  2. 02

    DTC monitoring

    Fault codes are logged against VIN, model year, trim, and build. Rate-of-rise and clustering are what matter, not individual events.

    Friction · The DTC that becomes a recall sits in a dashboard that is read weekly, not when the signal spikes.

  3. 03

    Root-cause analysis

    A fault pattern is matched to a part, a supplier lot, a build date range, or a software release. Engineering decides whether it is a service campaign, a soft recall, or a safety recall.

    Friction · The matching is manual; prior-model-year signal is in a spreadsheet nobody opened.

  4. 04

    OTA campaign

    A software remediation is scoped, tested, and rolled out to the affected VIN population through a staged OTA campaign under UN R156 process controls.

    Friction · Targeting the right VIN population without over- or under-including is still a manual exercise.

  5. 05

    Dealer service

    Hardware remediations route to dealers. Dealers see the recommended procedure, parts availability, and the customer's prior history in the service system.

    Friction · Dealers improvise when the fault code is new; parts arrive late because demand was not forecast.

  6. 06

    Warranty analytics

    Warranty claims are read against telemetry, build data, and supplier lots. The pattern feeds back to engineering, supplier quality, and the next model year.

    Friction · The feedback loop closes slowly; the next-year programme repeats the same supplier mistake.

Swipe the workflow

Where the work breaks

The friction is in the places nobody budgets for.

  • 01

    The recall-worthy signal is already in your telemetry.

    How we fix it · A system we build catches this before it costs you.

    Impact · Months of avoidable claims accrue; the recall announcement lands after the pattern was readable in field data.

  • 02

    DTC backlogs are read on a weekly cadence, not when they spike.

    How we fix it · A system we build catches this before it costs you.

    Impact · A build-date cluster is noticed late; the fix lands on a model year that could have avoided it.

  • 03

    OTA campaign targeting over- or under-includes.

    How we fix it · A system we build catches this before it costs you.

    Impact · Vehicles that did not need the update see it; vehicles that needed it do not. Dealer and customer trust takes the hit.

  • 04

    Dealers improvise when the fault code is new.

    How we fix it · A system we build catches this before it costs you.

    Impact · Repeat visits, extended cycle time, and a customer survey that puts you below the brand average.

  • 05

    The warranty feedback loop closes a programme too late.

    How we fix it · A system we build catches this before it costs you.

    Impact · The next-year programme inherits the same supplier mistake because the data never reached engineering in time.

What we would build

Systems, not features. Each with its own job.

  • 01

    Fleet-wide DTC monitoring

    The DTC that becomes a recall is readable in the data months earlier. No one has time to watch at the fleet level.

    Who benefits · Quality engineers, powertrain and ADAS leads, and the connected services team.

    Inputs
    Connected-vehicle telemetry (DTCs, signal snapshots, ride-quality), VIN build data, supplier lot and software release information, and prior-model-year quality history.
    What the system does
    A monitoring layer tracks rate-of-rise, clustering by build range and software release, and prior-model-year analogues. Alerts fire when a cluster crosses the engineer-defined threshold, with the top contributing signals attached.
    Output
    A ranked alert feed: each fault pattern with its fleet-wide hit rate, the VIN population affected, and the matching prior-model-year signal where it exists.
    Benefit
    Patterns reach engineering while a service campaign is still cheaper than a safety recall.
    Human stays here
    A quality engineer decides whether the pattern is a service campaign, a soft recall, or a safety recall. The system surfaces; the engineer decides.
  • 02

    OTA campaign targeting and verification

    Targeting a software remediation to the exact VIN population is still manual, and verifying it landed is a separate exercise.

    Who benefits · Connected services, OTA release managers, and quality engineering.

    Inputs
    The remediation scope, the current software baseline per VIN, the build and option configuration, and the UN R156 process controls your type approval requires.
    What the system does
    The system scopes the affected VIN population against the remediation criteria, stages a canary cohort, and verifies on telemetry that the fault signature actually goes away. Reports are produced in the format your type-approval authority expects.
    Output
    A targeted campaign with a canary wave, a documented verification report on fault signature, and the UN R156 artefacts an authority can read.
    Benefit
    Campaigns reach the vehicles that need them, and leave the ones that do not alone.
    Human stays here
    Release decisions, cohort approval, and campaign go/no-go remain with the OTA release manager under your R156 process.
  • 03

    Warranty analytics with the loop closed to engineering

    Warranty claims and telemetry live in different systems. The feedback loop to engineering closes a programme too late.

    Who benefits · Warranty operations, supplier quality, and engineering programme leads.

    Inputs
    Warranty claim records, dealer repair orders, telemetry, build and supplier lot data, and the engineering parts catalogue.
    What the system does
    Claims are joined against telemetry and supplier lots; cost-per-vehicle is attributed down to the responsible subsystem; patterns are surfaced to engineering with the supporting evidence linked.
    Output
    An engineering-ready warranty view: cost-per-vehicle by subsystem, supplier lot exposure, and the top candidates for the next-year countermeasure programme.
    Benefit
    The next model year inherits a countermeasure, not the same mistake.
    Human stays here
    Supplier claims and countermeasure decisions remain human. The system attributes and ranks; it does not file.
  • 04

    Dealer service decisioning

    When a new fault code arrives, dealers improvise. Repeat visits and cycle time climb; customer-experience survey scores fall.

    Who benefits · Dealer service advisors, master technicians, and dealer operations leaders.

    Inputs
    The vehicle's DTC history, the current fault, the recommended procedure from engineering, parts availability, and the customer's prior service history.
    What the system does
    A decisioning layer surfaces the recommended procedure for the fault, forecasts parts demand against incoming VIN appointments, and routes complex cases to a master technician with the context attached.
    Output
    A prepared service recommendation per repair order, with parts, time, and the engineering context the technician needs.
    Benefit
    First-time-fix rate rises; cycle time falls; parts arrive before the appointment.
    Human stays here
    The technician decides and signs the repair order. The system supports, it does not diagnose on its own.
  • 05

    ADAS perception integration

    Production integration of a perception stack is slower than the model work. The road time, the edge cases, and the compliance evidence pile up.

    Who benefits · ADAS engineering leads, integration teams, and homologation.

    Inputs
    Your perception stack, the vehicle sensor suite, your scenario library, and the edge cases surfaced from fleet telemetry.
    What the system does
    We integrate your perception stack into the production flow: scenario-coverage reports against your library, edge-case triage from telemetry, regression tests on your target hardware, and the evidence pack your homologation team needs.
    Output
    A production integration path: a repeatable release flow with scenario coverage, regression evidence, and the artefacts your homologation review expects.
    Benefit
    Software gets to the vehicle on cadence. The integration becomes the predictable part of the programme, not the risky one.
    Human stays here
    Perception model development, release approvals, and homologation sign-off stay with your engineering and compliance teams.

Show the system

What it could look like in your hands.

A design concept, not a shipped product. Interfaces like this get drawn out before any code lands, so the system reads back the way the people using it work.

quality / fleet diagnostics

Fleet pulse

  • Vehicles online

    1,842,017

  • Open DTCs tracked

    214

  • OTA campaigns in progress

    6

  • Warranty cost (90d, projected)

    $18.4M

VIN-level alert feed

  • VIN ****3912

    Sedan EV, 2026, trim L

    Drive motor inverter performance

    P0A94

    127 of 48,210 VINs in last 7 days

    medium

  • VIN ****7704

    SUV EV, 2025, trim R

    Invalid data from ECM

    U0401

    42 of 61,880 VINs in last 7 days

    low

  • VIN ****2185

    Sedan EV, 2026, trim L

    Drive motor inverter performance

    P0A94

    127 of 48,210 VINs in last 7 days

    medium

  • VIN ****5620

    Pickup EV, 2026, trim S

    ADAS forward camera calibration

    C1A52

    19 of 7,340 VINs in last 7 days

    high

  • VIN ****9044

    SUV EV, 2026, trim L

    Drive motor inverter performance

    P0A94

    127 of 48,210 VINs in last 7 days

    medium

  • VIN ****1267

    Sedan EV, 2024, trim L

    HVAC blower module

    B1A2F

    88 of 112,500 VINs in last 7 days

    low
Synthetic data. This is a design concept of how a quality engineer could see fleet-wide fault signal, the VIN-level feed behind it, and the remediation path for a focused code.

End-to-end workflow

From the trigger to the outcome.

A representative DTC-to-remediation path. Automated stages run the moment the data lands; human stages are explicit and never skipped.

  1. 01

    Telemetry lands

    DTCs, signal snapshots, and ride-quality data arrive from the fleet. VIN build and supplier lot context is joined on ingest.

    Automated
  2. 02

    Fleet-wide pattern detected

    A rate-of-rise or build-range cluster crosses the engineer-defined threshold; the pattern is scored against prior-model-year analogues.

    Automated
  3. 03

    Alert surfaced to engineering

    The alert lands in the quality engineering tool of record with the top contributing signals, the affected VIN population, and the matching prior signal.

    Integration
  4. 04

    Low-confidence patterns held

    Where the pattern does not clear the detection threshold or the prior-signal match is weak, the alert is held rather than paging a team.

    Guardrail
  5. 05

    Engineering decides remediation

    A quality engineer decides whether the pattern is a service campaign, a soft recall, a safety recall, or a monitoring hold.

    Human in loop
  6. 06

    OTA campaign scoped and canaried

    For software remediations, the VIN population is scoped against the remediation criteria and a canary cohort is staged under R156 process controls.

    Automated
  7. 07

    Verification on telemetry

    After the canary wave, telemetry is read to verify the fault signature actually goes away before the campaign is widened.

    Automated
  8. 08

    Dealer and customer path

    For hardware remediations, dealer service recommendations, parts forecasts, and the customer communication are prepared.

    Integration
  9. 09

    Audit trail logged

    Every detection, scoping, canary, and verification is logged with model version, inputs, and engineering decisions. Type-approval authorities can read the trail.

    Guardrail

How exceptions are handled

  • If telemetry drops for a VIN cohort, the system reports data gap rather than inferring a clean signal.
  • If the canary verification shows the fault signature persists, the campaign halts and routes back to engineering.
  • If a safety-relevant pattern is detected, the system notifies the responsible engineering lead immediately and does not stage a silent campaign.
  • If an EU VIN cohort is involved, data handling follows the GDPR data boundary; purpose and retention are enforced in the pipeline.

How it is engineered

Built on your stack, not ours.

Design choices that make this run against a real connected-vehicle platform and your release process, not around them. We build to your TCU interface, your campaign tools, and your type-approval posture.

01

Vehicle data integration

Ingest from your connected-vehicle platform through its supported APIs: DTC streams, signal snapshots, build data, and campaign status. Writes land only through the release and campaign tools your R156 process already governs.

02

Pattern detection

Rate-of-rise, build-range clustering, and prior-model-year analogue matching tuned to the signals your engineering team actually watches. Detection thresholds are engineer-authored, not a vendor default.

03

OTA campaign tooling

Integration with your release management and OTA campaign tooling. Scoping, canary waves, and verification reports are produced in the formats your R156 process requires.

04

Identity and access

Single sign-on through your identity provider. Engineering, release manager, and dealer-operations roles are attributable; the system never acts under a shared service account.

05

Regulatory posture

UN R155 cybersecurity management system expectations and UN R156 software update management system process controls are first-class. GDPR applies on EU telemetry; retention and purpose are enforced in the pipeline.

06

Observability and evaluation

Every detection, scoping, canary, and verification is logged with model version, inputs, and the engineer's decision. An evaluation harness watches drift and flags regressions against your historical outcomes.

What the business will measure

Numbers the operator already watches.

We agree on metrics and baselines before building. These are the numbers an engineering and connected-services leader usually watches when deciding whether a system is working.

  • 01

    Warranty cost per vehicle

    Baseline today

    Measured today: warranty cost per vehicle by model, trim, and build range, from the warranty system of record.

    How it moves

    Patterns reach engineering while a service campaign is still cheaper than a safety recall; countermeasures land in the next model year.

  • 02

    DTC-to-root-cause time

    Baseline today

    Days from the first clustered DTC appearing in telemetry to a documented root cause in the quality engineering tool.

    How it moves

    Fleet-wide clustering fires on signal, not on calendar; prior-model-year analogues shorten the analysis.

  • 03

    OTA campaign cycle time

    Baseline today

    Days from remediation scoped to canary verified to full rollout, per campaign.

    How it moves

    Targeting, canary staging, and verification on telemetry are the system's job; the release manager approves rather than assembles.

  • 04

    First-time-fix rate at dealers

    Baseline today

    Share of repair orders closed without a repeat visit on the same complaint, by model and trim.

    How it moves

    Service decisioning surfaces the right procedure, the parts arrive on time, and complex cases route to a master technician with context.

  • 05

    Fleet uptime

    Baseline today

    For connected fleet operators: scheduled hours vs available hours, by model and operator.

    How it moves

    Predictive maintenance from telemetry pulls work forward from a roadside breakdown to a planned bay visit.

Human in the loop

Oversight, safety, and the regulatory posture

Where the humans stay in control.

The system is designed around what type-approval authorities, cyber-security teams, and warranty engineers already expect. Nothing is autonomous that should not be.

  • 01

    UN R155 cybersecurity management

    The system respects the controls expected under UN R155 CSMS: identity, logging, change control, and incident response are first-class. Nothing we deploy sits outside the regime.

  • 02

    UN R156 software update management

    OTA scoping, canary waves, and verification reports are produced in the format your type-approval authority reviews under R156. Release decisions stay with your release manager.

  • 03

    FMVSS and safety recalls

    The system surfaces patterns and drafts documents. Decisions on recall vs service campaign, and the regulator-facing filings, stay with your product safety and legal functions.

  • 04

    GDPR on EU telemetry

    Purpose, retention, and data-subject rights are enforced in the pipeline for EU VIN cohorts. Data flows out of the EU only where a lawful basis exists.

  • 05

    Engineer sign-off on remediation

    No campaign is scoped and sent without the responsible engineer approving the population, the remediation, and the canary cohort.

  • 06

    Attribution and audit

    Every detection, scoping, canary, and verification logs model version, inputs, and the engineer's decision. An authority audit can reconstruct how any campaign was handled.

Proof

Work we have shipped, and the shape of what we build.

Real engagements where we can speak to them, and representative use cases where we cannot.

How the build runs

Scoped tightly, shipped in phases.

Fixed price per phase, approved before the phase starts. You own the code, the models, the data, and the deployment.

  1. 01

    Discovery

    Two weeks. We shadow quality engineering, release management, and dealer operations, map the real workflow against your connected-vehicle platform and release tooling, and agree on the metrics we will move and how we will baseline them.

  2. 02

    Prototype on real telemetry

    Four to six weeks. One subsystem, one model-year cohort, one proof of mechanism. Engineers use it in parallel to real work; we measure against the baseline.

  3. 03

    Production rollout

    Eight to twelve weeks per workflow. Platform integrations, SSO, R155 and R156 evidence, GDPR controls on EU cohorts, and the oversight workflow your product safety and release teams signed off on.

  4. 04

    Handover

    You get the full source, the detection thresholds, the evaluation suite, the evidence packs your authorities expect, and a two-week walkthrough with your engineering and connected-services teams.

  5. 05

    Optional ongoing support

    A fixed-term support agreement for monitoring, platform interface changes, and regulatory posture updates. Never a retainer dependency.

Common questions

Answers before the first call.

01Does this touch our ADAS perception models?
We integrate your perception stack into the production flow: scenario coverage, edge-case triage from telemetry, regression on target hardware, and the evidence pack homologation expects. We do not claim to train your perception models from scratch; that is work your ADAS organisation owns.
02How does this meet UN R155 and R156?
The system respects the CSMS controls expected under R155 and produces the artefacts your type-approval authority reviews under R156: scoping, canary waves, telemetry verification, and release decision records. Release decisions stay with your release manager.
03What about EU telemetry and GDPR?
Purpose, retention, and data-subject rights are enforced in the pipeline for EU VIN cohorts. Data flows out of the EU only on a lawful basis you have already established with your DPO.
04Can you integrate with our existing connected-vehicle platform?
Yes. We build to your platform's supported APIs rather than replacing it, and we write back only through the release and campaign tools your R156 process already governs.
05Will engineers trust the pattern alerts?
Trust is a workflow problem, not a model problem. Every alert carries its top contributing signals, the affected VIN population, and the prior-model-year analogue where it exists. Detection thresholds are engineer-authored. We measure override rate as a product metric and tune to it.
See the other details on the FAQ page

Next step

A thirty-minute conversation. Bring one subsystem where warranty cost or DTC-to-root-cause is not where you want it to be, and we will walk through what the first phase would look like, where the measurements come from, and what has to be true for your release and product-safety teams to approve it.

Discuss your warranty and telemetry workflow

Helpful to have on the call

Helpful to have on the call: your connected-vehicle platform, one subsystem with a warranty or recall pain point, and the person who owns the metric you would like to move.

Explore

A different problem in every sector, one engineering standard underneath.

Featured · AI for healthcare

Healthcare

Why is your clinician still charting at midnight?

Your clinicians are charting until midnight and your front desk is drowning in prior auths. We build AI that writes clinical notes automatically, triages patients to the right care faster, and finds any record with a simple question, so your people spend their hours on patients instead of paperwork.

See AI for healthcare
stallwart / healthcare

Live run

Healthcare

Running
as of nowhealthy
See every industry we build for

An AI-First Engineering Company

Get a price in one call.

One 30-minute call. You leave with an architecture, a fixed price, and a start date. No charge, and no slide deck.

Booking now for December 2026

Book a callSee how it works