Skip to main content
Exemplar page — first pass, entirely proposal. No Invoca product ships this pattern today. Nothing below is code fact or measured behavior — it is a proposal offered for review. See Coverage, stated honestly.

What it is

A marketer types “show me calls about billing” into a search over call data. That phrase has at least three non-overlapping readings: calls attributed to the Billing campaign, calls tagged with a Billing Signal, or calls whose transcript summary happens to mention billing. Each reading returns a different set of calls. Guessing one and running with it means the marketer either gets a plausible-looking result that is quietly the wrong scope, or gets nothing and has no idea why. Disambiguate is the system stopping to ask which reading is right before it runs anything. The same job recurs inside Signal AI itself. A transcript contains a caller who says “I want to cancel” partway through a call about a billing dispute — cancel the service, cancel the pending charge, or cancel the callback that was just scheduled are all live readings, and Signal AI’s own intent extraction can land on any one of them. Disambiguate applies there too: when the extracted intent is genuinely split between readings that would produce different Signals, the pattern is to surface the split to a human reviewer rather than let one reading win silently. Disambiguate is not a general uncertainty indicator and not a way to soften a single guess. It exists only where there are two or more discrete, nameable candidate readings and picking the wrong one would send the user somewhere they didn’t intend to go — not where the system is simply unsure about one answer.

Choose this when / choose something else when

Agency tier

Suggests. Disambiguate proposes candidate readings; it never proceeds on any of them until the user picks one, and rejecting all of them (see Outcome states, Interrupted) costs nothing. This is the tier by construction, not by convention — the pattern’s entire job is to stop short of acting. This differs from Recommend, which is also Suggests-tier: Recommend proposes doing something new, and Disambiguate proposes a reading of something the user already asked for. Escalating either past Suggests — for example, having the system silently proceed on its best guess after a timeout — is a tier change that needs to be recorded, not a fallback that ships unremarked.

Anatomy

Each candidate row states the reading in the user’s words, not the underlying field name — “the Billing campaign,” not campaign_id = 4. Per TITAN-COLOR-01 and the vocabulary rules on the overview, no row is styled to look more “correct” than another with color alone; if one reading is more likely, say so in the row’s own text.

Outcome states

Disclosure & recourse

  1. Does the user know this is AI, at the moment it matters? Yes — the question only exists because a model-driven interpretation split; the identifier mark is on the question itself.
  2. What did it use? The request text, and — for Signal AI’s own intent case — the specific transcript segment that produced the split. State which, next to the question.
  3. How sure is it, and does that change behavior? The split itself is the confidence signal: there was no single reading confident enough to act on alone. If one candidate is markedly more likely, its row says so in words; likelihood is never conveyed by position or color alone.
  4. How does the user check it? Each row is specific enough to verify against what the user actually meant — “the Billing campaign” is checkable; “option 1” is not.
  5. How does the user correct it? Picking a different row corrects it immediately, before anything runs. The choice does not persist as a standing preference unless the product deliberately offers to remember it — see Gaps.
  6. How does the user get out? The escape route (see Anatomy) returns to free text with no reading applied. Dismissing the question entirely is equivalent to never having asked.

Reference

No model, prompt, tool schema, latency budget, or cost has been defined for this pattern.

Evaluation

Not evaluated. No eval set exists for this pattern, and none exists yet for Signal AI’s intent extraction either.

Content

Name the specific term that split, in the question itself — “billing,” not “your request.” A candidate row states the reading concretely enough that picking the wrong one on purpose would be obviously wrong. Follows Voice and tone: plain language, no apology for asking.

Accessibility

  • The question is announced via a polite live region when it replaces the loading state — announced once, on completion, not per candidate as the list renders.
  • An indeterminate wait before the candidates are ready needs a non-visual equivalent to a spinner: accessible status text, not only a visual animation.
  • If one reading is more likely than the others, that likelihood is stated in the row’s visible and accessible text — never conveyed by row order or color alone, per TITAN-COLOR-03.
  • Initial focus lands on the first candidate row, not on the escape control — the common path is picking a reading, not rephrasing.
  • Selecting a candidate and dismissing the question both need to visibly and programmatically remove the question from the page; a reader using a screen reader should not encounter a disambiguation question for a request that has already been resolved.

Constraints

Divergences

Not applicable — nothing is shipped yet to diverge from.

Gaps

  • Whether a user’s chosen reading should be remembered as a standing preference for future, similarly-worded requests is undecided.
  • How many candidate readings is “too many” (see TITAN-DISAMBIG-06) has no stated number — it is a judgment call pending a real product case to test it against.
  • Whether Signal AI’s own intent-disambiguation case surfaces to the call reviewer synchronously (blocking further analysis of that call) or asynchronously (queued for later review) is undecided.
  • Whether ranked candidates should ever be pre-selected (with an easy override) rather than presented as an unranked choice is undecided — pre-selection risks reintroducing the silent guess this pattern exists to avoid.

Volatility

This page’s guidance depends on the system being able to produce discrete, nameable candidate readings rather than a single fuzzy score — if intent extraction can only ever produce one ranked guess with no real alternative to name, this pattern doesn’t apply and Trust builders: Caveat is the right pattern instead. Dated 2026-09-02; revisit on the first real implementation of disambiguation in either a search surface or Signal AI’s intent extraction.

Why it works this way

Naming the readings is what makes the question answerable. A vague “did you mean this?” gives the user nothing to check against; a concrete “the Billing campaign, or calls tagged with the Billing Signal” lets them recognize their own intent in one of the options, the same mechanism destructive confirmation relies on when it names the specific object rather than asking “are you sure?” Blocking on discrete readings, rather than guessing and flagging the guess, is a deliberate trade of a small amount of friction against a failure mode that has no visible seam. A wrong guess that isn’t flagged looks identical to a right one until the user notices something is off — often much later, and by then the cost of the wrong reading has already compounded into a report or a decision built on it.
Last modified on September 3, 2026