Diagnose problems with Spotter
Spotter can tell you what it doesn’t understand about your data model — before your users find out. Diagnosis is a conversation: ask Spotter where it’s confused, fix what it flags, and re-run until the answers come back clean. Run this after optimizing your data model and generating AI context, and before adding memory or instructions.
The diagnostic loop
┌──────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ Ask a diagnostic │ → │ Spotter flags │ → │ Fix in the Model │
│ prompt │ │ gaps & confusion │ │ or in memory │
└──────────────────┘ └───────────────────┘ └───────────────────┘
↑ │
└────────────── re-run until clean ──────────────┘
Fixes land in one of two places.
Single-column issues — an unclear meaning, missing values context, a bad name — belong in the data model.
Cross-column guidance — which date column to use for an analysis, KPI hierarchy, business definitions — can go straight into memory from the conversation.
Step 1 — Diagnose the whole Model
Start broad. In a Spotter conversation on your data model, ask:
"Show me the data model columns you’re confused about and what specifically is causing the confusion."
Spotter returns ambiguous columns, conflicting signals between columns, and places where context is missing. This is your fix list.
Step 2 — Narrow the diagnosis
The whole-model prompt finds general gaps. To find the gaps that matter for your use cases, narrow the diagnosis to the analyses your users will actually run. Use the questions you collected during Usecase discovery.
| Diagnostic angle | Ask Spotter | What it surfaces |
|---|---|---|
A specific analysis area |
"What do you understand about pipeline analysis based on this data model? Which columns would you use, and where are you unsure?" |
Whether Spotter’s mental model of a topic matches yours — wrong column choices, missing measures |
Confusing columns |
"Which columns have names or descriptions you could interpret more than one way? List the possible interpretations." |
Ambiguous naming — for example, does |
Value overlaps |
"Which columns contain overlapping or similar values? Where could you pick the wrong column when filtering?" |
The same value living in two columns — for example, "Closed" in both |
Metric definitions |
"How would you calculate win rate from this Model? What definition are you assuming?" |
Assumed formulas that don’t match your business definition — fix rigid formulas in the Model itself |
Date ambiguity |
"If I ask for revenue by month, which date column do you use and why?" |
Multiple date columns competing for the same query |
Run the analysis-area prompt once per use case you identified in discovery — pipeline, forecasting, team performance, whatever your target team asked for.
Step 3 — Fix what Spotter flags
| Spotter can’t fix the data model itself. It diagnoses and drafts suggestions, but Model-level changes — AI context, names, synonyms, formulas — you apply yourself. What Spotter can apply directly is memory: correct it in the conversation and ask Spotter to remember. |
Route each flag to the right fix:
| What Spotter flags | Fix in | How |
|---|---|---|
Ambiguous column name or unclear meaning |
AI context (Model) |
Keep it scoped to that one column: what it represents, the kind of values it holds, when to use it. ~200 characters, written as instructions to the AI |
Which column to use for an analysis — competing date columns, KPIs, column hierarchy |
Memory (conversation) |
Correct it in the conversation and ask Spotter to remember — for example, tell it which date column wins for revenue queries |
Value overlap between columns |
AI context + Memory |
Both layers. First, AI context on each column stating clearly what it’s used for, so overlapping values don’t cause misreads. If column context alone isn’t enough, add memory definitions for how to perform each specific analysis — "For pipeline progression, use |
Business definition Spotter gets wrong |
Memory (conversation) |
Give the correct definition in the conversation |
Term your team uses that the Model doesn’t |
Synonym (Model) |
Add it on the column |
Wrong or assumed formula |
Formula (Model) |
Define it once in the data model |
The dividing line: AI context is a static description of one column — memory holds the conditions.
If the fix describes what one column means or how it’s modeled — "`Opportunity Close Date` is the closure date for any deal won or lost" — it’s AI context. (Don’t list sample values; Spotter already sees those.)
If it’s a business definition, or a rule that depends on conditions and can’t be pinned to a single column, write it in memory — "For open deals, forecast with Expected Close Date; once a deal is closed, report on Actual Close Date." A conditional rule like that doesn’t fit either column’s context without misleading the other analysis.
Writing the AI context fixes
We recommend you write AI context yourself, based on what the diagnosis surfaced. You know the business meaning, and the diagnosis tells you exactly what to clarify.
You can also have Spotter draft it for you — but resolve the confusion in the conversation first, then ask for the draft:
"The
Opportunity Close Dateis the closure date for any deal won or lost. TheBooked Contract Opp Dateis for opportunities we’ve booked — the legal date of signing the contract. Draft AI context for both columns."
Review the draft before saving it to the Model — it’s a starting point, not a final answer.
Step 4 — Re-run until clean
The Model is ready when:
✓ The whole-model prompt returns no significant confusion. ✓ Analysis-area prompts describe each use case the way your team would. ✓ Metric prompts return your definitions, not assumptions.
If you’re still correcting the same things after two or three passes, the issue is structural — go back to Optimize your data model rather than adding more context.
Related information