An AI-Native Lead Qualification Engagement for Automotive

What the field reality means for the architecture

The hardest design question in automotive lead qualification engagements is where to draw the boundary between the digital system and the physical operation. Cross that boundary too far in either direction and the workflow breaks: too digital and field operators ignore it, too physical and the analytics layer cannot tell what is happening at scale.

We draw the boundary at the decision interface. The AI-native workflow ingests sensor data, system records, operator notes, customer signals, and external context. It surfaces the relevant subset to the decision-maker — usually an operator with physical-world context — with the supporting evidence pre-assembled. The operator's decision is captured, executed in the system of record (DMS or adjacent), and logged for the next iteration of calibration. The system does not pretend to know things it does not know; the operator does not have to relay things the system already has.

The architecture choice that follows is data-locality. For automotive, the data that matters lives in three places: the central system of record, the field-edge devices, and the operator's head. The first two are connectable; the third is captured through the reviewer interface and the operator notes layer, which we treat as a first-class data source rather than a free-text afterthought. By month six of Run, the operator notes have become a structured corpus that the retrieval layer queries — your field team's accumulated craft, finally legible to the analytics layer.

The risk we explicitly engineer against in automotive is the workflow that optimizes the dashboard at the expense of the field. We see this failure mode often in vendor-led AI deployments: the metrics look great, the operators are silently working around the system, the operation degrades. The instrumentation we ship reports both — central metrics and field-feedback signals — so leadership can detect the gap if it opens.

From kickoff to thin-slice production

For automotive engagements on lead qualification, the first 30 days are not about building features — they are about producing the labelled test set that will govern every subsequent decision. The test set is the most valuable artefact of the engagement, because it is what makes "did this change make the workflow better?" a measurable question instead of an opinion.

We spend week 1 on test-set capture. The operator team picks 200-400 representative cases spanning routine, exceptional, ambiguous, and adversarial. Each case has the expected outcome, the expected reasoning, and the source citations a reviewer would want to see. The test set is reviewed for coverage gaps, signed off by the engagement sponsor, and version-controlled alongside the prompts.

From week 2, every prompt change, retrieval-index update, and threshold calibration is gated by the eval harness running against this test set. Improvements that beat the incumbent across enough metric slices get promoted; changes that look impressive on one slice but regress on another are flagged for review. By the end of Build, the test set has grown to 600-1000 cases, the workflow has been through 15-25 eval cycles, and automotive leadership has empirical evidence that the system performs on their data, not on a vendor's demo.

This is the practice most automotive AI projects skip because it looks like overhead in the first three weeks. It is the practice that determines whether the workflow survives the third quarter of Run, which is why we treat it as the foundation of Build rather than an afterthought.

If you have ever shipped a non-trivial production system you know the first 30 days are make-or-break. For lead qualification in automotive, the make-or-break decisions are: what does the labelled test set look like, what is in scope for the integration against DMS, where does the automation boundary sit, and how is the reviewer queue UX going to feel to your operator team. We answer all four in the first two weeks.

Labelled test set: 200 cases minimum by end of week 2, signed off by the engagement sponsor, covering routine, exceptional, ambiguous, and adversarial. Integration scope: documented and bounded by end of week 1, with the data-access plan reviewed by your engineering team. Automation boundary: drawn deliberately in week 2 — full automation lane, drafted-with-review lane, reserved-to-human lane — with confidence thresholds calibrated against the test set. Reviewer UX: prototyped in week 2 with two of your senior operators in the loop, iterated through week 3.

From day 30, the Build sprint shifts to widening the envelope. The decisions made in the first month are the ones that shape the next 12 months of operating the workflow — which is why we resist the temptation to skip ahead to the model layer before the test set and the reviewer UX have been earned.