Use cases

One capability. Any table. Your domain brings the question.

Every case below carries the same five things: the human question, the engine’s reading of it, what happens when the signal isn’t there, the leakage trap that would have flattered a naive model, and a prompt you can paste straight into Claude, ChatGPT, or Cursor.

Where it lands hardestPRD §3.3
01 · collections & propensity-to-pay
02 · insurance renewal & claims triage
03 · lending & adverse-action
04 · B2B SaaS churn & expansion
05 · healthcare no-show & readmission

Ranked by where the differentiators are worth most — not by where the tooling is most crowded.

Front doors

The three we lead with.

The overlays are the segment entrances. One engine and one architecture already work this way.

Collections · propensity-to-pay

“Which accounts are most likely to pay if we work them?”

entity=account · outcome=paid · horizon=30d
If the signal isn’t there

Payment history too thin to separate will-pay from won’t-pay above the bar in this window.

The trap leak-guard catches

Leakage from payment_received_date or a settlement flag written after the fact.

Using the Hunter-Seeker MCP server, rank my accounts table by likelihood of
payment within 30 days. Outcome column: paid. Entity: account_id.
Return the top 25 with evidence, levers, and provenance.
Claims triage

“Which claims need a human referral?”

entity=claim · outcome=referred · horizon=none
If the signal isn’t there

Referral base rate too low, or claim features don’t separate referred from cleared above lift 1.5.

The trap leak-guard catches

adjuster_notes or a review-completed timestamp that only exists after the referral.

Using the Hunter-Seeker MCP server, rank my claims table by likelihood of
needing referral. Outcome column: referred. Entity: claim_id.
Return the top 20 with evidence and provenance.
Customer success · RevOps

“Which accounts are most likely to churn next quarter?”

entity=account · outcome=churned · horizon=90d
If the signal isn’t there

No stable pattern above lift 1.5 — usage data too sparse, or churn base rate too low for this window.

The trap leak-guard catches

Leakage from cancellation_date or downgrade_flag — leak-guard quarantines and names them.

Using the Hunter-Seeker MCP server, rank my accounts table by likelihood of
churn in the next 90 days. Outcome column: churned. Entity: account_id.
Return the top 20 with evidence, levers, and provenance.
Also shipping

Same engine, other tables.

Sales

“Which leads should sales call first?”

entity=lead · outcome=converted · horizon=30d
If the signal isn’t there

Conversion signal below the bar — too few converted examples in the training window.

The trap leak-guard catches

won_opportunity_id leakage — a column that only exists after the win.

Using the Hunter-Seeker MCP server, rank my leads table by likelihood of
converting within 30 days. Outcome column: converted. Entity: lead_id.
Return the top 25 with evidence and provenance.
Operations

“Which machines are likely to fail this month?”

entity=machine · outcome=failed · horizon=30d
If the signal isn’t there

Sensor history insufficient — not enough failure examples to validate above lift 1.5.

The trap leak-guard catches

maintenance_performed recorded after the failure — classic post-outcome leakage.

Using the Hunter-Seeker MCP server, rank my machines table by likelihood of
failure in the next 30 days. Outcome column: failed. Entity: machine_id.
Return the top 15 with evidence and what would move each out of the risk pattern.
Logistics

“Which shipments will be late?”

entity=shipment · outcome=late
If the signal isn’t there

Route and carrier features don’t separate late from on-time above the bar in this dataset.

The trap leak-guard catches

actual_delivery_time leakage — the answer hiding in the features.

Using the Hunter-Seeker MCP server, rank my shipments table by likelihood of
arriving late. Outcome column: late. Entity: shipment_id.
Return the top 30 with evidence and provenance.
Why teams switch

The complaints competitors collect — and what we do instead.

These come from reviews of the tools our buyers already own. Note that adoption, data quality, and trust — not model accuracy — cause most of the failures.

The complaintOur answerLands hardest in
“Reps won’t follow a score they can’t explain” — adoption cratersDriver groups, per-entity levers, and staged action with approvalCollections, claims, RevOps
“Couldn’t explain the prediction to the board”The engine owns every fact; the language model only rephrasesLending, insurance, collections
Leakage: models that looked excellent and failed in productionLeak-guard quarantine with plain-English reasons; out-of-time validation by defaultAny high-stakes ranking
“Health scores are consistently inaccurate”Calibrated scores, honest-empty below the bar, quota refundedCS/churn, collections
Pricing shock, months-long implementationSingle-purpose, fast to valueMid-market underserved by enterprise incumbents

Complaints we would not fix, and might worsen: narrow scope, no forecasting, no unstructured data, human-in-the-loop friction, and refusing to answer. If those are dealbreakers, we are the wrong tool and we would rather say so now.

Get started

Bring one outcome and one table. We’ll tell you if it holds.

Solutions · Hunter-Seeker