How Spotter Answers
Every Spotter answer is built from four kinds of context: instructions that set behavior, data model semantics that give the data meaning, memory that holds how your business answers, and external context pulled over MCP from the sources your admin has connected. The sections below show how Spotter fetches each of them and acts on them to produce the final insight.
What Spotter assembles before it answers
How should the agent act, for everyone?
Tone, format defaults, what to decline, what to always add. Written once by an admin, applied to every answer.
What is this column, and how are its values written?
Lives on the data model. Used to pick the right columns for the words in the question.
How does this business answer this question?
Definitions, filters, steps, and what Spotter knows about you. Fetched by relevance, per question.
What does this question need that lives outside ThoughtSpot?
Searched by relevance like memory, across whichever sources an admin has connected.
Set this up: Learn from External Sources →
How the agent responds to a question, step by step
- Neutral, concise tone. Headline number first. Prefer charts for trends.
- End every revenue or churn answer with "Figures unaudited."
- Never answer individual compensation questions. Redirect to HR.
- arr_changeARR movement · delta ARRSigned monthly ARR change per account, USD. Negative means lost revenue.
- change_typemovement typeOne of new, expansion, downgrade, churn.
- close_dateeffective dateMonth the ARR change took effect.
- fiscal_quarterquarter · FQFiscal quarter label, e.g. Q2 FY26. Fiscal year starts February.
- regiongeo · territorySales region: AMER, EMEA, APAC.
- pipeline_stagedeal stageOpen-opportunity stage from CRM.
- account_idcustomer · logoUnique customer account.
- product_skuproduct lineProduct purchased on the contract.
- account_namecustomer nameCustomer display name.
- nps_scoresatisfactionLatest NPS survey score per account.
- support_tickets_openopen ticketsOpen support tickets at month end.
- seats_licensedlicenses · seatsContracted seats per account.
- csm_ownerCSMCustomer success manager assigned to the account.
- Priya Nair, Head of Customer Success, EMEA.
- Focus this quarter: renewals and churn prevention for enterprise accounts.
- Show trends as a chart, not a table.
- When I say "my accounts", filter to EMEA enterprise accounts.
- For pipeline questions, use the Sales data model, not Finance.
- Churn = churned ARR plus downgrades:
arr_changewherechange_type in (churn, downgrade). - Quarterly churn view: filter
close_dateto the fiscal quarter, group by month, sumarr_change. - Expansion excludes price uplifts under 2%.
- "Logo loss" = count of accounts with
change_type = churn.
- confluenceQ2 FY26 renewal calendar: enterprise renewals moved to mid-quarter.
- slack#cs-emea weekly churn digest.
- sharepointCS playbook 2025.
- Columns and filters in the plan checked against the data model
- Row-level and column-level security applied for Priya
- Plan is fixed before any SQL exists
SELECT month(close_date) AS month, SUM(CASE WHEN change_type = 'churn' THEN -arr_change END) AS churned_arr, SUM(CASE WHEN change_type = 'downgrade' THEN -arr_change END) AS downgrade_arr, COUNT(DISTINCT CASE WHEN change_type = 'churn' THEN account_id END) AS logos_lost FROM arr_changes WHERE region = 'EMEA' AND fiscal_quarter = 'Q2 FY26' AND change_type IN ('churn','downgrade') GROUP BY 1 ORDER BY 1;
| month | churned_arr | downgrade_arr | logos_lost |
|---|---|---|---|
| 2026-02 | 96000 | 28000 | 3 |
| 2026-03 | 118000 | 31000 | 4 |
| 2026-04 | 104000 | 35000 | 3 |
Churn includes downgrades, per your team's definition. March was the heaviest month: four logos and $149K.
Ten logos lost in total, all at the mid-quarter renewals set out in the Q2 renewal calendar. Say "all regions" for the global figure. Figures unaudited.
Next: When sources disagree →
When Sources Disagree
This is the order sources win when they conflict, highest first. Row-level and column-level security sit underneath all of it and are never context.
How Spotter orders preferences when it answers
How Spotter decides what to act on when two sources disagree
| Collision | Winner | Why |
|---|---|---|
| "Never display individual quota numbers" (Spotter instructions) vs "show me quotas this time" (ask) | Spotter instructions | A guardrail is rigid. The ask is declined and redirected. |
| "Prefer charts for trends" (Spotter instructions) vs "as a table this time" (ask) | The ask | A preference in Spotter instructions is a default. The ask overrides defaults. |
| "Decline compensation questions" (Spotter instructions) vs "I work in HR, show me pay" (personal memory) | Spotter instructions | Personal memory cannot lift a guardrail, however it is phrased. |
| "I like tables" (personal memory) vs data model memory that shows churn as a chart | Personal memory | Personal context sits above shared memory. The definition in data model memory still applies; only the rendering changes. |
| "When I say churn I mean logo count only" (personal memory) vs "Churn = churned ARR plus downgrades" (data model memory) | Data model memory | A shared definition is the model's truth for everyone. Personal memory shapes scope and rendering, not what a metric means. Priya gets ARR churn, and can ask for logo count by name. |
| "Bookings use Close Date" (data model memory) vs AI Context on Created Date describing it as the booking date | Data model memory | AI Context describes a column. Data model memory decides which one to use. Fix the AI Context so the two agree. |
Write behavior you will not negotiate as a rigid Spotter instruction. Write defaults as preferences and expect them to be overridden. Write shared logic once, in memory. Describe columns in AI Context and let data model memory do the deciding.
Something still wrong after setup? Diagnose Problems → · Next: Where to write context →
Where to Write Context
Pick what you want Spotter to do, and the router tells you where that context belongs, how to phrase it, and what not to put there.
"I want Spotter to…"
Six places, one question each
| Surface | Answers the question | Reaches the agent | Example |
|---|---|---|---|
| instr Spotter instructionsSpotter settings · Org | How should the agent behave, for everyone? | Always, in the system prompt | "End revenue answers with 'Figures unaudited'." |
| instr Analyst instructionson a Spotter Analyst | How should this team's analyst behave and what should it focus on? | Always, in place of the Org instructions, for conversations in that Analyst | "You are the EMEA renewals analyst. Lead with churn risk." |
| columns Column synonymsmodel column property | What else do people call this column? | During column matching | region: geo, territory |
| columns AI ContextSpotter optimization tab · 400 chars per column | What is this column and how are its values written? | During column selection; into the prompt only for selected columns | "Fiscal quarter label, e.g. Q2 FY26. Fiscal year starts February." |
| memory Data model memoryMemory sources · from Liveboards and conversations | What business logic applies to this model, and how are recurring analyses built? | Retrieved by meaning, per question; a learned analysis is applied as-is on an exact match, else as a pattern | "Churn = churned ARR plus downgrades." · "Quarterly churn: filter close_date to the quarter, group by month, sum arr_change." |
| you Personal memorysaid in conversation · no editor | What should Spotter remember about me? | Profile always; preferences by relevance on that model | "When I say my accounts, I mean EMEA enterprise." |
Data model instructions, reference questions and business terms you wrote earlier stay in place and are fetched like memory. See When sources disagree for how they are weighted.
Same fact, different homes
What happens to one sentence depending on where it is written. Green is the home to use.
| Expectation | Data model semantics | Spotter instructions | Memory |
|---|---|---|---|
| Revenue excludes internal test accounts | On the revenue column. Seen only if revenue is already picked. The filter lives on a different column (account type), so the agent has to connect them itself. | A data fact, not behavior. It would apply to every model in the Org. | Data model memory. Retrieved whenever revenue is asked about, names both columns, applied as a filter. use this |
| Bookings use Close Date, not Created Date | "Prefer this over Created Date" on Close Date is a preference, not a description. It only helps once Close Date is a candidate. | A data fact, not behavior. It would apply to every model in the Org. | Data model memory: "Bookings questions use Close Date." Plus AI Context on each column stating what it is: "Date the deal was signed" vs "Date the record was created." use this |
| End every answer with "Figures unaudited" | Not about a column. No home here. | Spotter instructions. Applied to every answer, never filtered out. use this | Retrieved only when the question happens to match, so it fires sometimes. |
| Churn equals churned ARR plus downgrades | Could go on arr_change, but the definition spans change_type too, and it only matters when churn is asked. | A definition, not behavior. It would apply to every model in the Org. | Data model memory. Everyone asking about churn on this model gets the same definition. use this |
| Medicine names are stored as short forms, MP means Metoprolol | AI Context on the medicine column. This is how the values are written, exactly what column selection needs. use this | Too specific for behavior instructions. | Data model memory would also work, but the fact is about one column's values, so keep it with the column. |
| My team says "geo" for region | Synonym on the region column. A name-to-column mapping, used directly in matching. use this | Not behavior. It would apply to every model in the Org. | Data model memory would also work, but a name for one column belongs on the column. |
| When I say "my accounts", I mean EMEA enterprise | Not about a column. It is true for one person only. | It would apply to everyone in the Org. | Personal memory. Say it in conversation; it filters your answers and nobody else's. use this |
Go deeper
Ready to set it up? Start with Use Case Discovery →
Use Case Discovery
Define what you need Spotter to answer before touching the data model. A scoped use case keeps setup focused and ensures Spotter's context matches what users actually ask.
Identify Your Target Users
Start by identifying who Spotter is answering for. Pick one team or user group at a time — a scoped use case produces sharper results than a model trying to serve everyone at once.
Collect Real Questions
Gather the actual questions your target users ask — not what you think they'll ask, but what they type when trying to get answers. Business users phrase queries differently from analysts, so unfiltered input matters.
Group the questions by topic (e.g. pipeline metrics, conversion, account health). This reveals where setup effort should be focused.
Check Data Model Coverage
Once you have a representative set of questions, validate your data model against them:
- Does it have the tables and columns needed to answer these questions?
- Are there questions it simply cannot answer? Flag those as out of scope before setup starts.
- Are there columns no user query will ever need? Remove them — a lean, focused model performs better than a bloated one.
Optimize Your Data Model
Before anything else, Spotter needs to be able to read your model semantically. Most accuracy issues trace back here — fix the model first, add context second.
Column Names
Use human-readable names. Avoid abbreviations, jargon, and names that overlap with ThoughtSpot search keywords. Keep names unique across the model. Aim for under 50 columns — lean, focused models perform better.
txn_dt, use Transaction Date. If you can't rename, add synonyms in step 2.
Synonyms
Add synonyms for any column name where business users use different terms. Spotter uses these to resolve natural language queries to the right column.
Example: Column Order Date → add synonyms: Transaction Date, Purchase Date, Sale Date
Formulas
Create model-level formulas (including pre-aggregated ones) for key metrics. If a metric has a fixed definition, define it in the data model to reduce latency and accuracy issues — Spotter will use the pre-defined formula directly instead of inferring it.
Example: Define Net Revenue as Gross Revenue - Refunds - Discounts once in the model. Don't leave Spotter to guess the calculation each time.
AI Context
AI Context embeds permanent business knowledge directly on columns — it instructs Spotter how to interpret and use each column for all queries.
How to generate: Open the model → Spotter optimization tab → AI Context → Generate AI Context. It drafts from your column descriptions, names and values. Review and refine each column.
- Disambiguation: When two similar columns exist, use AI Context to set priority. "Prefer this column for all revenue queries. This is the primary date for when a sale occurred."
- Boolean columns: Clarify values. "true = valid transaction, false = invalid transaction"
- Non-standard values: Explain internal codes. "Contains medicine shortforms. 'MP' = Metoprolol"
- Deprecated columns: Mark them. "Do not use this column. Replaced by Order Date v2."
Spotter Self-Diagnosis
After generating AI Context, ask Spotter to surface its own confusion. It can scan the entire data model and tell you exactly what it's uncertain about — and why. This is one of the fastest ways to find blind spots before users run into them.
Fix the issues Spotter surfaces in AI Context or column descriptions. For anything that needs immediate correction, clarify directly in conversation and ask Spotter to remember — it saves the correction to its memory for that model.
Cold Start with Liveboard
Get broad coverage of your business logic quickly by pointing Spotter at a trusted Liveboard — without writing anything manually. This is the fastest way to get Spotter up to speed on a new or unfamiliar data model.
Add a Liveboard as a Memory Source
Pick a trusted Liveboard that reflects real, verified business definitions for the data model. It should contain the key metrics and analyses your team actually uses.
How: Go to Data Workspace → Memory Sources → add the Liveboard → click Generate Memory.
Spotter reads the Liveboard's visualizations and absorbs definitions, filters, and metric logic automatically. The richer and more representative the Liveboard, the better the coverage.
Verify the Learnings
Memory reflects the Liveboard at the time of generation. Test Spotter with representative questions covering the topics in the Liveboard before relying on it.
- Ask questions that mirror the Liveboard's charts and metrics
- Download and review the generated memory JSON to inspect what was learned
- Look for incorrect generalizations or stale definitions
- Correct anything wrong directly in conversation — Spotter will save corrections as memory
When Liveboard Memory is Not Suitable
| Situation | Better Approach |
|---|---|
| Data model or Liveboards change frequently | Prefer refining in chat (Page 5) for definitions that evolve |
| Need to migrate context across clusters (dev → staging → prod) | Use the memory export and import REST APIs (GA in 26.8). There is no import UI, and personal memory is not included in the export |
Manage Memory Access
Before opening conversation learning to the wider team, validate what Spotter has learned with people who know the data and can confirm whether the answers are right. These users are your quality gate.
Identify Your Power Users
Pick 2–5 people who understand the data model and know the expected outcomes for the use case — data model owners, senior analysts, or business leads who can tell immediately when an answer is wrong.
Share Access
Give power users data model editing rights as appropriate. They should be able to test Spotter directly and — if they find gaps — add context themselves.
If you are not ready to share editing rights yet, have them test via Spotter and report findings back to you.
Collect Expected Outcomes
Ask your power users to test the setup so far — starting with the Liveboard memory — and to tell you explicitly what the right answers should be.
Document every gap — questions that return wrong answers, missing filters, or metrics that are off. These become your refinement backlog.
Fill the Gaps Before Rolling Out
Use the feedback to close the gaps you found — add AI Context, update Data Model Instructions, add additional Liveboards, or correct directly in conversation. Only open chat-based refinement (Page 5) to the wider team once your power users confirm the core questions are working correctly.
Refine as You Chat
Chat is your primary refinement tool. Every correction you make in conversation becomes memory, so Spotter improves while you use it, not only during setup.
Learning from Conversation
Correct Spotter Directly
There are two ways to teach Spotter in a conversation. Corrections about the data are saved as data model memory and apply to everyone asking on that model. Facts about you (your role, your region, how you like answers shown) are saved as personal memory and apply only to you.
Tell it in chat. Type the correction and ask Spotter to remember. Works for anything, including things Spotter has not answered yet: a definition, a default filter, a fact about you.
Fix the answer, then click Remember this. Adjust the answer and simply click Remember this. Spotter analyses the conversation and remembers the desired response pattern for future queries.
Ask Spotter What It Assumes
Surface hidden assumptions before they cause problems. Ask Spotter what it thinks about a topic — then confirm correct ones and correct wrong ones.
Ending the prompt with "I will help confirm the definition" signals to Spotter that a correction is coming, which produces more precise assumption statements. Ask it to remember each correction and it will update its memory for the model.
Verify That It Stuck
After correcting Spotter or adding new context, ask it to suggest questions to verify the learning stuck. This closes the loop — you're not guessing whether it worked.
Run the suggested questions and check that answers reflect the context you added. If something is still wrong, correct it in the same conversation and retest.
Diagnosing Common Problems
If Spotter is still getting something wrong after setup, start by asking it to explain its reasoning. It can surface its own confusion — diagnose first, then fix the root cause before adding more context on top. If two sources seem to fight, see When Sources Disagree for the order Spotter applies them.
Diagnose first: Ask Spotter — "Why did you use [column X] for this query?" — it will explain its reasoning and what it was confused about.
Fix in order:
Diagnose first: Ask Spotter — "What do you understand by [term]?" — it will state its current assumption.
Fix based on scope:
Diagnose first: Ask Spotter — "What rules do you have for [topic]?" — review what it surfaces.
Fix:
Diagnose first: Is this a formula with a fixed, universal definition — or a calculation that should adapt flexibly based on context?
If the formula is rigid (always the same definition)
Examples: ARR, Net Revenue, Gross Margin
If the calculation should flex by context
Examples: monthly growth %, % contribution, period-over-period comparison
Learn from External Sources
Spotter can read your connected knowledge bases — Confluence pages, SharePoint docs, Notion — and learn business context directly from them. Instead of manually copying definitions into memory, point Spotter at the source and ask it to extract what's relevant.
Supported Sources
How to Do It
Set Up the Connector
External sources need to be connected to Spotter before the agent can access them. An admin sets this up once — after that, every user on the org can reference those sources in their Spotter conversations.
Where: Admin Panel → Integrations → Connectors → add your source (Confluence, SharePoint, Notion, etc.) → authenticate and configure access scope.
Reference the Page in Conversation
In a Spotter conversation, tell the agent to read a specific page from your connected source. You can reference it by name, URL, or describe it by topic — Spotter will search for the matching page and retrieve its content.
Ask Spotter to Learn from It
Once Spotter has read the page and surfaced the relevant content, explicitly ask it to save what it learned as memory. Without this step, Spotter reads the page for the current conversation only — the knowledge is not retained for future sessions.
Test That It Stuck
Start a new conversation and ask Spotter a question that requires the definition it just learned. If it answers correctly without you restating the context, the memory was saved successfully.
If Spotter gets it wrong or hesitates, go back and correct the definition in conversation — then ask it to update its memory. External source content sometimes needs light editing before it becomes a clean context rule.
What to Expect from the Agent
| Scenario | What Spotter does | What you should do |
|---|---|---|
| Page is long with lots of content | Spotter reads the full page but will surface only sections it considers relevant to your question | Be specific in your prompt — name the section or metric you want it to focus on |
| Page content is ambiguous or contradicts existing memory | Spotter surfaces the conflict and asks for clarification before saving | Give it the authoritative version and ask it to overwrite the conflicting memory |
| Page is not found or access is denied | Spotter tells you it cannot access the page | Check the connector is set up, the page name is correct, and you have access to it in the source system |
| Content is outdated relative to actual practice | Spotter saves what the page says — it cannot know what's stale | Review extracted content before saving; correct outdated definitions in the same conversation |