Blog
What's Really Aging Inventory On The Lot
Joel Webb
August 17, 2026
What's Really Aging Inventory On The Lot

How an Explainable AI Model Found $219K in Trapped Floorplan Capital

A large regional auto group came to us with a question: why is this vehicle still sitting on the lot? I analyzed their full new and used inventory as of May 2026, everything from compact sedans to heavy duty commercial trucks, across five store locations and several brands.

I've anonymized the dealer group and store names for this write up; the underlying data and results are real.

Each record includes the fundamentals an inventory manager already tracks: new versus used, model year, make, model, body style, MSRP, cost, lot price, mileage, transmission, interior color, and dealer location. It's exactly the kind of operational data most dealer groups already have, which makes it a good question every used and new car operation eventually runs into: are we actually managing what's driving days on lot?

From Raw Data to a Working Model in Minutes

Using Intelligible's Summand platform, I loaded the raw inventory export, built a training view around days on lot as the target, and kicked off model training. When using Intelligible's glass-box modeling, the platform trains an Explainable Boosting Machine, or EBM, so that every prediction can be decomposed into individual, auditable feature contributions rather than a single opaque accuracy score.

The baseline across all inventory was about 89 days on lot. The EBM's job was to explain, in days above or below that baseline, exactly what each factor was contributing while holding everything else constant. That last part matters. A dealership's own average days by category dashboard can tell you trucks average more days than sedans, but it can't tell you whether that's because of the vehicle type itself, or because trucks also happen to be pricier, older, or concentrated at a slower store.

What the Model Revealed

New versus used is the single strongest factor. New vehicles push predicted aging 25.5 days above the baseline. Used vehicles pull it 64.4 days below. The used vehicle operation is turning efficiently. Almost all of the trapped capital is sitting in new inventory, a distinction a blended average days on lot figure completely erases.

Model year acts like a cliff, not a slope. 2025 model year units run 21 days below average. They're moving well. 2024 model year units jump to 53 to 57 days above average, and 2023 and older units are worse still, at 38 to 94 days. The jump isn't gradual, it's a cliff between current year and prior year stock, and that tells the dealer exactly where to draw the line for an aged unit blitz.

Lot price has a non-linear dead zone. Vehicles priced below $25K move quickly, 13 to 18 days faster than average. Vehicles priced above $65K also move fast, 18 to 43 days faster. Luxury buyers tend to know what they want. But the $35K to $50K band peaks at 44 days above average. That's the mid market no man's land where buyers cross shop endlessly. A simple average of price versus days on lot would show something close to flat and completely hide this dip in the middle.

None of this is inferred or approximated. It's read directly from the model's learned shape functions, with confidence intervals that widen where inventory is thin, so the dealer group knows where to trust the number and where to treat it as directional.

Where Dashboard Averages Get It Wrong

Say an inventory manager runs the standard report: average days on lot, grouped by store location. One store, the busiest, highest volume location, looks fine on paper. Another, smaller store shows elevated average days, and the obvious read is that the store just has a tougher inventory mix: too many trucks, too many EVs, too many high dollar units.

The model tells a different story. After the EBM controls for vehicle mix, pricing, model year, and everything else, one store still contributes 37.8 days to predicted aging, independent of what it's stocked with. That's not a product mix problem. It's something about that specific store: merchandising, photos, pricing authority, lot visibility, or staffing. Meanwhile the model's best performing store contributes 6.3 fewer days after the same controls, which makes it the internal benchmark to study rather than a store that just got lucky with easier inventory.

A store level average conflates what a store happens to be stocked with and how that store performs. Separating the two isn't something a GROUP BY can do on its own, because the inventory mix and the operational performance are tangled together in the raw number.

A Model You Build Once and Keep Asking Questions

Once the model is trained, it becomes a persistent, reusable layer the dealer group can query conversationally. Ask which vehicles are structurally slow, and get a ranked list of nameplates whose aging can't be explained by price or age alone: commercial trucks with no retail demand, EV models oversupplied relative to actual demand, sedans that structurally add days no matter their condition. Ask what's driving one store's aging, and get the isolated store effect, separate from its inventory mix. Ask what happens if you cut price by $3,000 on a specific unit, and get a direct read from the lot price shape function.

That's a real shift from filing a new report request every time a district manager has a new question. The model holds the full multivariate structure, vehicle, pricing, timing, and location, all interacting, in memory. The conversation just navigates it.

Building Agentic Workflows on a Grounded Layer

For a multi store dealer group, the trained model isn't just for a one time analysis. It becomes infrastructure. Incoming inventory can be scored automatically the moment it hits the lot, flagging units entering the $35K to $50K dead zone or arriving as prior model year stock before they've aged a single day. Ordering guides can be updated on a rolling basis to cap allocation of structurally slow moving trims. Store level performance can be monitored continuously for drift, instead of revisited once a quarter.

