The system said the unit was defective.
But “defective” had become a junk drawer. Damage during delivery went in there. Bad installation went in there. Missing or unclear instructions went in there. Actual manufacturer defects went in there too.
What caught my eye was the rate. We were coding far too many units as manufacturer defects. That is the kind of number that should make you suspicious, not because it is high, but because it is convenient. So I started pulling the actual returns and comparing the condition of the unit against the original delivery documentation.
The classifications did not hold up. Some units had been damaged in delivery. Some during installation. Some on the trip back. Different causes, different timelines, different people responsible. But the check-in team had one status to reach for, and they reached for it correctly, according to the process. “Defective.” The field was filled. The unit had a status. The handoff looked complete.
But the label had erased the cause.
That erasure had a price. We could not hold the 3PL accountable for return damage, because on paper there was no return damage, only defects. We could not tell a bad product from a bad install. And unless someone went back through the original delivery records by hand, we could not prove when the damage happened or who owned it. The claims were difficult or impossible to prove.
The work was documented. The truth wasn’t.
We fixed it by killing the shortcut. The team now had to identify the specific damage, photograph it, record measurements, and review the original delivery evidence before assigning responsibility. The label stopped being a place to hide the question and started carrying the answer. A defensible chain of evidence instead of a convenient category.
That change, folded into a larger redesign of how we handled claims and disposition, recovered a serious amount of inventory value. Not because we found new money. Because we stopped throwing away the evidence that let us claim the money we were already owed.
That experience changed how I think about completed work. A closed task is not the same thing as a resolved question. A filled field is not evidence that the right judgment was made.
Call it false coherence. Work that still looks right but has stopped touching reality. It is older than AI. Dashboards do it, the board stays green while the people behind it run on empty. Reviews do it, the meeting ends, everyone nods, nothing was decided. My junk-drawer field did it on a check-in floor with no AI anywhere near it.
But here is what keeps me up now. Point an AI at those records and it would learn, confidently, that all those units were defective. It would summarize the data perfectly. It would categorize new returns in milliseconds. And it would reproduce the exact mistake at scale, cleaner and faster and far harder to question.
The problem would not be hallucination. The problem would be faithful obedience to a category that had already erased reality. The model would not be wrong about the data. The data was already wrong, and the model would defend it beautifully.
That is the part people miss. AI does not just risk making things up. It makes broken systems fluent. It takes a shortcut a tired team invented on a busy floor and turns it into infrastructure. A rough draft tells you it is rough. A junk-drawer field, filled and closed and confident, tells you nothing is wrong.
So the question is not whether to use AI. It is where fluency is hiding the absence of contact.
The most dangerous operational failures do not look unfinished. They look complete.
I have always loathed to see QA staff closing tickets by doing the bare minimum possible (sometimes not resolving anything at all) in order to beef their "closed ticket" counts. So dysfunctional.