LLMs.txt directory

Context Layer

The context layer is a shared knowledge system that sits between everything your organization knows and every answer a Spotter agent delivers. It collects, structures, and governs the institutional knowledge that makes the difference between a generic AI response and a precise, business-aware answer.

Spotter memory is part of the context layer. The context layer is the broader system that encompasses memory alongside learning, orchestration, lifecycle management, security, and governance. For details on working with Spotter memory, refer to Spotter memory.

Overview

A great data analyst doesn’t just know SQL. They know the data model, understand the business, remember how metrics are defined, know how the audience wants to see results, and personalize their work for each stakeholder. The context layer codifies that same knowledge and makes it available to the Spotter agent on every question.

The context layer works as a pipeline:

  1. Sources feed knowledge into the system.

  2. A learning system indexes, extracts, or distills context from each source.

  3. Context orchestration structures and files every piece of knowledge so it can be found, ranked, and maintained.

  4. The context layer store holds typed, scoped, and stamped knowledge.

  5. Lifecycle management keeps the layer current as sources change and usage patterns evolve.

  6. RAG (retrieval-augmented generation) fetches, ranks, and assembles the right context for each question.

  7. Security filters what reaches the agent based on user permissions.

  8. Governance provides transparency, audit trails, and human control.

Every answer the Spotter agent gives carries a receipt of exactly what context went in, so you can trace, audit, and refine the system over time.

Context layer and the semantic layer

The semantic layer and the context layer are separate systems.

The semantic layer defines your data model: tables, columns, joins, metrics, and aggregation rules. It lives in your data platform or in ThoughtSpot’s modeling layer, and you continue to maintain it there.

The context layer consumes the semantic layer as one of its inputs. Definitions from the semantic layer flow through the learning pipeline and are filed under the Data model understanding pillar alongside knowledge learned from other sources.

But the context layer is broader. It adds business logic, use case knowledge, reporting preferences, and per-user context on top of the data model. Where the semantic layer tells the Spotter agent what the data is, the context layer tells it how to think about it, who is asking, and how to present the answer.

What the context layer stores

The context layer organizes knowledge into five pillars. Each pillar represents a domain of expertise that a knowledgeable analyst brings to their work.

Data model understanding

Represents what a data engineer knows about the data: tables, columns, join paths, grain, aggregation rules, units, freshness, synonyms, and lineage.

Example: "Revenue" maps to amount_net on fct_orders, one row per order line, in USD.

Use case understanding

Represents what a domain expert knows about the business context: what the company does, what industry it operates in, and what purpose this particular agent serves.

Example: Mid-market SaaS company. This agent serves the renewals team.

Business logic and analysis

Represents what a senior analyst knows about reaching correct answers: metric definitions, analysis rules, defaults, exclusions, analysis workflows, and routing to knowledge sources.

Example: ARR excludes services. Pipeline questions should use the Sales data model.

Reporting preferences

Represents how a presenter would format the output: chart types, axes, colors, output format (table or narrative), length, tone, and follow-up actions.

Example: Use bar charts over pie charts. Two-line summary. Post to #revenue as a PDF.

User context

Represents what a personal assistant knows about each individual: role, region, locale, goals, personal preferences, and conversation history.

Example: Priya is the EMEA Customer Success lead. Assume EMEA region. She prefers tables.

Each pillar can hold context at the organization, group, or user scope. A metric definition can apply across the entire organization, a reporting preference can apply to a specific team, and a chart format preference can apply to an individual user.