All posts

IQ Drafts. People Decide. What Actually Happens to a Warranty Claim.

Most software that promises to "automate" warranty claims is doing one of two things: routing them faster, or generating confident-sounding text about them. Neither is the hard part. The hard part is the judgment — is this covered, under whose standard, and what exactly should the sub be told to do.

IQ is the engine inside Cascade Connect that does that reading, drafting, and routing. It's the subject of our provisional patent filing, and it's the piece of this platform I get asked about most. So rather than adjectives, here's the actual path a claim takes — including the two places IQ deliberately stops.

What it reads: that home's warranty, and nothing else

Every determination starts from the warranty plan assigned to that specific home. Not a generic idea of what warranties usually say. Not the last builder's language, pasted in from habit.

This sounds like a detail until you manage more than one builder. Builder A's drywall crack tolerance is not builder Z's. The homeowner on the other end of the email is holding their builder's warranty booklet, and if your determination quotes a standard from somewhere else, you are wrong in writing — either giving away coverage that isn't owed or declining something that is.

So the grounding is strict, and it fails closed: no assigned plan, no determination. IQ would rather produce nothing than quote the wrong builder's provisions. Every draft it does produce cites the section it is actually deciding under.

What it drafts, and when

The when matters as much as the what: this happens on submission. Not when someone remembers to run a batch, not when a queue clears overnight. The homeowner hits submit, and by the time your team opens the request, every item on it already carries:

  • The coverage determination — covered or not covered, with the governing provision quoted by section.
  • The service order — a directive for the trade. Not "look at the window," but what to inspect, what to correct, and what "done" means.
  • The routing — the right subcontractor for that trade, pulled from the roster attached to that home.

All three render as a suggestion sitting under the item on the claim, not as a decision. Your team works down the request adjusting whatever needs adjusting — a different call, different wording, a different sub. Then one button in the request header accepts everything at once: suggestions applied, subs assigned, service orders generated, and one PDF per sub emailed with the claim photos embedded.

Read it, fix what's wrong, click once. That's the whole loop, and the click is the part that can't be automated away — by design.

The moment it refuses to rule

This is the part I'd point at if I could only show you one thing.

A homeowner writes: "My gutter is overflowing above the garage." That's a rulable claim — gutter overflow, clear standard, and an early version of the pipeline produced a clean, apply-able dispatch: inspect the gutters, clear any blockage, verify pitch. Good directive. Confident. Correct-sounding.

It's also, most of the time, leaves. The engine can rule on gutter overflow. What it cannot do is see inside the gutter — and nothing in the pipeline had noticed it was ruling on an assumption.

So IQ now answers a second question on every claim: is there one thing the homeowner could check that would change this call? When there is, the coverage call is not made yet. The status is held at Needs Info — even if the model tries to rule anyway, the pipeline clamps it — and IQ drafts a message that thanks the homeowner, names the issue, says it may well be covered but we need one more piece of information, asks for that one thing, and asks them to report back.

Notice what that message deliberately does not do: it doesn't cite provisions, and it doesn't name the likely cause. "This is usually just leaves" pre-judges the claim and reads to a homeowner like a decline dressed up as a question. It also runs under a safety guardrail that earns its keep immediately — the naive version of this asks a homeowner to climb a ladder.

The gate is simply did it name a check — not a confidence score. Self-reported confidence drifts between model versions and is weakly calibrated; "would a homeowner-checkable cause flip this?" is a crisp question with a real answer. A system that knows when it's guessing is worth more than one that's always sure.

When a homeowner pushes back

Declines get disputed. That's healthy — it's how a warranty program stays honest — but it used to be one of the most awkward parts of the job to write.

Now, the moment a homeowner submits a dispute, IQ drafts the reply in the background against that home's provisions. It lands in a suggestion box, not in the homeowner's feed. Your team sees "Suggested Dispute Response" with Apply and Dismiss; Apply is the only thing that writes the response, and Send is the only thing that publishes it. The homeowner never waits on the drafting, and never sees a word of it until a person has read it and sent it.

If the item has no assigned warranty plan, the draft doesn't happen at all — same fail-closed rule as everything else.

It learns your call, and the learning stays yours

When your team edits a determination, that edit isn't discarded. IQ treats it as precedent: the next similar claim reflects the way your company makes that call, not a generic default.

Two things about this matter more than the feature itself. First, it means the platform gets more like your team over time instead of the other way round. Second — and this is the part security reviewers ask about — that learning is stored privately to your company. Another company's corrections never shape your output, and yours never shape theirs. Same default-deny isolation as the rest of your data.

Asking IQ a question

The last piece is the search bar. Type a homeowner's name and you get instant homeowner results, the way search should work. But you can also ask an actual question — "which claims in Maple Ridge are past 30 days without a dispatch?" — and get an answer grounded in your real records, with links straight into the claims it's talking about. It never fires on a keystroke; asking is always an explicit act.

Every place a person says yes

Stack the gates up, because they're the whole design:

  • A draft is a draft — everything IQ writes lands as a suggestion attached to the item. It is never the record until someone accepts it.
  • Apply — one click can accept a whole request's worth of suggestions, but a person has to make that click, having read them.
  • Send — nothing reaches a homeowner or a subcontractor until someone clicks it. Applying a dispute reply doesn't publish it; sending does.
  • Needs Info — and when IQ isn't sure, it hands the question back rather than filling the silence with a ruling.

What I won't claim

IQ doesn't decide. It doesn't make your warranty program legally bulletproof, and anyone selling you that is selling you a liability. What it does is narrower and, I'd argue, more valuable: every determination is grounded in the correct provision and written in the same structure, every time.

Your exposure was never your best rep on a good day. It's the rushed hire covering a busy week, quoting a standard from memory, into a file that gets written casually for months and then read adversarially exactly once. Consistency is the thing that fixes that, and consistency is a machine's strong suit and a tired human's weak one.

IQ drafts. People decide. That's not a hedge in the marketing — it's how the pipeline is built, at every step.


IQ is the engine inside Cascade Connect, our warranty platform for builders and warranty management companies. Patent pending. See the platform and pricing, the security and data-isolation model, or everything else the platform runs.