Is this car connectable?
A specialized, edge-hosted LLM for connectivity eligibility

Eligibility is a moving target

Connectivity eligibility is not a single fact. It is the intersection of many: make, model, trim, model year, market, the generation of embedded hardware, the telematics protocol, and whether a carrier supports it in that country. Every manufacturer publishes this differently, in different formats and different vocabulary, and revises it every time a new variant ships. A car that is connectable in one market may not be in another. A mid-cycle refresh can swap the hardware generation without changing the model name.

Why hand-written rules don't scale

The obvious approach is a rules engine: a decision tree over all those attributes. We built one. It works until it doesn't. Each manufacturer, market and model year adds branches. The tree grows into thousands of brittle conditions that only a handful of people understand. Every new variant is a code change and a deploy. The maintenance cost grows faster than the coverage.

Our approach: a small, specialized model

Instead of encoding the rules by hand, we let a model learn them. We built a language model specialized on one task: decide connectivity eligibility from heterogeneous manufacturer data. Two design choices carry the whole system.

First, it is specialized, not general. We did not reach for a large general-purpose model. We took an open-weight base model and fine-tuned it with a LoRA adapter on our own eligibility corpus. The result is small and focused. It does one thing, and does it well.

Second, it is self-hosted on Cloudflare. The model runs on Cloudflare Workers AI: serverless GPU inference that executes at the edge, close to the request. Cloudflare's AI Router sits in front of it. The Router is a single control point. It routes between the specialized model and fallbacks, and it lets us manage cost, latency and model version without touching application code.

The data pipeline

A specialized model is only as good as the corpus behind it. We normalize manufacturer feeds into one consistent representation of a vehicle and its eligibility outcome. That normalized corpus is what we fine-tune on. When a manufacturer changes how it describes a variant, we extend the corpus and retrain the adapter. We do not rewrite a decision tree.

Why it matters

Why specialized beats general here

A large general model can answer eligibility questions too. It is also slower, more expensive per call, and harder to keep inside a data boundary. For a decision that sits in the hot path of every connected-service request, latency and cost compound fast. A small model, trained on our own data, is fast enough to run inline, cheap enough to run at volume, and small enough to host where our data has to stay. The trade-off is scope: it does one job. That is exactly what we want.

Early results

Early production signals are encouraging. The specialized model matches our previous rules engine on known cases, and generalizes to variants the rules never covered, at a latency that keeps it inline. Precise latency and cost figures will follow once the pilot stabilizes, and we will update this post with measured numbers.

What's next

We are widening the corpus across more manufacturers and markets, and using the AI Router to test new adapter versions safely behind the same endpoint. The longer-term goal is to apply the same pattern to other vehicle- intelligence decisions that today live in brittle rules.

Scope

This post is about connectivity eligibility. It deliberately keeps raw vehicle identifiers out of the model.