# Data Entity Groups & Domains

A **Data Entity Group (DEG)** is the platform's logical-grouping primitive — a catalog-level container that gathers related data entities (datasets, transformers, quality tests, consumers) under one umbrella with their own metadata, owners, tags, and terms. A **Domain** is a particular use of a DEG: a DEG flagged as a domain surfaces in the Catalog Overview home page's Domains section as a top-level discovery surface.

This page covers both framings — DEGs as the underlying primitive, and Domains as the operator-flag use of them.

## What a DEG is

Create groups to gather similar entities (datasets, transformers, quality tests, etc.). Each group can be enriched with specific metadata, owners, and [terms](/features/data-glossary/business-glossary.md).

**Example.** An organisation has ingested metadata related to its finances into the ODD Platform. All the entities are united into the Finance **Namespace** by default. To categorise entities, one creates Revenue and Payrolls DEGs.

![](/files/IhwfVgWbYEYX0a7C2D4O)

A DEG is itself a Data Entity (of type `DATA_ENTITY_GROUP`) — it has a detail page, an ODDRN, and participates in [lineage](/features/data-lineage/data-objects.md) (Group lineage returns the union of the group's children's lineage).

## The Domain framing

Flagging a DEG as a **domain** unlocks one extra surface: the Catalog Overview page renders a **Domains** section listing all domain-flagged DEGs as quick-jump tiles. This makes domain-flagged DEGs the platform's first-class discovery axis on the home page.

Operationally:

1. Create or open a DEG.
2. Use the DEG's edit surface to flag it as a domain.
3. The DEG now appears on the Catalog Overview's Domains section (which is conditional — the section appears only when at least one domain-flagged DEG exists).

The Domains section is also reachable through the [Search](/features/data-discovery/search.md) Groups facet, where domain DEGs participate alongside non-domain DEGs.

## DEG metadata

A DEG carries the same metadata model as any other Data Entity — owners, tags, terms, descriptions, statuses — at the group level. The convention is:

* **Owners** — set on the DEG to mark domain-stewardship at the group level instead of duplicating per-child.
* **Tags** — applied at the DEG level surface the group on Tag-faceted searches.
* **Terms** — link [glossary terms](/features/data-glossary/business-glossary.md) to the DEG to capture meaning.
* **Description** — narrative authoring describing what the group represents.

Children of the DEG keep their own metadata; the DEG-level metadata supplements it rather than replacing it.

## Relationship to ML Experiments

In ODD, an **ML experiment** is a Data Entity Group of class `ML_EXPERIMENT` that collects the entities produced by a training run — input datasets, feature tables, training jobs, model instances, and resulting model artifacts — into one logical container. Lineage, ownership, tags, and alerts follow through at the experiment level instead of being scattered across each child entity.

ML experiments are DEGs of a particular shape — the same primitive, used for a specific workflow.

{% hint style="info" %}
ML experiments in ODD are a **catalog view** over the assets that participated in the run. The platform does not track metrics, compare runs, or select a "best" model — it has no experiment-tracking UI or API of its own. For tracking, keep using MLflow, Weights & Biases, Comet, or your tool of choice, and push the resulting entities (datasets, models, runs) into ODD through a push adapter or the [ODD Specification](/introduction/main-concepts.md#odd-specification) so the experiment and its lineage are browsable alongside the rest of your data platform.
{% endhint %}

Each experiment's training-run inputs and outputs participate in the catalog-wide [lineage graph](/features/data-lineage/data-objects.md) — an operator opening an ML experiment's Lineage tab sees its dataset / model / run-level edges alongside the rest of the data platform.

## Group lineage

The dedicated [Group lineage](/features/data-lineage/data-objects.md#group-lineage) endpoint returns the lineage graph for the DEG's *children*, not the DEG itself. This is what an operator usually wants when reasoning about a domain or pipeline group — *"what does the Finance domain depend on, and what depends on it?"* is a question about the union of the children's edges.

## Where to next

* [Search and Filtering → Groups facet](/features/data-discovery/search.md) — narrow the catalog to entities that are members of selected DEGs.
* [Data Lineage → Data Objects → Group lineage](/features/data-lineage/data-objects.md#group-lineage) — the dedicated endpoint that returns DEG-children lineage.
* [Manual Object Tagging](/features/data-discovery/tagging.md) — the lighter-weight labelling counterpart for cross-cutting groupings that do not justify a DEG.
* [Main Concepts → Terms & Aliases — Data Entity Group](/introduction/main-concepts.md#terms-aliases) — the canonical-term reference.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.opendatadiscovery.org/features/data-discovery/groups-domains.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.