> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dqlabs.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> How Domain, Product, Application, Tag, and Glossary work together to give data assets business context in Prizm.

<script type="application/ld+json">
  {`{
            "@context": "https://schema.org",
            "@type": "TechArticle",
            "headline": "Semantics Overview",
            "description": "How Domain, Product, Application, Tag, and Glossary work together to give data assets business context in Prizm.",
            "url": "https://docs.dqlabs.ai/architecture/semantics/overview",
            "publisher": {
              "@type": "Organization",
              "name": "DQLabs Inc",
              "logo": "https://media.brand.dev/332adc35-5bc4-4d2b-bf78-256aa4a5e414.svg"
            }
            }`}
</script>

Semantics are the organizational layer that connects raw data assets to the business concepts they represent. Every major surface in Prizm — the asset catalog, quality score groupings, RBAC rules, and criticality scoring — uses semantic context to filter, group, and prioritize. Without semantics, assets are unnamed tables; with semantics, they have owners, business meaning, and a place in the organization.

## The five semantic types

| Type            | Purpose                                                                   | Applies to                                 | Cardinality                                                  |
| --------------- | ------------------------------------------------------------------------- | ------------------------------------------ | ------------------------------------------------------------ |
| **Domain**      | Business area ownership and accountability                                | Assets, Attributes, Products, Applications | 0–1 per asset / attribute; exactly 1 per product             |
| **Product**     | Groups assets around a business concept with defined quality expectations | Assets, Attributes                         | Many assets per product; exactly 1 owning domain per product |
| **Application** | Represents source systems, processing platforms, and consumption tools    | Assets                                     | Many assets per application; many domains per application    |
| **Tag**         | Flexible labels for filtering, grouping, and policy targeting             | Assets, Attributes                         | 0–many per asset or attribute                                |
| **Term**        | Primary business definition for a data attribute                          | Attributes                                 | Exactly 1 per attribute                                      |

## How they relate

Domains establish the top-level ownership boundary — they answer the question "which business area is accountable for this data?" Each Domain can have Sub-domains for finer-grained ownership (e.g., Finance → Accounts Receivable).

Products live inside Domains. A Data Product groups the assets that deliver a specific business capability (e.g., a "Customer 360" product containing `customer_dim`, `orders_fact`, and `churn_score`). Every product has exactly one owning domain.

Applications are independent of the domain hierarchy. An Application — such as SAP, Snowflake, or Tableau — can span multiple domains and link to multiple products. It represents the system layer: where data is created, where it is processed, and where it is consumed.

Tags and Terms operate at the asset and attribute level. Tags are free-form and can stack — an asset can be `PII`, `Certified`, and `Production` simultaneously. Terms come from the Glossary and are assigned one per attribute — the single authoritative business definition for that column.

```text theme={null}
Domain
  └── Sub-domain
        └── Product  ←── Application (many-to-many)
              └── Asset
                    └── Attribute  ←── Term (Glossary)
                                   ←── Tag(s)
```

## Where semantics appear

| Platform surface                             | Semantic types used                     |
| -------------------------------------------- | --------------------------------------- |
| **Asset catalog** — filter panel             | Domain, Product, Application, Tag, Term |
| **Quality score page** — grouping dimensions | Domain, Tag, Application                |
| **Criticality scoring** — inputs             | Domain, Product membership              |
| **RBAC** — resource-level access control     | Domain, Product, Application, Tag, Term |
| **Converse** — natural language queries      | All five types (semantic search)        |
| **Alerts / Issues** — scoping                | Domain, Product, Tag                    |

<CardGroup cols={2}>
  <Card title="Domain" icon="sitemap" href="/architecture/semantics/domain">
    Define business areas and sub-domains. Set accountability and group assets by ownership.
  </Card>

  <Card title="Product" icon="box" href="/architecture/semantics/product">
    Group assets into data products with health metrics, SLAs, and adoption tracking.
  </Card>

  <Card title="Application" icon="grid-2" href="/architecture/semantics/application">
    Register source systems, processing platforms, and consumption tools.
  </Card>

  <Card title="Tag" icon="tag" href="/architecture/semantics/tag">
    Apply flexible labels to assets and attributes for filtering and policy targeting.
  </Card>

  <Card title="Glossary" icon="book-open" href="/architecture/semantics/glossary">
    Build a business vocabulary with Glossaries, Categories, and Terms linked to attributes.
  </Card>
</CardGroup>