Solid Frequently Asked Questions

Product & Architecture

What problem does Solid solve?

Enterprise data contains far more than tables and columns. To answer business questions correctly, AI needs to understand which data is relevant, how tables relate, how metrics are calculated, what business terminology means, and which existing SQL patterns represent trusted logic.

Solid turns the knowledge already present across the data environment into governed semantic models that AI applications can use. This enables organizations to scale use cases such as conversational analytics, AI-assisted analysis, and autonomous agents — without rebuilding the required data context separately for every application.

What is a semantic model in Solid?

A semantic model is a use-case-specific representation of the data and business logic needed to answer a set of related questions.

A typical model includes approximately 5–10 tables and 50–100 relevant columns, along with relationships, metrics, descriptions, business terminology, trusted SQL examples, benchmark questions, and model-specific instructions.

Models are intentionally scoped around business use cases rather than attempting to expose an entire enterprise data warehouse to an AI model at once.

How is Solid different from a traditional semantic layer?

Solid focuses on the full lifecycle of enterprise semantics, not simply providing a place to define them.

Solid automatically discovers existing knowledge from warehouse metadata, query history, BI assets, documentation, and other sources; uses that knowledge to draft semantic models; continuously tests those models against real business questions; monitors changes in the underlying environment; and proposes updates as the data and its usage evolve.

Organizations can therefore manage semantics as an ongoing, governed engineering process rather than a one-time modeling exercise.

How does Solid work with semantic capabilities already in platforms like Snowflake, Databricks, or Microsoft Fabric?

Solid is designed to complement the existing data stack. Organizations can use Solid as the semantic and governance layer directly through MCP, or publish semantic artifacts into supported downstream platforms and formats. This allows teams to benefit from automated model generation, testing, and maintenance while continuing to use their preferred warehouse, BI, and AI technologies.

Is Solid a data catalog?

Solid complements data catalogs rather than replacing them. Catalog information can be one of the inputs Solid uses to understand the enterprise environment. Solid's primary purpose is to operationalize that knowledge for AI — turning it into tested, use-case-specific semantic models that can reliably guide SQL generation and agent behavior.

Does Solid replace our AI agent or conversational analytics platform?

No. Solid is designed to work with whichever AI experience the organization chooses. Solid also offers its own conversational analytics chat and agent module. An agent, application, or conversational interface can call Solid through MCP to understand the relevant business concepts and generate validated SQL. The organization can continue using its preferred agent framework, user experience, and LLM.

Data Access, Privacy & Security

What information does Solid need from our data environment?

The primary inputs are warehouse schema and metadata, and query history. Additional context can improve the resulting models — including non-PII data samples, BI reports and dashboards, business documentation, existing catalog information, metric definitions, and other approved semantic context.

Organizations control which systems, databases, schemas, and contextual sources are made available to Solid.

Does Solid ingest our entire production dataset?

No. Solid does not copy the underlying production dataset into its platform. It primarily learns from metadata, query patterns, business context, and the structure and usage of the data. Where configured, limited non-PII samples may be used to better understand the meaning of particular fields. Production data remains in the organization's data platform.

Is raw production data sent to an LLM?

No. Solid's LLM-based reasoning works on metadata, semantic context, business definitions, and relevant patterns — not production row-level data. This separation allows Solid to build rich business understanding while preserving the organization's existing data-security boundaries.

When a user asks a question, does the result data pass through Solid?

The normal runtime pattern keeps the data path between the AI application and the organization's warehouse. Solid provides the validated SQL and supporting context. The calling application executes that SQL using the appropriate warehouse credentials and receives the result directly from the warehouse — so existing warehouse controls remain the source of truth for access to the underlying data.

How are row-level, column-level, and user permissions enforced?

Permissions continue to be enforced by the underlying data platform. The application or user runs the generated SQL using its own authorized credentials. Solid does not grant additional access to tables, rows, or columns that the caller is not otherwise permitted to use.

Can Solid generate write operations against our warehouse?

No. Solid's SQL generation is restricted to SELECT operations, enforced through deterministic static validation — not by relying on an LLM to enforce this restriction.

What deployment options are available?

Solid supports three deployment patterns:

• Solid-managed SaaS — the platform is operated by Solid
• Private Cloud — Solid is deployed inside the customer's own cloud environment (AWS and Azure supported)
• Hybrid — Solid's control plane is managed centrally while the data-sensitive components remain within the customer's environment

The appropriate architecture can be selected based on security, networking, regulatory, and data-residency requirements. See Deployment Models for more detail.

What enterprise security capabilities does Solid support?

Solid supports SAML 2.0 and OAuth 2.0 integrations, encryption in transit and at rest, security monitoring, vulnerability management, and regular penetration testing. Solid maintains SOC 2 Type II compliance and is actively pursuing ISO 27001. See Security Architecture and Identity and Access Management for full detail.

Building & Governing Semantic Models

How does Solid create a semantic model?

Solid first builds an understanding of the organization's business and data environment using signals such as warehouse schemas, query history, BI definitions, documentation, metrics, and existing semantic information.

A modeler then defines the business purpose and representative questions for a use case. Solid uses the available evidence to propose the relevant tables, columns, relationships, metrics, SQL patterns, business context, and benchmark questions.

The resulting model is reviewed and refined by a human before it is certified for production use.

Do we need perfect documentation or a mature data catalog before using Solid?

