Your AI shouldn't have to guess what your data means.
Knowi's semantic layer turns raw columns into governed business terms, before an agent ever answers. Define revenue once. Every dashboard, query, and agent uses that definition.
Live SQL, NoSQL, and API sources. No warehouse required first.
Your AI answers questions wrong confidently. Semantic layer helps with this.
Revenue means three things to three different people.
Finance counts what was booked. Sales counts what closed. Product counts what was recognized. All three are right, and all three live in your BI tool under names nobody wrote down.
That is not a model problem. It is a definitions problem.
One definition. Everything downstream reads from it.
A semantic layer is the translation layer between raw data and business language. It records what your organization means by a term, which datasets and fields it resolves to, and the rules that apply when someone asks for it. Both people and AI read from it, so a natural language query returns the metric you defined instead of whichever column happened to look right.
In Knowi that layer is the governed dataset. Any query result, including a Cloud9QL join across sources, is saved as a reusable object carrying its field mappings, definitions, and transformations.
Map your vocabulary to the actual data.
A term carries its meaning and the exact place it resolves to, so a definition is executable rather than documentation someone has to remember to apply.
- Plain-English name, or a reusable Cloud9QL function
- Aliases, so churn, attrition, and logo loss land in one place
- Mappings to specific datasets and fields
- Scoped account-wide, or to a single dataset
See what is trusted, and what is not.
The data catalog is one inventory of every dataset, data source, dashboard, and widget you can reach, with its semantic setup and certification status visible at a glance. People find what already exists instead of rebuilding it.
Certified assets rank higher in Agentic BI chat, and carry a blue checkmark everywhere they appear.
What happens before the agent answers.
The semantic layer runs first. By the time a query is written, the ambiguity is already gone.
Matches your words
The question hits the glossary first. Terms and their aliases resolve to specific datasets and fields, instead of the agent pattern-matching on column names.
Prefers certified assets
When more than one asset could answer, human-certified assets rank first. Certification influences ranking, it does not silently hide anything else.
Normalizes the values
Global alias datasets map "CA", "Calif.", and "California" to one canonical value before the query runs. Up to 10 reference sources per account.
Follows your relationships
Connected assets and lineage tell the agent how your data actually relates, plus the primary date field and aggregation rules that apply.
The difference is not that the agent tries harder. It is that "revenue", "California", and "last quarter" each have exactly one meaning by the time the query is written.
Two minutes, one definition, every answer downstream.
Watch a metric get defined once in the glossary, then answered the same way by a dashboard, a natural language question, and an agent.
Not all semantic layers are equal.
Most of them assume you already loaded and modeled everything into a warehouse. That assumption is where the months go.
- 1.Is there a real semantic layer, or does the AI infer meaning from column names?
- 2.Does it need a warehouse and a modeling project before you can use it?
Governed by people, applied by agents.
Data governance that an agent actually respects. The AI drafts, a person decides, and everything downstream inherits that decision.
Certification
A human reviews an asset and certifies it. That tells everyone it is verified and safe to reuse, and it ranks the asset higher in Agentic BI chat. A blue checkmark marks it in every asset listing and widget panel. Certification is per asset and never inherited, so a certified dashboard does not quietly vouch for an unreviewed dataset.
Role-scoped access
Glossary management is admin only. Editing semantic details takes semantic edit access plus native access to the asset itself. Certifying takes a separate certification permission. Viewing stays scoped to what you can already see.
AI drafts, humans publish
Knowi suggests descriptions and glossary definitions to save the blank-page work, and you choose the model behind those suggestions. Every suggestion stays in the form until someone reviews and saves it. Nothing publishes on its own.
Global AI instructions
Set the account-wide rules once: fiscal calendar, currency conventions, default aggregation policy. Admins own them, and every agent answer respects them without anyone restating it in the question.
Data lineage you can follow
Every asset links to its lineage: how it was built, how each individual field was derived, and which other assets are associated with it. When someone questions a number, you trace it instead of relitigating it.
Available over MCP
The semantic layer is reachable programmatically through the Knowi MCP server: list glossary terms, map them, configure dataset semantics, and pull back how a given question resolved.
Before you commit to it.
How do I know an AI answer built on the semantic layer is accurate?
Because the definitions are set before the AI runs, not inferred by it. Your glossary term resolves to a specific dataset and field, global alias datasets normalize the values, and the primary date field settles what "last quarter" means. The agent is executing your definitions rather than guessing at column names, and you can trace how any question resolved.
Do I need a data warehouse or an ETL pipeline before I can use it?
No. Knowi builds the governed dataset directly over live sources, including SQL databases, NoSQL stores like MongoDB and Elasticsearch, REST APIs, and documents. The dataset is the semantic layer, and it is built at query time. If you already run a warehouse, it connects to that too.
How is this different from dbt Semantic Layer, Cube, or AtScale?
Those sit on top of data you have already loaded and modeled, and the model is maintained as code in a repo. Knowi's layer works over live multi-source data with no ETL step first, and it is maintained in the UI by the people who own the data, with role-scoped permissions and certification. The practical difference shows up in cross-source metrics: joining MongoDB to Postgres to a REST API is a Cloud9QL query saved as one governed dataset, not a pipeline project.
How is a business glossary different from a data dictionary?
A data dictionary describes the data as it is stored: table names, column names, data types. A business glossary describes what the business means: what counts as an active user, which discounts come out of revenue, whether churn is measured on logos or dollars. Knowi's glossary is the second kind, and it goes further by binding each term to the specific datasets and fields it resolves to, so the definition is executable rather than documentation someone has to read and apply by hand.
Can it work alongside a Snowflake, Databricks, or Power BI semantic model?
Yes. Knowi connects to those platforms as data sources, so anything you have already modeled there stays where it is and can be governed and certified as a Knowi dataset. The reason teams add Knowi's layer on top is coverage: a warehouse semantic model only describes what has been loaded into the warehouse. Knowi extends the same governed layer over the MongoDB, Elasticsearch, and REST API data that never made it into the pipeline.
What happens when two teams genuinely define the same metric differently?
You do not have to force them into one number. Terms can be scoped globally across the account or to a single dataset, so "revenue" can mean bookings in the finance dataset and closed-won in the sales dataset. Aliases keep both discoverable, and each answer carries the definition it used.
What if my field names are inconsistent or cryptic?
That is the normal starting point. Business display names sit over raw field names, field synonyms map everyday phrasing to a calculation or a Cloud9QL expression, and global alias datasets reconcile up to 10 reference sources of value variants. Nothing needs renaming at the source.
Who can edit the business glossary and certify a dataset?
Glossary management is admin only. Editing an asset's semantic details requires semantic edit access plus native access to that asset. Certifying requires a separate certification permission on top of native access. Viewing is scoped to the assets a user can already reach.
Does the AI publish definitions on its own?
No. Knowi drafts asset descriptions and suggests glossary definitions, and you choose which model powers those suggestions. Every suggestion stays in the form until a person reviews and saves it.
Can I reach the semantic layer programmatically?
Yes, through the Knowi MCP server. You can list and map glossary terms, configure dataset semantics, and retrieve how a question resolved to assets and fields, from any MCP-compatible client.
Where does the semantic layer live in the product?
Under Data › Semantic, which holds the Glossary, the Catalog, and Global Settings. The Semantic Details panel for an individual asset is also reachable directly from asset listings, dashboards, queries, and widgets, so you can configure an asset without leaving what you are working on.
Every answer, from the same definitions.
Bring one metric your teams argue about. In 30 minutes we will define it once in the glossary and show every downstream answer line up behind it.
Works on the sources you already have. No warehouse project first.