Frequently asked questions for getting Spotter ready

Start with one to three. Choose Liveboards that represent your most common, most trusted query patterns — not your most complex ones. The goal is to give Spotter a clear signal about how your team actually uses the data, not to upload everything at once.

You can still set up Spotter without Liveboards. Write instructions and AI context manually to cover your core business definitions and constraints. Conversation learning is available from day one — users with Can manage Spotter privileges can correct Spotter mid-conversation and those corrections become shared memory.

Yes, as long as you have view access to it and the Liveboard is built on a data model (not a table or View). The memory generated from that Liveboard is scoped to the data model — it applies to anyone querying that Model, regardless of who added the Liveboard source.

Memory generation does not work on Liveboards built on tables or Views — only on data models. If your Liveboard has a mix of charts (some from a data model, some from a View), generation proceeds on the data model charts only. Charts built on Views are skipped without error.

You do not need to complete every data model readiness step before generating memory, but the quality of memory depends on the quality of the data model. A poorly named or underdocumented data model produces vague or incorrect rules.

Re-running AI context generation overwrites any manual edits you made to the AI context fields. If you have customized AI context manually, document what you changed before re-running, or do not re-run.

Use Spotter (agent-level) instructions for behavioral constraints that apply across all queries in that Spotter instance — output format requirements, personas, escalation rules, or org-wide policies.

Use instructions for hard constraints that must always be followed — they are prioritized over memory and applied strictly. Use instructions when the rule is non-negotiable and you want no ambiguity in enforcement.

Yes, they can conflict. Instructions win. Spotter prioritizes instructions over memory rules when they contradict each other.

Starting in 26.7, Spotter Memory has two distinct types:

Three problems memory solves:

Rules capture business definitions, constraints, and conventions that should apply consistently. Example: "Revenue always excludes returns."

No. Memory encodes what it finds in the Liveboard. If the underlying data model has ambiguous column names, inconsistent metric definitions, or missing relationships, memory will reflect that ambiguity — not correct it. Fix the data model first, then generate memory.

Spotter infers a significant amount from data model structure, column descriptions, and context. Before writing explicit memory rules, test whether Spotter already answers correctly without them. Avoid writing rules for behavior Spotter already demonstrates reliably — duplicate rules create noise and can introduce conflicts.

Near-duplicate reference questions (e.g., "revenue this month" and "revenue in current month") create ambiguity for Spotter at retrieval time. If you need to cover phrasing variations, write one canonical question and let Spotter’s semantic retrieval handle the variants. Review your reference questions periodically and consolidate duplicates.

No. Memory does not refresh when columns are renamed, metrics are redefined, or relationships change. Stale memory — rules that no longer match the data model — can silently degrade answer quality.

No. Admins navigate to cluster admin settings → AI settings and enable "Memory from Liveboards and conversations" under Spotter capabilities.

Users with Can manage Spotter, Manage Memory access, or data model edit access.

10–20 minutes depending on Liveboard size.

Data models only. Liveboards built on tables or Views return an error. For mixed Liveboards, generation proceeds on data model charts only.

Three methods:

Not currently.

Users with Can manage Spotter, Manage Memory access, data model edit access, or admin access. End users without these permissions cannot write shared data model memory.

Explicit intent:

No. Conversation learning writes memory at the data model layer — it does not update instructions, AI context, reference questions, or business terms.

Personal memory is context Spotter builds about an individual user — their role, goals, output preferences, and personal scope (accounts, region, team). It is separate from shared data model memory and applies only to that user’s sessions.

Any user, once the admin enables the "Enable personal memory learning for all users" flag. Can manage Spotter is not required.

Four categories:

Through conversation — the same mechanism as shared memory. Explicit statements like "Remember I’m Head of CS for EMEA focused on renewals" or "Always show me tables" trigger a save. Spotter confirms what was saved.

Applied quietly in every session — the user does not re-state their context. Explicit in-query instructions always override personal memory for that query.

Personal memory does not override shared data model Rules. If shared memory defines "revenue excludes returns" and a user has personal context that suggests otherwise, the data model definition takes precedence. Personal memory shapes context and preference, not data definitions.

Ask in conversation: "What do you know about me?" Spotter summarizes all saved personal memory for that user.

Both through conversation:

No. Admins cannot view the personal memories of individual users in this release. The memory download from the Memory Sources page covers shared memory only.

Open Spotter, click the Settings icon in the lower left corner, and toggle Personal memory off. Existing personal memories are preserved but not applied. Re-enabling the toggle makes them active again.

Separately from Reference Questions, Business Terms, and Instructions.

No. Memory persists — shared or personal — until explicitly deleted.

Claude Sonnet.