Both Banners Say AI. Here Is How to Tell Them Apart.
Two booths at the same trade show. Both banners say AI. One took a weekend to build. The other took months and sits underneath everything the product does.
Nobody walking that aisle can tell them apart.
The word is the only part you can see
That is the real problem with AI in this industry right now, and it is worth being precise about what the problem is not. It is not that the tools do not work. Plenty of the narrow ones are genuinely good and built with care, and a well-made assistant that does one thing is worth more than a badly-made one that claims everything.
The problem is that a single word covers a chatbot added to a help page and a product somebody rebuilt from the inside, and the word is the only part the buyer can see from outside. Scope is invisible in marketing. It is very visible in a demo, if you know what to ask.
I sell one of these, so I will offer the questions I would want used on me.
Ask what the number counts
Everyone quotes a number of records. The number by itself tells you nothing, because nobody tells you what happened to it.
Raw volume is not an asset. It is inventory. What matters is whether anyone scoped it, cut it, structured it, tested it, found it wrong, and restructured it again. A dataset that started at a million and ended at ten thousand has had years of judgment applied to it. One that is still a million has had none, and the difference does not show up in the headline figure.
I know which side of that I am on, because the most useful thing I ever did to my own data was throw most of it away. Around twenty one thousand imported records, deleted, because of the way they had been recorded. They were not merely noisy. They were structurally misleading in a way that would have taught the engine the wrong lesson quietly, which is the worst kind of bad data, because nothing fails visibly. What is left is far smaller, and it is the reason the thing works.
While you are there, ask what the records are records of. A claim is a request. A determination is a conclusion and the reason behind it. Those are not the same unit and they do not do the same work, and a large pile of the first one is not a small pile of the second.
Ask where the time goes
Every AI pitch in this category ends at the same promise, because less time is more margin. So make the vendor walk the actual work with you.
In every warranty platform I have used or demoed, the shape is identical. Claims come in. A person reads each one and decides whether it is covered. Some need the governing provision checked. Then the description gets rewritten, either as a decline explanation for the homeowner or as service order prose for the trade. Then subs get assigned, service orders get created, messages get drafted, and everything gets sent.
Ask which of those steps the software removes, and which it only relocates. Most automation relocates work and gets marketed as removing it.
For our engine the answer is that the work is finished before anyone opens the claim. IQ runs at submission rather than on demand, so by the time a coordinator opens the file the determination is drafted, the service order is written, and the sub is assigned. The work is not queued up waiting for someone to press start. It is done, and what is left is the decision.
Then one button sends every service order at once. Twenty claims, one click. I know exactly how that sounds, and it is literally true.
What makes it true rather than a slogan is the part nobody puts on a banner: the click lands after a person has read the drafts, confirmed the calls, and checked the assignments. Not instead of it. That review is real work and it takes real time. It is a fraction of writing all of it from nothing, and it is the step that should never be automated away.
The same decision, made three times
Foundational is a word vendors use about themselves, so it is worth showing rather than claiming. Here is the same design decision in three different parts of our platform. In each one the machine does the work up front, a person stays at the point where the work becomes consequential, and the result is something you can check rather than something you have to trust.
A claim that drafts itself before anyone opens it
When IQ drafts a determination, it reads the warranty plan assigned to that specific home and quotes the governing provision by section. If no plan is assigned to the home, it produces nothing at all rather than reasoning from a general sense of what warranties usually say.
The citation is the checkable artifact. A determination that names its provision can be verified in fifteen seconds by someone who knows the plan. One that does not is a confident paragraph you have to take on faith, and a confident wrong answer reads exactly like a confident right one.
A phone call that becomes a claim
Homeowners call. They have always called, and a portal does not stop them calling.
Our intake assistant answers, takes the issue in conversation, and matches the caller to a home. The first signal is carrier caller ID, compared against the phone numbers on the homeowner record, including the second buyer and the alternate number. When the phone does not resolve, it falls back to a fuzzy match on the property address, with the name the caller gave used only to break ties between records the address already reached. A name never admits a homeowner the address did not.
On a match, a warranty request is created from the call. Not a note, not a task for somebody to retype in the morning. The request is built the same way the homeowner portal builds one, with the same parent record, the same line items, and the same per-homeowner numbering, so a request created from a phone call is indistinguishable from one the homeowner typed themselves.
The restraints are the interesting part. Only warranty-shaped calls create anything, so a question about a closing date does not open a claim. A duplicate guard suppresses a second request for the same homeowner inside twenty four hours, because retries happen and frustrated people call twice. And when the caller cannot be matched to a home, nothing is created. The call goes to a person, because a claim attached to the wrong house is worse than a claim nobody filed.
A question about the data that answers itself
You can ask the platform a question in English. How many open claims does this development have, what is the average cycle time for that trade, which homes in this community have had drywall work twice.
The part worth asking about is what happens underneath, and our answer is specific: the model never writes SQL. It emits a query specification against a fixed schema, which is validated and then executed by a query engine we wrote by hand. It can supply filter values. It cannot invent a query shape, and it cannot name a builder group, because the tenant scope is resolved from your signed-in session and applied to every statement regardless of what the model asked for. Isolation is not something the model is trusted to respect. It is something the model is structurally unable to reach past.
Here is a boring, specific answer of the kind I said to go looking for. We pin the model's reasoning effort higher than the cheap setting, and there is a comment in the file telling the next person not to optimize it away. At the lower setting, on two-step questions like "average days for this sub," it silently dropped the filter it had just resolved and reported the group-wide average as though it were that sub's number. Same latency, wrong answer, delivered with total confidence and no error anywhere.
That is the kind of failure you only find by checking outputs against known values on real data, and it is the kind of thing that separates six months of work from a weekend. Nobody would ever encounter it in a demo.
What the three have in common
None of those are chat features. In all three the intelligence sits under the workflow rather than on top of it, and in all three the shape is the same: do the work early, put a person at the moment it becomes consequential, and leave behind something checkable. A cited provision. A request identical to one a homeowner would have filed. A query the model could not have pointed at someone else's data.
That is what foundational actually means in practice, and it is why it takes months. Not because the model is hard to call. Calling a model is easy, which is exactly why a weekend version exists and can put the same word on its banner.
What I am not claiming
I am not going to give you a percentage.
I could. Every vendor in this category quotes one, and nobody publishes a methodology behind it. What I can tell you is what the software does, at which step, with what left over for a person, and every one of those claims is something you can make me demonstrate on real claims rather than a slide. When I have measured the labor honestly, against our own eighteen years of warranty operations, I will publish the number and the method together. Until then the absence of one is the honest position, and you should hold every other vendor to the same standard, including the ones whose figures are larger than mine would be.
I am also not claiming the engine is always right. It is not, and any vendor who tells you otherwise is selling you something that does not exist. What it is, consistently, is grounded in the specific provision it cites and structured the same way every time, which means when it is wrong, it is wrong somewhere you can see.
You do not need to understand the technology to run any of this. You only need the vendor to show their work. The ones who built something will give you boring, specific answers. The ones who did not will answer with adjectives.
IQ is the engine inside Cascade Connect, our warranty platform for builders and warranty management companies. Patent pending. See why verification is the whole argument, how the claims engine actually works, the platform and pricing, or the security and data-isolation model.