Glossary
This page is the canonical definition of every term used across the docs. Articles link here whenever a term needs explanation. Read top to bottom for an overview of the product’s vocabulary, or use search and the right-hand table of contents to jump to a specific term.
Applies to: anyone using the docs
Detail level: Comprehensive
How this fits the docs site
The Glossary is the single source of truth for terminology. Every article in the docs that uses a defined term links here for the canonical meaning. Most terms belong to one of the two product stages (Define, Designer) or to the governance and Snowflake plumbing that supports them. The order of sections below mirrors that flow.
Product
Data Product Studio
The Snowflake Native App that designs governed data products from business domain and process knowledge. The product itself. After first mention in any article, refer to it as “the platform”; never use “the Studio” alone, which is ambiguous between the product and the parent company. See Install from Snowflake Marketplace.
Configuration page
The page inside the platform where custom domains and processes are added before being selected in the Define stage. See Add a custom domain on the Configuration page.
Snowflake Marketplace
The Snowflake distribution channel from which the Data Product Studio is installed into a customer’s Snowflake account. See Install from Snowflake Marketplace.
The product stages
The platform’s product flow runs through two stages, in order. Each stage has its own Overview article in the relevant section of this site.
Define
The first stage. The user picks a domain and process and provides context. The platform generates entity models and a process map. See Overview: the Define stage.
Designer
The second stage. The user opens the canvas, connects source tables, profiles them, maps source fields to model fields, adds expressions and lookups, then publishes and deploys to Snowflake. The output is the dimensional model that downstream metrics and semantic views are built on. See Overview: the Designer.
Domain
A business area such as maintenance, procurement, production, inventory, finance, HR, or safety. The first input the platform needs in the Define stage. Custom domains can be added on the Configuration page. See Choose a domain and process.
Process
A specific business workflow within a domain. For example, “Work order to completion” within the Maintenance domain. Selected after the domain is chosen. See Choose a domain and process.
Context
The use case, source system, and user roles a domain and process will support. Provided by the user before generation runs, and used by the platform to shape the entity model. See Provide context for entity generation.
Entity
A business object generated by the platform from domain and process knowledge. Examples: Work Order, Asset, Maintenance Schedule. Entities are reviewed and edited before being grouped into data products. See Generate entity models from a domain and process.
Entity model
The set of entities, their attributes, and the relationships between them, generated as a unit. The Define stage’s primary structural output. See Generate entity models from a domain and process.
Process map
A visual representation of the selected process, generated alongside the entity model. Shows the flow of activities and decisions inside the process. See Generate a process map.
Custom domain
A domain not on the built-in list, added on the Configuration page. Custom domains work the same way as built-in ones once configured. See Add a custom domain on the Configuration page.
Custom process
A process not on the built-in list within a domain, added on the Configuration page. See Add a custom process within a domain.
Visual designer
The Miro-like canvas where source data is profiled and mapped to business entities during the Connect stage. See Open the visual designer.
Source data
Data from an ERP or business system (SAP, Oracle, Pronto Xi) connected via the visual designer. The raw input that gets mapped to business entities. See Connect a source system.
Source system
The customer system holding source data: an ERP or another business system. One source system can expose many source tables. See Connect a source system.
Source table
A specific table inside a connected source system. The platform profiles source tables to support business naming. See Profile a source table.
Profiling
The platform’s analysis of a source table’s columns and values. The result helps the user choose accurate business names for Facts and Dimensions. See Profile a source table.
Mapping
The link between source data columns and a business entity’s attributes. Mappings are created in the visual designer and produce Facts and Dimensions on validation. See Map source data to business entities.
Business key
The field or fields that identify a record uniquely within a model. Business keys are set on the source-side mapping and form the relationships between models. A simple business key is one field (Employee Number for an Employee model). A composite business key is two or more fields (Purchase Order Number plus Line Number for a Purchase Order Line model).
Business naming
Naming Facts, Dimensions, and metrics in the language of the business process, not the source system’s column names. See Apply business naming to Facts and Dimensions.
Outputs
Data product
A grouped set of entities with shared governance, designed to support a defined business use case. The unit the platform produces and deploys. See Overview: the Designer.
Fact
A measurable output produced from source data, named in business terms. Examples: Work Order Cost, Maintenance Hours. See Apply business naming to Facts and Dimensions.
Dimension
A descriptive attribute used to group, filter, or contextualise Facts. Examples: Asset, Site, Time. See Apply business naming to Facts and Dimensions.
Dimensional model
The structured set of Facts and Dimensions for a data product, ready to support metrics. The platform produces a dimensional model from the mappings created in the Designer.
Metric
A defined calculation built from Facts and Dimensions. Generated per data product, then reviewed and edited before going into a semantic view. See Generate metrics for a data product.
Semantic view
A Snowflake object built from governed metrics. Queryable through Cortex Analyst, Cortex Agents, and standard Snowflake tools. See Build a semantic view from metrics.
Process tagging
Metadata that links every output (data product, dimensional model, metric, semantic view) back to the process it was generated from. The mechanism behind the golden thread. See Apply process tagging to outputs.
Provenance
The record of where a piece of data came from and how it was produced. In the Data Product Studio, provenance is captured automatically through process tagging and is what makes the golden thread auditable end to end.
Process knowledge
The business understanding of how a process runs, captured through the domain, process, and context selection in the Define stage. The input that lets the platform generate a meaningful entity model.
Golden thread
The end-to-end traceability from a process definition through to a final output (data product, metric, or semantic view). Achieved through process tagging and lineage.
Deployment
The act of pushing a finished data product, with its dimensional model, metrics, semantic view, and tags, into Snowflake as live objects. See Deploy a data product to Snowflake.
Governance
Governance
Access controls, validation rules, and lineage. In the Data Product Studio, governance is defined at the business level before source data is connected, not after. See Overview: governance in the studio.
Access control
The set of rules that determine which roles can read or write data inside a data product. Defined at the business concept level and enforced after deployment. See Manage roles and access.
Validation rule
A constraint defined at the business concept level (for example, “Work Order Cost must be non-negative”) that the platform enforces during deployment and ongoing data flow.
Lineage
The recorded path from source data through mappings, Facts, Dimensions, and metrics to the final outputs. Used for impact analysis and audit. See Audit a data product’s lineage.
Audit
The process of inspecting a data product’s lineage, governance, and deployment record. See Audit a data product’s lineage.
Deployment history
The list of past deployments of a data product, with timestamps, contents, and the user who triggered each one. See View deployment history.
Deployment events timeline
A timeline view of every event from a single deployment: validations run, objects created, errors raised, completion. See Read the deployment events timeline.
Role
A Snowflake role with specific access to the platform and its outputs. The platform uses roles such as UH_USER and UH_ADMIN. See Manage roles and access.
Feedback collection
The mechanism for capturing user feedback inside the platform. Feedback writes to a Snowflake table via stored procedure, and email links use native mailto anchors. See Collect and review user feedback.
Snowflake objects
Native App
The Snowflake deployment model the Data Product Studio uses. Runs inside the customer’s Snowflake account with no outbound network access. See Install from Snowflake Marketplace.
Streams and tasks
Snowflake’s native primitives for change-data-capture and scheduled work. The platform uses streams and tasks, deployed inside the Native App, to keep data products in sync with their source data after deployment.
Warehouse
A Snowflake compute resource. The platform runs its generation, profiling, and deployment work on warehouses sized for the workload. See Set up warehouses for the studio and Manage warehouses for the studio.
Cortex
Snowflake’s native AI feature set, including Cortex Analyst and Cortex Agents. Semantic views generated by the platform are queryable through Cortex.
Cortex Analyst
Snowflake’s natural-language query surface for semantic views. A semantic view built by the platform can be queried through Cortex Analyst without further configuration. See Query a semantic view with Cortex Analyst.
Cortex Agent
Snowflake’s agent framework. A semantic view can be exposed as a tool inside a Cortex Agent for multi-step reasoning over governed data. See Use a semantic view in a Cortex Agent.
YAML schema
The YAML structure that defines a semantic view at deployment time. Includes metric definitions, synonyms, verified queries, and custom instructions. See Understand the YAML structure of a semantic view and YAML schema for semantic views.
Synonyms
Alternative phrasings that map to a metric or dimension in a semantic view. Help Cortex Analyst answer questions phrased in different ways. See Add synonyms to a semantic view.
Verified queries
Pre-checked example queries embedded in a semantic view. Used by Cortex Analyst as known-good prompts to guide its answers. See Add verified queries to a semantic view.
Custom instructions
Free-text guidance attached to a semantic view that tells Cortex how to interpret ambiguous prompts or apply business rules. See Write custom instructions for a semantic view.
AI-assisted metric suggestion
The platform’s feature that proposes additional metrics for a data product based on the dimensional model and process context. The user reviews and accepts each suggestion before it joins the data product. See Use AI-assisted metric suggestion.
Reading concepts
Shared language
The agreed map of what business objects are, how they relate, and what they mean. The user-friendly term for what the industry calls an ontology. Used in non-technical articles and in any prose addressed to domain experts.
Ontology
The technical term for the shared language. Used in technical reference content (such as this page) and in articles addressed to data engineers. The two terms refer to the same thing; the choice between them depends on the audience.
ERP and business systems
The umbrella term for the customer’s source systems. ERP examples in any docs prose: SAP, Oracle, Pronto Xi. Avoid “legacy ERP” or “legacy systems”.
How to use this Glossary
For readers, this is a definition-by-definition reference. Search the page or use the right-hand table of contents to find a term.
For authors writing or editing articles in this repo:
- Add a new term to the Glossary before any article uses it. The Glossary is the single source of truth for terminology.
- Place the new term under the section that best matches its role: Product, The four stages, Outputs, Governance, Snowflake objects, or Reading concepts.
- Each term gets one canonical sentence. If genuine context is needed, add one short example or note. Keep entries to two sentences or fewer.
- Cross-link the term to the article in this docs site that introduces the concept in depth, where one exists. If no article exists yet, leave the link off and add it once the article ships.
- If the same concept has both a non-technical and a technical name (for example, shared language and ontology), give each its own entry and cross-reference them.
- When the meaning of a term changes, update the Glossary first. Then sweep the articles that use the term to confirm they still match.
FAQs
Why does the platform use “shared language” instead of “ontology”?
Shared language is the term most readers will recognise, so it is the default in non-technical articles. Ontology is correct in technical reference and in articles for data engineers. Both terms appear in this Glossary so readers can move between the two.
What is the difference between a Fact and a metric?
A Fact is a single business measurement coming out of source data, for example Work Order Cost. A metric is a defined calculation built on Facts and Dimensions, for example Average Work Order Cost by Site, year on year. One Fact can support many metrics.
Are Facts and Dimensions Snowflake objects?
No. Facts and Dimensions are business-level concepts the platform uses to organise the dimensional model. They become physical Snowflake objects only after deployment, and even then the user works with them through the platform’s business names rather than the underlying tables.
Related articles
- Sibling: Supported domains and processes
- Next step: Supported domains and processes
Search keywords
glossary; definitions; terminology; what does X mean; data product studio terms; entity definition; metric definition; semantic view; cortex; native app; visual designer; profiling; business naming; shared language; ontology; ERP and business systems; SAP; Oracle; Pronto Xi