Because every prediction decomposes into additive, dollar and day feature contributions, the group's floorplan cost math inherits that same transparency. Instead of “this truck has been on the lot too long,” the system can say this unit is carrying $58K in annual floorplan cost, driven by 35 to 44 days of model specific aging, on a body style the group should stop ordering on spec. That specificity is what turned an inventory review into a prioritized, five action plan, and what let us put a real number on it: roughly $219,000 in annual floorplan cost tied to identified slow moving units.

Who This Is For

Dealer principals and GMs managing multiple stores and brands, who need to know whether a store's aging problem is a mix problem or a management problem before deciding where to step in.

Inventory and used car managers who are tired of reacting to whichever unit is oldest today, and want to know which factors are actually driving days on lot so they can fix the pipeline instead of just the symptom.

OEM allocation and ordering teams who want future orders informed by which model year, price band, and trim combinations actually turn, rather than by last year's order guide.

The common thread I keep seeing: anyone managing floorplan cost across more than one dimension, vehicle, price, timing, location, who needs to know which one is actually the problem, and needs an answer specific enough to act on this week.

Why This Matters

The store level example above isn't a one off. It's representative of a pattern I see in almost every dataset I look at: a blended average hides whether a number comes from the mix or from performance, and a raw price to days relationship hides the non linear dead zones where inventory actually gets stuck. In a dealer group, that ambiguity costs real money. In this case, a specific, defensible estimate of $219,000 in annual floorplan cost sitting in identifiable, actionable units.

A dealer group should not have to hire a data science team or stand up a BI pipeline to get this kind of clarity. Intelligible gives them a trained, inspectable model through a conversational experience that meets an inventory manager where they already are, asking which units to move first, and getting an answer grounded in what's actually driving the aging, down to the specific store, model, and price band.

Built with Intelligible. Data provided by a large regional auto dealer group in May 2026; names have been anonymized.

When an LLM reasons about a dataset, it starts from scratch. It writes code to explore the table, fits a quick model or computes correlations, interprets the output, and builds up an understanding of the data's structure, all within a single conversation. The next time someone asks a question about the same dataset, all of that scaffolding is gone. The model rebuilds it again, possibly differently.
This naive approach may be acceptable for straightforward questions. Compute a correlation matrix, find missing values, plot a distribution, etc. These are one-shot tasks where code is an acceptable answer. But there are harder analytical questions: which features interact, where a relationship changes direction, which column is structurally anomalous. These depend on understanding the data deeply and building up to an answer via intermediate steps. For these, rebuilding from scratch is unreliable, expensive, and often inadequate.
We evaluated this by presenting frontier LLMs with three analytical tasks under two conditions — with and without access to pre-computed structural knowledge — and measured how much that knowledge changed the accuracy of their answers.

Setup

We gave the model a dataset, a Python sandbox, and an unlimited tool call budget, then asked it an analytical question. Each task runs in two conditions:
Code-only: The model can write and execute Python against the dataset. To assist the model, we pre-loaded the dataset into a Pandas dataframe in the Python sandbox.
Code + semantic components: The model also has access to pre-computed components (e.g. column summary statistics, feature importances, shape functions, pairwise interactions and interaction rankings from an Explainable Boosting Machine trained on the dataset). These components are automatically generated using Intelligible's intelligible-ai package and exposed to the model as callable tools — for example, get_feature_importances or get_interaction_rankings — that the model can invoke alongside its Python sandbox during the conversation.

The only variable across these two settings is whether pre-computed structural knowledge is available.

Within each of these two settings, we evaluated Claude Opus 4.6 and Claude Sonnet 4.6 across four base tabular datasets [1, 2, 3, 4] at multiple row counts (100, 500, 1,000, and 10,000). To avoid contamination from LLM training data, we constructed evaluation tasks by injecting a synthetic phenomenon (e.g., corrupted rows or artificial interactions) into a dataset. This ensured that the ground-truth answer (i.e., recovery of the injected phenomenon) was known, unambiguous, and unseen during training. In total, this procedure yielded 48 candidate tasks, of which 10 were excluded because the injected phenomenon was not sufficiently strong (e.g., an injected pairwise interaction did not rank as the strongest in the dataset), leaving 38 tasks for evaluation.

Task 1: Data Quality Detection

Task: A Boolean flag column marks problematic rows. Identify it. All column names are random strings.
Why we care: In enterprise datasets, training on anomalous data silently degrades model performance. Identifying rules to exclude problematic rows is a routine but time-consuming part of data cleaning. Any AI system that is designed to deploy predictive models should first check for data quality.
Results:
Code-only accuracy (both models combined):
71%
With semantic components:
92%
Opus:
92%
100%
Sonnet:
50%
83%