No. Solid is designed to derive substantial context from systems that already exist — particularly schema information, query history, and BI usage. Existing documentation, catalogs, glossaries, and metric definitions can further improve the models, but organizations do not need to complete a large documentation project before getting started.

Can Solid use semantic work we've already done?

Yes. Existing business definitions, metrics, SQL, BI logic, catalog information, and documentation can be incorporated rather than recreated. Repository-based assets such as YAML, dbt definitions, and approved documentation can also contribute to the semantic context. The objective is to build on the organization's existing knowledge and create a consistent operating layer around it.

How much human involvement is required?

Solid automates much of the discovery, model drafting, testing, and ongoing maintenance work — while keeping people in control of production semantics. Modelers can inspect and edit tables, columns, relationships, metrics, SQL examples, glossary definitions, instructions, and benchmarks. Models move through a governed lifecycle before being certified. Only certified models are made available for production MCP use.

Does Solid automatically change certified business logic?

No. Solid can identify changes and recommend updates, but changes to governed semantic models require human action. This gives organizations the benefit of continuous automated monitoring without removing ownership from data and business teams.

Accuracy & Reliability

How does Solid measure accuracy?

Each semantic model has a benchmark made up of representative business questions and trusted ground-truth SQL. During a benchmark run, Solid generates SQL for each question and evaluates it against the expected result, with result-set equivalence serving as the primary measure. This provides a repeatable way to measure model quality rather than relying on subjective spot checks. Benchmark sets can be automatically expanded over time as new business questions and edge cases emerge, ensuring models are completely tested.

See Benchmarking for more detail.

What accuracy should we expect?

Accuracy is measured for each customer's own use cases and benchmark set rather than through one universal number. Solid recommends a minimum benchmark score of 85% for automated production use, with models typically improving through refinement, additional context, and Solid's automated correction workflow. Teams can establish an explicit quality threshold for each model before making it available to applications and agents.

How does Solid reduce AI hallucinations when generating SQL?

Solid constrains generation to governed context rather than asking an LLM to reason freely over an entire warehouse. The model provides the relevant tables and columns, approved relationships, metric definitions, business terminology, trusted SQL patterns, and custom instructions. Generated SQL is then subjected to validation and correction workflows before being returned. This substantially narrows the space in which the AI needs to reason and makes its behavior testable.

Can we understand why Solid generated a particular query?

Yes. Solid can expose the semantic model selected, how business terminology was interpreted, which relationships and filters were used, and the rationale behind the resulting query. This gives developers and modelers a way to inspect and debug behavior rather than treating semantic reasoning as an opaque black box.

Maintenance & Scale

What happens when our warehouse or business logic changes?

Solid continuously monitors signals that can affect semantic model quality. Its Auto-Maintain workflows identify warehouse changes, benchmark regressions, and patterns in production usage that indicate missing or outdated context. Solid then proposes specific model updates for review. This makes the semantic layer an actively maintained system rather than a static configuration.

See Auto-Maintain for more detail.

What happens when a business question spans multiple semantic models?

Solid can route a question to the most appropriate model and, when needed, combine up to two complementary semantic models within a single generation request. For broader questions spanning several independent business domains, the AI application can decompose the task into multiple calls and combine the results at the agent layer. This keeps individual models focused while still supporting sophisticated cross-domain analysis.

Can Solid work across multiple data warehouses?

Yes. Solid can provide a common semantic operating layer across supported data platforms. For questions that require data from different warehouses, the agent can make separate calls to the relevant sources and combine the resulting information. Solid does not require organizations to consolidate all enterprise data into a single warehouse first.

Which data platforms does Solid support?

• Snowflake
• Databricks
• Oracle
• SQL Server
• Teradata
• Db2
• Amazon Redshift
• Google BigQuery
• Microsoft Fabric / Synapse
• Starburst

Solid is also expanding its list of out-of-the-box connections and is happy to explore custom integrations. See Connect Your Data for setup guides.

Integration & Ownership

How do AI agents connect to Solid?

Solid exposes its semantic capabilities through MCP, allowing MCP-compatible AI applications and agents to discover business context and obtain validated SQL. Teams can build their AI experience independently while using Solid as the governed semantic foundation underneath it. See Getting Started with the Solid MCP Server for setup.

Can our semantic models be used outside of Solid?

Yes. Depending on the target system, models can be consumed through MCP or published in supported formats including Snowflake Semantic Views, dbt YAML, Tableau .tds, LookML, and Solid YAML. See Export and Publishing Surfaces for the full list.

Who owns the semantic models created in Solid?

The customer does, with Solid supporting the initial implementation. The business definitions, semantic models, and generated semantic artifacts created from the customer's environment remain the customer's assets and can be exported into supported downstream systems.

How should an enterprise get started?

The recommended approach is to begin with a well-defined, high-value business domain or use case rather than attempting to model an entire enterprise environment at once.

Typical sequence:

1. Scope the initial business questions and data domain
2. Connect the relevant data and contextual sources
3. Allow Solid to discover and organize the existing semantic knowledge
4. Generate and refine the first semantic models
5. Establish benchmark questions and validate accuracy
6. Certify the models
7. Connect them to the target AI or analytics experience
8. Expand to additional domains using the same governed framework

This creates a repeatable path from an initial use case to an enterprise-wide semantic foundation.