Domain Knowledge

Domain Knowledge helps your team turn scattered knowledge into a single reviewable source of truth. Instead of each dashboard, analysis, or prompt using a different definition, you register terms, metrics, relationships, and AI suggestions in one place that can be safely reviewed and reused.

Why use it?

• Avoid conflicting definitions: "active customer", "net revenue", and similar terms gain one official meaning.
• Speed up collaboration: analysts, managers, and reviewers start speaking the same language.
• Improve product AI: approved context makes suggestions and answers more consistent.
• Add governance without slowing the team down: you can start simple and formalize the domain over time.

Data Catalog vs Domain Knowledge

The two areas complement each other:

Area	Main question
Data Catalog	Where is the data?
Domain Knowledge	What does it mean, how should it be measured, and how is it related?

What you find here

📘 Concepts

Define business terms and rules in plain language

📊 Semantic Layer

Formalize shared metrics, entities, and dimensions

🕸 Ontology

Model key business relationships when you need more precision

🤖 AI Suggestions

Receive AI suggestions and publish only what has been reviewed

How to use each area

Concepts

Start here. Concepts works as a living business glossary.

Use it when you want to register:

• important terms;
• operating rules;
• definitions that currently live in spreadsheets, chat messages, or team memory.

Example: "Active customer" = a customer with at least one purchase in the last 90 days.

Today you can create, edit, search, and archive concepts, and optionally connect them to technical catalog assets.

Difference between term, rule, entity, metric, and policy

Type	When to use it	Example
Term	Define the meaning of a word or expression the team uses	"Active customer"
Rule	Capture an operating condition, business criterion, or decision	"Orders above $500 require approval"
Entity	Name a core business object that may later become semantic or ontology structure	"Customer", "Contract", "Campaign"
Metric	Mark an official measure or a candidate official measure	"Net revenue", "CAC", "CPM"
Policy	Document a business guideline, restriction, or formal directive	"Do not reuse leads without consent"

Practical shortcut:

• use Term for meaning;
• use Rule for expected behavior;
• use Entity for business actors or objects;
• use Metric for numbers that need consistent interpretation;
• use Policy for norms and boundaries.

Semantic Layer

The Semantic Layer is where a concept becomes a reusable definition for analysis.

Use it when you need to:

• define an official metric;
• name business entities consistently;
• document how a measure should be interpreted in dashboards and analyses.

Example: "Net revenue" = revenue minus discounts and refunds.

Today you can maintain entities, metrics, dimensions, and mappings. More advanced modeling remains on the roadmap.

Ontology

Ontology becomes useful when defining terms and metrics is not enough and you need to describe domain relationships explicitly.

Use it to model:

• who relates to whom;
• relevant events and states;
• hierarchies and relationship rules.

Example: "Customer places Order" or "Contract belongs to Company".

Today you can maintain nodes and relationships. More formal domain modeling is planned for later.

AI Suggestions

AI helps speed up domain documentation, but publication stays under team control.

Use it when you want to:

• receive draft descriptions;
• promote concepts into metrics or more formal relationships;
• quickly review what makes sense and discard what does not represent the business.

Every suggestion is reviewed before it becomes published knowledge.

Recommended journey

1. Start by registering the business terms your team uses most in Concepts.
2. Review AI suggestions to speed up the first version of this knowledge base.
3. Promote stable items into the Semantic Layer when they need to become official metrics, entities, or dimensions.
4. Use Ontology only when domain relationships need more clarity.
5. Keep only reviewed knowledge as the reference for chats, analyses, and dashboards.

Governance, Permissions, and Multi-Tenancy

• knowledge belongs to the company;
• team remains a future applicability extension;
• the area operates with isolation across companies.

Important rule

Suggestion review is separate from publishing changes. This helps keep control over what becomes official knowledge.

Available now and what comes next

Topic	Status
Concepts	Available now
Semantic Layer	Available now
Ontology	Available now
AI suggestion review	Available now
Approved knowledge reused across product AI experiences	Available now
More advanced semantic modeling	Planned
Richer formal ontology	Planned
More automated enrichment at scale	Planned
Team applicability	Planned

See Also

• Data Catalog
• Approval Cycle
• Domain Knowledge API