For this task, we additionally obfuscate all column names with random strings. Frontier models have memorized popular tabular datasets. If you ask Claude about bike sharing data, it will recall column names and known quirks. Obfuscation ensures we’re measuring reasoning rather than recall.
In code-only mode, the model explores ~20 opaque columns looking for the one that flags bad rows. It has no structural prior, so it falls back on heuristics: checking for missing values, high correlations, distribution anomalies.
In contrast, when given Intelligible's semantic components, LLMs quickly identify the column that flags data quality problems. They do so by exploiting a nonobvious characteristic: data quality can be understood as an interaction effect, where a data quality indicator modulates the predictive relationship. In this task the indicator is a Boolean column in the dataset, so its two values produce clear differentials that surface as strong interaction effects.
Armed with semantic components, the LLM follows a streamlined procedure. Opus, for example, typically needs just 4–6 calls: retrieve feature importances, examine the shape function of the top binary column, and confirm the result with a Python check.

Task 2: Interaction Detection

Task: Which pair of features has the strongest interaction effect on the outcome?
Why we care: As the previous task showed, data quality problems can hide inside interaction effects. They're not the only thing hiding there—so do subgroup-specific risks, conditional treatment responses, and failure modes that only emerge when two conditions coincide. These patterns are invisible to linear methods, and they're exactly the patterns that drive costly surprises in production.
Results:
Code-only accuracy:
54%
With semantic components:
100%
Both Opus and Sonnet went:
54%
100%

Identifying interactions from scratch requires searching over all feature pairs, fitting interaction terms, computing H-statistics, or estimating SHAP values. These methods can find the right answer but also frequently disagree with the actual nonlinear interaction structure. Without a solid foundation to build on, LLMs identify the wrong pair on nearly half of instances, and different statistical methods produce different wrong answers.
With semantic components, every single instance is solved in a single tool call. The LLM retrieves pairwise interaction rankings, reads the top-ranked pair, and answers. No Python needed.

Task 3: Interaction Direction

Task: For the strongest interacting feature pair: when the first feature (sorted alphabetically) is above its median, does increasing the second feature increase or decrease the outcome?
Why we care: Knowing that two features interact is only half the picture. The direction determines whether the relationship is synergistic or antagonistic, and getting the direction wrong can invert a recommendation entirely.
Results:
Code-only accuracy:
73%
With semantic components:
100%
Opus:
77%
100%
Sonnet:
69%
100%

Comparing accuracies against Task 2 is misleading because this task is a binary question, so random guessing scores 50%.
This task is a two-step problem: first identify the pair, then determine the direction. Code-only LLMs mostly fail on step one because they try to avoid the difficulty. Instead of exerting effort and employing complicated statistical tools to find the correct interaction pair, code-only LLMs use linear regression interaction terms, which leads to incorrect rankings and hence incorrect answers.
With the semantic components, the harder subproblem (pair identification via retrieving interaction rankings) is precomputed and available as a tool call. Hence, the LLM focuses its Python code on what’s actually being asked: computing the conditional correlation. The typical pattern is 3 semantic calls (interaction rankings, dataset overview, interaction surface), followed by 2 Python calls (compute median, check direction). Five total calls, high accuracy.

The Full Picture

The pattern across these three tasks is consistent: when an analytical question depends on structural knowledge about the dataset, providing that knowledge as a pre-computed resource produces large accuracy gains.
On one hand, this is obvious—giving a model more information should make it better at reasoning. On the other hand, it's surprising. None of the structural knowledge in these experiments was external to the datasets. Every answer was self-contained, derivable through statistical analysis of the data itself. We gave the LLMs an unlimited budget for Python calls. We weren't measuring efficiency; we were measuring accuracy. And yet, LLMs with Python sandboxes regularly got the wrong answer. Pre-computed semantic components produced major gains on questions the models could, in principle, have answered on their own.
Reliable AI reasoning requires a foundation: persistent, precomputed knowledge about the data itself. This is what we're building at Intelligible. Our system extracts structural knowledge from enterprise data using interpretable models, persists it, and makes it available to LLMs and AI systems as an interactive semantic layer. The premise is straightforward: data meaning should be infrastructure, computed once and maintained, not regenerated from scratch on every query.
These three tasks are a starting point. We're working on a full benchmark and associated tooling for evaluating grounded enterprise reasoning. If you're building in this space, let’s talk.
Aaron Alvarez is a research intern at Intelligible, supervised by Rich Caruana and Ben Lengerich. Questions or comments: rich@intelligible.ai.

Stay in the loop.

Sign up to get product updates, early access opportunities, and new findings from the field.

Get product updates

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Text Link