I talked to my mechanic the last time my car was in the shop. He described something that's a known, named problem in his world: a "comeback." A vehicle returns for a problem that should have been fixed the first time — and every service department tracks how often that happens, because it costs real money and it dings customer satisfaction scores.
His shop runs on repair databases — shared libraries of technician-submitted, verified fixes, searchable by symptom or trouble code. When a car comes in, the first move isn't always to diagnose from scratch. It's to check whether someone, somewhere, already solved this exact problem on this exact vehicle and had that fix confirmed. Most of the time, someone has.
But that doesn't always work... he noted that there are a lot of smart technicians in those databases. But not everyone contributes. It's a bit of a pain to type up those repair orders by hand, and whether the next technician benefited from it depended on whether that fix made it into the shared database at all. Similar processes are even more critical for IT Operations, because next-generation platforms like ServiceNow don't just log resolutions into a Knowledge Base; they proactively run playbooks that can resolve potential issues before a human even sees them.
This quarter, LEAP dramatically closes the gap between what operations teams see and the automations they apply: it's writing the fix down automatically, checking it against what's already confirmed, and tracking the comebacks that slip through when neither happens.
Worth noting up front: LEAP is getting a new expansion behind the acronym. What was "AIOps LEAP (Learning Enhanced Automation Playbook)" is now simply LEAP — Learning-Enhanced Automation Platform. Small change, but it reflects something real. LEAP has grown past being a single playbook mechanism into a platform that spans resolution, automation, and accountability for what didn't get automated.
Writing Down the Fix
A repair order isn't just a receipt — it's the record of what the vehicle came in for, what caused it, and what corrected it. That write-up is what makes a fix reusable later, either for a comeback or for the next tech who pulls the same VIN. Until now, once LEAP identified an automation opportunity, an operator still had to do that write-up by hand: turn a recognized pattern into a documented, usable set of resolution steps.
Automated Resolution Steps creation takes that off the operator's plate. When LEAP surfaces an automation opportunity, it generates the resolution steps directly from the incident pattern. The operator is reviewing a completed write-up, not drafting one from a blank field.
This is the equivalent of the repair order filling itself in the moment the diagnosis is confirmed — no lag between knowing the fix and having it documented.
Recognizing What You Already Have
A confirmed-fix database only works if two things happen: the fix gets checked against what's already there, and a real person signs off before it's trusted as verified. Neither step is optional. A shop with the database but no discipline for using it is really no better off than one without it.
The AI Agent for Ansible Playbook Integration runs that same check for incident resolution. It compares newly generated resolution steps against your existing Ansible playbooks, weighing step overlap, tool alignment, and historical execution data. Where it finds a match, it surfaces that playbook as the confirmed fix. Where there's no match, the resolution steps route into Workflow Studio to become a new one.
An operator reviews and links the playbook before anything executes, in either case — the equivalent of a master technician signing off before a submitted fix earns "confirmed" status.
This is the step that turns a one-off diagnosis into something the whole operation benefits from, not just the person who happened to solve it first.
Flagging the Ones That Keep Coming Back
Every service department already tracks comebacks, because it's one of the clearest signals of where quality is breaking down. A vehicle returning for the same unresolved issue means something in the process — the diagnosis, the write-up, the fix itself — didn't hold.
IT departments don't always track where they missed a chance to avoid fixing something twice, but we should. And now LEAP does, looking for incidents that recurred without any automation ever getting created for them — the ones that fell through, quarter after quarter, without anyone building the fix.
Comebacks cost a shop money and trust, whether or not anyone's counting them. The only difference automation tracking makes is whether you can see the pattern before it becomes a habit.
Where This Fits
A well-run shop doesn't rely on any one of these disciplines alone. The write-up gets the fix documented, the confirmed-fix check keeps techs from reinventing solved problems, and comeback tracking catches what falls through both. LEAP now runs the same three disciplines on incident resolution: document the fix, check it against what's already confirmed, and track what recurs without either happening.
That's what compound learning looks like in practice — three ordinary disciplines that get sharper every time an operator closes an incident.
Closing the Book — For Now
Getting back to my mechanic. Love that guy. The techs worth trusting are the ones working somewhere the confirmed fix is one search away, and where the comebacks keep getting shorter. People talk about "untrustworthy mechanics" as if they are somehow deficient in honesty. More than likely, they are just the victim of deficient processes.
That's the direction this release moves LEAP: fewer comebacks, and a fix that only has to be found once.
