Meet Cason
AI engineer + VMRS specialist
Cason Shepard builds AI for repair and maintenance. He’s also the person who’ll happily spend an afternoon digging into VMRS codes, repair workflows, and out-of-service issues. For him, knowing those details is how you build tools fleet and service teams can actually rely on.
Most AI engineers never go anywhere near VMRS. What made you want to learn it?
VMRS is such an underutilized yet powerful organizational system.
VMRS can encode data at every level of specificity: what system of the vehicle was worked on, what repair actions were performed, all the way down to a single component like the left lug nut on the rear left tire. As someone who has always enjoyed intuitive systems, graph theory, and mnemonic devices alike (PEMDAS!!), VMRS is the perfect intellectual playground.
In a perfect world, the benefits of VMRS utilization are obvious: fleets can track maintenance spend and actions across labor categories, component types, and vehicle systems, at whatever degree of granularity you need. Everyone wants these kinds of insights, but fully utilizing a taxonomy this rich requires real depth of knowledge and sheer hours of rote memorization, not to mention the time it takes to actually encode the data. A gap like this is one perfect for AI intervention, as it has three key attributes. First, VMRS is a well defined taxonomy, meaning clear rules and decision boundaries that are perfect for building and evaluating against. Second, the breadth of coverage VMRS provides means lots and lots and lots of data, the perfect medium to shape an AI system. Finally, complete VMRS utilization requires a constant upkeep that no human can realistically keep up with, a perfect use case for AI. As an AI engineer, these aspects of VMRS make it such an incredibly exciting problem to solve and build solutions around!
What’s something AI gets wrong about maintenance data when the person building it doesn’t understand the specifics?
A problem we’ve seen a lot is that fleets and shops run their organizations in specific, specialized ways. Many fleets have unique internal ID systems for tracking their vehicles, or run separate internal and external work order systems to accommodate certain workflows. The difficulty is that there is no one-size-fits-all AI system that can understand and adjust to an ever-changing trucking scene. One of the qualities I enjoy about the team’s approach at Axle is that we work closely with specific pain points of shop owners to understand where automation can have the most impact. You can’t just use AI to “read an invoice” without first understanding why you’re reading it. Are we catching overbilling? Are we looking to log service dates for record keeping? How do certain providers bill differently? These goals shape how AI systems should be built, not just how they are interacted with. We lose the plot when AI products try to build the future without first understanding where we are currently at.
Another example of this is the discussion around predictive maintenance. It would certainly be wonderful if we could predict when a vehicle will break down and which fault codes may appear soon, but at the end of the day this is just a glorified guess that doesn’t solve the root issue: faulty preventative maintenance schedule tracking. Fleet managers know this. When a truck misses its maintenance schedules it’s much more likely to break down and cause problems; they don’t need fancy ML models to tell them. This is why I’m really enjoying building AI native workflows that work alongside a fleet manager’s extensive working knowledge rather than building systems attempting to replace them.
When you’re building AI for fleets and shops, how do you think about the technician or fleet manager or service writer on the other end of it?
I think this answer goes hand in hand with the second question! It’s important, as in any industry, to build with humans in mind. In any job there are a ton of small things we all have to do to keep the lights on, whether it’s filling out a form or sending a quick update on work progress. Fleet managers and service writers do plenty of this already, and they also oversee work that requires real care and thought when it comes to their fleet’s operational health or a vehicle’s safety on the road. I see it as our job to build systems that not only harness AI but also harness the experience and expertise that a user of our system already possesses. To do so, it’s really important to know how those experts work in their day-to-day! Only once we understand the problems can we find an optimal placement for AI in their workflows, rather than lazy rip-n-replace AI applications that we see too often these days.