> For the complete documentation index, see [llms.txt](https://docs.opendatadiscovery.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.opendatadiscovery.org/features/features.md).

# Overview

One-page index of ODD Platform's most important features — a quick-scan surface that points each feature at its canonical home, API surface, and operator-configuration keys.

This page is the **one-page index** of ODD Platform's most important features — a quick-scan surface for discovering what the platform does. For step-by-step walkthroughs and configuration detail, follow the cross-links from each feature's section to its dedicated page: each feature below points at (a) its **canonical home** — for read-oriented features, one of the six governance pillars ([Data Discovery](/features/data-discovery.md), [Data Modelling](/features/data-modelling.md), [Master Data Management](/features/master-data-management.md), [Data Quality](/features/data-quality.md), [Data Lineage](/features/data-lineage.md), [Data Glossary](/features/data-glossary.md)); for operator-mutating UI workflows, the [Management](/features/management.md) section; for the platform's event-driven, opt-in behaviours (alerts, notifications, activity tracking, data collaboration, GenAI), the [Active platform features](/features/active-platform-features.md) section; (b) its **API surface** under the [API Reference](/developer-guides/api-reference.md) hub; and (c) its **operator-configuration keys** under [Configure ODD Platform](/configuration-and-deployment/odd-platform.md). For the broader vocabulary and the [Data Governance map](/introduction/main-concepts.md#data-governance-map), see [Main Concepts](/introduction/main-concepts.md).

[Metadata Storage](#metadata-storage)\
[Search and Filtering](/features/data-discovery/search.md)\
[End-to-end Data Objects Lineage](/features/data-lineage/data-objects.md)\
[End-to-end Microservices Lineage](/features/data-lineage/microservices.md)\
[Data Quality Test Results Import](/features/data-quality/test-results-import.md)\
[Alerting](/features/active-platform-features/alerting.md)\
[ML Experiments](/features/data-discovery/groups-domains.md#relationship-to-ml-experiments)\
[Manual Object Tagging](/features/data-discovery/tagging.md)\
[Data Entity Groups & Domains](/features/data-discovery/groups-domains.md)\
[Catalog Overview page](/features/data-discovery/catalog-overview.md)\
[Directory](/features/data-discovery/directory.md)\
[Dictionary terms](/features/data-glossary/business-glossary.md)\
[Activity Feed for Monitoring Changes](/features/active-platform-features/activity-feed.md)\
[Data Collaboration](/features/active-platform-features/data-collaboration.md)\
[Dataset Quality Statuses (SLA)](/features/data-quality/sla-statuses.md)\
[Dataset schema diff](/features/data-discovery/schema-diff.md)\
[Associating Terms with Data Entities through Descriptive Information](/features/data-glossary/business-glossary.md#term-to-entity-associations)\
[Adding Business Names for Data Entities and Dataset Fields](/features/data-discovery/business-names.md)\
[Entity description](/features/data-discovery/entity-description.md)\
[Custom metadata](/features/data-discovery/custom-metadata.md)\
[Per-column annotation](/features/data-discovery/per-column-annotation.md)\
[Integrating Vector Store Metadata](/features/data-discovery/vector-stores.md)\
[GenAI assistant](/features/active-platform-features/genai.md)\
[Data Modelling](/features/data-modelling.md)\
[Query Examples](/features/data-modelling/query-examples.md)\
[Relationships and ERDs](/features/data-modelling/relationships.md)\
[Data Quality Dashboard](/features/data-quality/dashboard.md)\
[Filters to Include and Exclude Objects from Ingest](/integrations/integrations/ingestion-filters.md)\
[Data Entity Statuses](/features/data-discovery/statuses.md)\
[Alternative Secrets Backend](/configuration-and-deployment/collectors-secrets-backend.md)\
[Lookup Tables](/features/master-data-management/lookup-tables.md)\
[Integration Wizards](/integrations/integrations/integration-wizard.md)\
[Data Entity Attachments](/features/data-discovery/attachments.md)\
["Recommended" panel on the main page](/features/data-discovery/catalog-overview.md#recommended)\
[Custom navigation links](https://docs.opendatadiscovery.org/features/pages/YH2ILihhfTPfYTyBhtw2#additional-navigation-links-odd.links)\
[Metadata stale](/features/data-discovery/metadata-stale.md)\
[Machine-to-Machine (M2M) tokens](/configuration-and-deployment/enable-security/authentication/s2s.md)\
[Multilingual UI](/features/multilingual-ui.md)

{% hint style="info" %}
**Looking for the HTTP API?** Every Platform endpoint is documented at [API Reference](/developer-guides/api-reference.md) — grouped by feature area, with operation IDs, paths, and back-links to each feature page.
{% endhint %}

## Metadata Storage

The platform's metadata storage is a single PostgreSQL database that holds every catalog entity, every lineage edge, every term, and the full-text search index — no extra Elasticsearch / Solr / Neo4j services to deploy. Metadata is processed near-real-time as collectors and push adapters report it; storage capacity scales with the underlying PostgreSQL cluster.

For the deployment topology and how metadata flows from a source system to the catalog screen, see [Architecture → Data flow](/introduction/architecture.md#data-flow); for the operator-side configuration of the database itself, see [Configure ODD Platform → PostgreSQL Configuration](/configuration-and-deployment/odd-platform.md#postgresql-configuration).

## Search and Filtering

The catalog's query-oriented entry path — type a term, narrow by seven facets (Datasource / Type / Namespace / Owner / Tag / Groups / Statuses), and find data entities across names and metadata in seconds. Search is available across the Catalog, Query Examples, Master Data, Management, and Dictionary tabs.

See the dedicated [Search and Filtering](/features/data-discovery/search.md) page under [Data Discovery](/features/data-discovery.md) for the seven facets, the per-result information / question icons, and the indexing / ranking technical detail.

## End-to-end Data Objects Lineage

Upstream and downstream lineage across the full ODD entity model — datasets, transformers, transformer runs, quality tests, consumers, data inputs, data entity groups (including [ML experiments](/features/data-discovery/groups-domains.md#relationship-to-ml-experiments)), and entity relationships — rendered as a per-entity Lineage tab plus the dedicated Group lineage endpoint that returns the union of a [Data Entity Group](/features/data-discovery/groups-domains.md)'s children's lineage.

See the dedicated [Data Objects Lineage](/features/data-lineage/data-objects.md) page under [Data Lineage](/features/data-lineage.md) for the entity-class participation table, the `lineage_depth` and `expanded_entity_ids` query parameters, and the Group lineage endpoint.

## End-to-end Microservices Lineage

Microservice call lineage rendered alongside data-object lineage — sourced from OpenTelemetry traces ingested through [`odd-tracing-gateway`](/integrations/integrations/odd-tracing-gateway.md) (the platform's only [standalone gateway](/introduction/main-concepts.md#the-architecture-chain) push adapter today).

See the dedicated [Microservices Lineage](/features/data-lineage/microservices.md) page under [Data Lineage](/features/data-lineage.md) for the OpenTelemetry-to-ODD path and the gateway's role in the architecture chain.

## Data Quality Test Results Import

The Platform ingests test results from [**Great Expectations**](/integrations/integrations/odd-great-expectations.md) and [**dbt tests**](/integrations/integrations/odd-dbt.md) (both push-clients in the ODD ecosystem), plus statistical profiles generated by [**odd-collector-profiler**](/integrations/integrations/odd-collector-profiler.md) (which uses Capital One's [DataProfiler](https://github.com/capitalone/DataProfiler) under the hood). Custom frameworks can push their own test results through the `POST /ingestion/entities` endpoint of the [ODD Specification](/introduction/main-concepts.md#odd-specification).

See the dedicated [Test Results Import](/features/data-quality/test-results-import.md) page under [Data Quality](/features/data-quality.md) for the per-integration setup paths and the custom-framework escape hatch.

## Alerting

The platform watches each catalogued entity for failed jobs, failed data-quality tests, backwards-incompatible schema changes, and externally-injected distribution anomalies — and tracks every alert through an `OPEN` → `RESOLVED` lifecycle with per-entity halt configuration and four navigation views (All / My Objects / Downstream / Upstream). For the alert types and what triggers each, the lifecycle and auto-cleanup rules, the halt-notification UI and its `Distribution anomaly` caveat, and the API surface, see the dedicated [Alerting](/features/active-platform-features/alerting.md) page under [Active platform features](/features/active-platform-features.md). For how alerts get out of the platform — Slack, email, generic webhook, plus the Prometheus AlertManager inbound webhook — see [Notifications](/features/active-platform-features/notifications.md).

## ML Experiments

In ODD, an **ML experiment** is a [Data Entity Group](/features/data-discovery/groups-domains.md) 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. ML Experiments are not a separate feature surface; they reuse the DEG primitive for a specific workflow.

See [Data Entity Groups & Domains → Relationship to ML Experiments](/features/data-discovery/groups-domains.md#relationship-to-ml-experiments) under [Data Discovery](/features/data-discovery.md) for the framing, the catalog-view-not-experiment-tracker positioning, and the lineage cross-link.

## Manual Object Tagging

Lightweight labelling for data entities and columns — apply tags to drive faceted search, surface `Important`-flagged labels visually, and feed the Catalog Overview's Top tags chip strip.

See the dedicated [Manual Object Tagging](/features/data-discovery/tagging.md) page under [Data Discovery](/features/data-discovery.md) for the tag application workflow, the three `TAG_*` RBAC permissions, and the read-side / Management-side split (this page is read-side; vocabulary curation lives at [Management → Tags](/features/management.md)).

## Data Entity Groups & Domains

Logical containers that gather related entities (datasets, transformers, quality tests, consumers) under one umbrella with their own metadata, owners, tags, and terms. Flagging a DEG as a **domain** surfaces it on the [Catalog Overview page](/features/data-discovery/catalog-overview.md)'s Domains section as a top-level discovery surface.

See the dedicated [Data Entity Groups & Domains](/features/data-discovery/groups-domains.md) page under [Data Discovery](/features/data-discovery.md) for the DEG metadata model, the Domain framing, the relationship to ML Experiments, and the Group lineage cross-link.

## Catalog Overview page

The **Overview page** is the catalog's home page — a unified surface that combines [Search](/features/data-discovery/search.md), the [Directory](/features/data-discovery/directory.md) level-1 cards, [Top tags](/features/data-discovery/tagging.md), [Domains](/features/data-discovery/groups-domains.md), the per-class **Entities** report, the **Recommended** quick-jumps, and (when authentication is on) an Owner-association request.

See the dedicated [Catalog Overview page](/features/data-discovery/catalog-overview.md) page under [Data Discovery](/features/data-discovery.md) for the per-section walkthrough, the Recommended panel sub-surface, and the disambiguation between the catalog's Overview *page* and a data entity's Overview *tab*.

## Directory

The **Directory** is the catalog's browse-oriented entry point. It complements [Search](/features/data-discovery/search.md): where Search is query-driven, the Directory walks down a four-level hierarchy — **data source types → data sources → entity types → entities** — so an operator can drill into the catalog without typing a query. Reach for it when you know the kind of source you want to explore (PostgreSQL, Snowflake, Kafka, ...) but not the specific entity, or when you want a per-source coverage view.

See the dedicated [Directory](/features/data-discovery/directory.md) page under [Data Discovery](/features/data-discovery.md) for the level-by-level walkthrough, the four backing API endpoints (`/api/directory`, `/api/directory/datasources`, `/api/directory/datasources/{id}/types`, `/api/directory/datasources/{id}`), and the relationship to the [Catalog Overview page](/features/data-discovery/catalog-overview.md) (which surfaces the Directory's level-1 cards inline on the home page).

## Dictionary terms

Operator-curated term entities that name and describe the concepts your data represents. Terms are first-class catalog citizens with their own descriptions, owners, namespaces, RBAC, and links to data entities (description-text mentions and direct term-to-term links).

See the dedicated [Business Glossary](/features/data-glossary/business-glossary.md) page under [Data Glossary](/features/data-glossary.md) for the full term-creation flow, the seven `TERM_*` permissions, term-to-term linking modes, the term-to-entity descriptive walkthrough, and the API surface.

## Activity Feed for Monitoring Changes

The platform records every metadata change as a typed event on a global **Activity** page and on each entity's own **Activity** tab — entity lifecycle transitions, ownership changes, tag and term assignments, dataset-field edits, data-entity-group changes, and the alert-state transitions described above. The feed is the catalog's audit trail and its change-driven discovery surface.

See the dedicated [Activity Feed](/features/active-platform-features/activity-feed.md) page under [Active platform features](/features/active-platform-features.md) for the seven facets on the global filter panel, the full event-type catalogue (grouped by the metadata area each event describes), and the configuration entry for retention partitioning.

## Data Collaboration

ODD Platform's **Data Collaboration** feature lets users start in-app discussion threads anchored to specific data entities, with replies tracked back from a Slack workspace via OAuth + the [Slack Events API](https://docs.slack.dev/apis/events-api/). Conversations stay attached to the entity that anchored them, so an operator returning to a dataset months later can read the original threads — context, decisions, and follow-ups — without leaving the catalog. The feature is disabled by default (`datacollaboration.enabled=false`); for the per-entity Discussions-tab visibility caveat when disabled, the message-flow model, the disambiguation between this Slack app and the [Slack alert webhook](/features/active-platform-features/notifications.md#slack-incoming-webhook), and the operator-side setup, see the dedicated [Data Collaboration](/features/active-platform-features/data-collaboration.md) page under [Active platform features](/features/active-platform-features.md).

{% hint style="warning" %}
**Platform-feature toggles are captured at JVM boot and the top-level navigation chrome is invariant to the toggle state.** Three related properties operators should know:

* **Boot-immutable.** The active feature set is read from configuration at JVM startup (`@Value` injection on the feature resolver's constructor) and frozen for the lifetime of the process. Runtime configuration changes — for example via Spring Boot Actuator's `/actuator/refresh` endpoint — are not reflected by the platform's feature-active endpoint or by the sub-page feature gates. To change a platform feature's enabled state, edit the configuration and **restart the JVM process**.
* **Both keys must be present, or the platform fails to start.** The two feature flags `datacollaboration.enabled` and `notifications.enabled` are injected without a fallback default. A stock install is safe — the bundled `application.yml` supplies both keys set to `false` — but if you supply your own externalised `application.yml` (exactly the "edit the configuration and restart" workflow above) and **omit either key**, the platform aborts startup with an opaque `BeanCreationException: Could not resolve placeholder 'datacollaboration.enabled'` (or `notifications.enabled`). When overriding configuration, always carry both keys forward explicitly rather than copying only the line you want to change.
* **Chrome-invariant.** The platform's top-level navigation tabs (Data Modelling, Data Collaboration-flavoured surfaces, etc.) are rendered regardless of the corresponding feature-flag setting. Feature-gated functionality **inside** those tabs honours the active feature set — sub-page affordances, write endpoints, and gated panels behave correctly when the flag is off — but the tab itself stays visible. Users disabling `datacollaboration.enabled=false`, for example, still see the Data Modelling tab on the toolbar; clicking it lands on a page whose feature-gated affordances are correctly hidden, but the tab itself is not removed.

The operator-visible consequence is "the platform feature gating is consistent at the per-affordance level, not at the chrome level." Operators expecting "disabling a feature removes its tab" should know this is not how the platform's UI shell behaves today. The two configuration keys covered by this caveat are `datacollaboration.enabled` and `notifications.enabled` — the only two that flow through the boot-time feature resolver — plus any future platform-feature flag added under the same `@Value` boot-injection pattern.

**`genai.enabled` is not one of them.** Despite sitting next to the two flags above in configuration, the GenAI assistant toggle does not flow through the feature resolver: it is re-read on every call at the service layer rather than snapshotted at boot, and it is not part of the active-feature set the chrome consults. A `genai.enabled` change therefore takes effect on the next request without a restart — but, like the two flags above, it does not add or remove a top-level navigation tab.
{% endhint %}

## Dataset Quality Statuses (SLA)

Operator-set **Minor / Major / Critical** severities on dataset test results, aggregated into a single dataset-level **SLA colour** (Green / Yellow / Red) that downstream BI reports import directly via the `/api/datasets/{id}/sla` endpoint.

See the dedicated [Dataset Quality Statuses (SLA)](/features/data-quality/sla-statuses.md) page under [Data Quality](/features/data-quality.md) for the severity-setting workflow, the BI-report URL pattern, and the actual SLA-colour computation logic (which is **not** a direct severity-to-colour mapping — colours come from `SLACalculator` based on aggregate severity weights).

## Dataset schema diff

The platform compares each dataset's metadata between revisions and surfaces every change — added columns, removed columns, type changes, renames — as a visual side-by-side diff on the dataset's Structure tab. Backwards-incompatible changes additionally raise a [Backwards-incompatible schema change](/features/active-platform-features/alerting.md#backwards-incompatible-schema-change-what-triggers-it) alert.

See the dedicated [Dataset schema diff](/features/data-discovery/schema-diff.md) page under [Data Discovery](/features/data-discovery.md) for the revision history walkthrough, the diff illustrations, and the link to the alert rule.

## Associating Terms with Data Entities through Descriptive Information

The Wikipedia-About-style walkthrough — adding business terms to the Dictionary, designating term owners, authoring rich descriptions, linking terms inline using the required format, and the reverse-search capability that surfaces every entity and column linked to a term.

See the dedicated [Business Glossary → Term-to-entity associations](/features/data-glossary/business-glossary.md#term-to-entity-associations) section under [Data Glossary](/features/data-glossary.md) for the full step-by-step walkthrough with screenshots.

## Adding Business Names for Data Entities and Dataset Fields

Operators can assign **business names** to data entities and to individual dataset fields — alternative human-readable labels that surface alongside the original technical names everywhere the entity is rendered.

See the dedicated [Business names for data entities and dataset fields](/features/data-discovery/business-names.md) page under [Data Discovery](/features/data-discovery.md) for the per-entity and per-field workflows, the activity-feed audit-trail event, and the RBAC permissions.

## Entity description

The platform's per-entity **Description** panel is a Markdown-authored prose surface — operators write rich descriptions of what an entity represents, with linked glossary terms inline. The rendered description surfaces on the entity's Overview tab and on several adjacent surfaces (search-result previews, lineage-node hovers, group cards) so the same authored prose travels with the entity wherever it appears.

See the dedicated [Entity description](/features/data-discovery/entity-description.md) page under [Data Discovery](/features/data-discovery.md) for the Markdown authoring and render pipeline, the `DATA_ENTITY_DESCRIPTION_UPDATE` permission, the activity-feed event, and the cross-surface stored-XSS family admonition operators should review before opening the surface to less-trusted authors.

## Custom metadata

Operators can attach typed custom fields to data entities — strings, integers, booleans, dates, URLs, JSON, and arrays — with the field definitions managed as a separate catalog and per-entity values authored on the entity's Metadata panel. INTERNAL fields are operator-curated; EXTERNAL fields arrive from collector-ingested metadata.

See the dedicated [Custom metadata](/features/data-discovery/custom-metadata.md) page under [Data Discovery](/features/data-discovery.md) for the two-half architecture (FIELD catalogue read + per-entity VALUE write), the 7 supported types, the INTERNAL / EXTERNAL origin distinction, the per-entity permissions, and the 4 known limitations operators should know before depending on the feature.

## Per-column annotation

On every dataset's **Structure** tab, each column carries a per-column composer that lets operators author five distinct annotations — column description, column tags, glossary terms, enum values, and a column-level business name — each gated by its own RBAC permission and emitting its own activity-feed event.

See the dedicated [Per-column annotation](/features/data-discovery/per-column-annotation.md) page under [Data Discovery](/features/data-discovery.md) for the 5 sub-editors, the per-sub-editor permissions and audit-feed coverage, and the 3 operator-visible write-path caveats (including the silently-`403`s wiring-bug pair on `DATASET_FIELD_ADD_TERM` and the empty-array-clears-all-tags shape of `updateDatasetFieldTags`).

## Integrating Vector Store Metadata

The platform recognises **vector-typed datasets** as a first-class catalog primitive — a dedicated `Vector Store` dataset type plus a `Vector` column data type — so vector tables sit alongside relational ones in search, lineage, and ownership. Today the recognition is wired up for PostgreSQL `pgvector` columns via [`odd-collector`](/integrations/integrations/odd-collector.md); other adapters can emit the same types by following the [specification](https://github.com/opendatadiscovery/opendatadiscovery-specification/blob/main/specification/entities.yaml).

See the dedicated [Vector Store metadata](/features/data-discovery/vector-stores.md) page under [Data Discovery](/features/data-discovery.md) for the specification source, the adapter coverage, and how the type surfaces in the catalog.

## GenAI assistant

The platform ships an opt-in **GenAI assistant** that proxies natural-language questions to an external AI service the operator runs separately. Disabled by default (`genai.enabled=false`); when turned on, exposes a single platform endpoint `POST /api/genai/ask` that forwards each question to `POST {genai.url}/query_data` and returns the answer. API-only today — no in-app UI affordance currently calls it.

See the dedicated [GenAI assistant](/features/active-platform-features/genai.md) page under [Active platform features](/features/active-platform-features.md) for the configuration keys (with the operator-relevant defaults caveat — `genai.url` empty + `genai.request_timeout=0` will silently misconfigure if only `enabled=true` is set), the external AI service contract (`POST /query_data` with JSON `{"question": "..."}`), and the platform's `/api/genai/ask` request / response schemas.

## Data Modelling

The **Data Modelling** section of the platform houses operator-curated artefacts that describe how data is intended to be used — canonical query examples and the entity-to-entity relationships that collectors extract or that operators define. It opens from the top-level navigation **Data Modelling** and exposes two sub-surfaces: **Query Examples** (the snippets below) and **Relationships / ERDs**.

See the [Data Modelling overview](/features/data-modelling.md) for the section's structure, the UI entry points, and the RBAC permissions that gate each surface.

## Query Examples

**Query Examples** are operator-curated SQL / KQL / Spark snippets attached to data entities and glossary terms — the canonical "how this dataset is used" surface. Snippets carry a description that doubles as a prompt-style explanation of intent, link to one or more datasets, and link to terms; a dedicated faceted search and a per-entity / per-term lookup surface them across the catalog.

See the dedicated [Query Examples](/features/data-modelling/query-examples.md) page under [Data Modelling](/features/data-modelling.md) for the UI walkthrough, the seven `QUERY_EXAMPLE_*` RBAC permissions, the 16-endpoint API surface, and the term-linking workflow.

## Relationships and ERDs

ODD Platform tracks entity-to-entity relationships as first-class catalog objects: **ERD edges** between table-class entities (derived from foreign-key constraints in the source) and **graph edges** between graph-store nodes. The dedicated **Data Modelling → Relationships** surface lists every relationship across all data sources, with a tab strip for filtering by ERD vs graph and a search input scoped to relationship names.

See the dedicated [Relationships](/features/data-modelling/relationships.md) page under [Data Modelling](/features/data-modelling.md) for the cardinality model (`ONE_TO_EXACTLY_ONE` / `ONE_TO_ZERO_OR_ONE` / `ONE_TO_ONE_OR_MORE` / `ONE_TO_ZERO_ONE_OR_MORE`), the API surface, and the per-adapter ingestion coverage (PostgreSQL and Snowflake adapters surface ERD today; no adapter currently emits graph relationships).

## Data Quality Dashboard

Catalog-wide quality view at `/data-quality` — three breakdown rings (Table Health / Test Results / Monitored Tables), six anomaly-class metrics (Assertion Tests / Column Values Anomalies / Freshness Anomalies / Schema Changes / Unknown Category / Volume Anomalies), and per-side filter sets (one for tables, one for tests; `AND`-only conjunction).

See the dedicated [Quality Dashboard](/features/data-quality/dashboard.md) page under [Data Quality](/features/data-quality.md) for the per-anomaly-class definitions, the monitored-vs-unmonitored breakdown, and the two-side filtering model.

## Filters to Include and Exclude Objects from Ingest

Pull adapters in ODD's collectors ingest **everything they can see** by default. Per-plugin **ingestion filters** scope a plugin to a regex-defined slice — `schemas_filter` (PostgreSQL, Snowflake), `filename_filter` (S3, Azure Blob, GCS), `datasets_filter` (BigQuery), `pipeline_filter` (Azure Data Factory), and similar — so the catalog stays focused on what teams care about.

See the dedicated [Ingestion filters](/integrations/integrations/ingestion-filters.md) page under [Integrations](/integrations/integrations.md) for the include / exclude shape, the worked PostgreSQL example, and the per-adapter coverage matrix.

## Data Entity Statuses

Every catalogued entity carries a status — `UNASSIGNED` (default), `DRAFT`, `STABLE`, `DEPRECATED`, or `DELETED` — that signals where it sits in its lifecycle. Statuses surface as a [Search](/features/data-discovery/search.md) facet, drive an Activity-feed event, and trigger a soft-delete TTL handled by the platform's housekeeping job.

See the dedicated [Data Entity Statuses](/features/data-discovery/statuses.md) page under [Data Discovery](/features/data-discovery.md) for the per-status semantics, the operator workflow, the soft-delete TTL configuration, and the RBAC permission.

## Alternative Secrets Backend

Store collector configuration — the Platform token, per-plugin database passwords, cloud-provider credentials — in an external secrets backend instead of plaintext in `collector_config.yaml`. Currently the AWS Systems Manager Parameter Store provider is supported; values from the backend override values set in the local YAML file.

This feature is also known as the **collector secrets backend**. For the configuration reference, the region-resolution order, a worked SSM example, the required IAM permissions, and the known limitations (10-parameter pagination cap, no custom SSM endpoint, no timeout / retry override), see [Collector secrets backend](/configuration-and-deployment/collectors-secrets-backend.md).

## Lookup Tables

**Lookup Tables** are operator-curated reference tables that live inside the ODD Platform itself rather than in an external source system — managed end-to-end (schema, data, versioning, RBAC), exposed in the catalog as standard Data Entities, and reachable both through the platform API and directly via PostgreSQL's `lookup_tables_schema`. Find them in the platform UI under the **Master Data** top-level tab → **Lookup Tables**.

See the dedicated [Lookup Tables](/features/master-data-management/lookup-tables.md) page under [Master Data Management](/features/master-data-management.md) for the creation flow, supported field types, the Data tab walkthrough, the 9 `LOOKUP_TABLE_*` RBAC permissions, and the full `/api/referencedata/` API surface.

## Integration Wizards

The **Integration Wizard** is an in-app UI under [**Management → Integrations**](/features/management.md) that helps operators bootstrap `collector_config.yaml`. Pick an integration, fill in a handful of source-specific fields, copy the rendered YAML snippet into your collector config — the wizard is a template generator, not an installer.

See the dedicated [Integration Wizard](/integrations/integrations/integration-wizard.md) page under [Integrations](/integrations/integrations.md) for the per-card flow, the `META-INF/wizard/*.yaml` registry that backs it, the API surface (`GET /api/integrations`, `GET /api/integrations/{integration_id}`), the static-parameter substitution context (today only `platform_url`, sourced from `odd.platform-base-url`), and the wizard-vs-`collector_config.yaml` boundary.

## Data Entity Attachments

Operators and users can attach **files** (images, PDFs, CSVs, TXT) and **links** (remote URLs) to any data entity for additional context — runbook PDFs, sample CSVs, dashboard screenshots, ticketing references. Attachments persist across re-ingests and can be edited or deleted at any time.

See the dedicated [Data Entity Attachments](/features/data-discovery/attachments.md) page under [Data Discovery](/features/data-discovery.md) for the upload workflow, the storage-backend caveat (LOCAL is ephemeral; use REMOTE S3 / MinIO in production), and the [Attachment Storage Configuration](/configuration-and-deployment/odd-platform.md#attachment-storage-configuration) operator reference.

## "Recommended" panel on the main page

The Recommended panel is a sub-surface of the [Catalog Overview page](/features/data-discovery/catalog-overview.md) that surfaces personalised quick-jumps for the signed-in user — recently-ingested owned entities, lineage neighbours, and the catalog's most-popular entities.

See [Catalog Overview page → Recommended](/features/data-discovery/catalog-overview.md#recommended) under [Data Discovery](/features/data-discovery.md) for the four-column layout, the freshness indicator, the disambiguation from the Alerts → My Objects tab, and the [User-owner association](/configuration-and-deployment/enable-security/authorization/user-owner-association.md) prerequisite.

## Custom navigation links

Operators can populate the App Info menu (the popup behind the information icon in the top-right toolbar) with their own links — runbooks, internal wikis, support channels, anything that helps users navigate from the catalog into the rest of the platform's surrounding ecosystem. Links are configured once on the platform side via the `odd.links[]` setting and surface to every signed-in user.

For the configuration detail (YAML and env-var form, including the visibility caveat that every signed-in user can read the configured URLs), see [Configure ODD Platform → Additional navigation links](https://docs.opendatadiscovery.org/features/pages/YH2ILihhfTPfYTyBhtw2#additional-navigation-links-odd.links). Operationally part of the [Management](/features/management.md) section.

## Metadata stale

Entities that have not been re-ingested for longer than `odd.data-entity-stale-period` (integer days; default `7`) are flagged with an orange clock icon next to their name everywhere they appear in the catalog — a discovery-time prompt that the metadata's freshness is uncertain.

See the dedicated [Metadata stale](/features/data-discovery/metadata-stale.md) page under [Data Discovery](/features/data-discovery.md) for the freshness window's meaning, what the indicator does (and doesn't) signal, and the operator-side reference for tuning the value.

## Machine-to-Machine (M2M) tokens

ODD Platform supports **server-to-server (S2S) API-key authentication** — a single shared static token presented in the `X-API-Key` header — for non-UI programmatic callers such as CI/CD jobs, ingestion pipelines, and automation scripts. Disabled by default; designed for trusted non-human callers and grants ADMIN-role access.

For configuration, the header contract, the curl example, and security considerations (token rotation, HTTPS, blast radius), see [Server-to-server (S2S) authentication](/configuration-and-deployment/enable-security/authentication/s2s.md). Operationally part of the [Management](/features/management.md) section.

## Multilingual UI

The platform's UI ships with seven locale translations — English (default), Spanish, Chinese, French, Ukrainian, Armenian, and Brazilian Portuguese (from 0.28.0) — loaded at SPA bootstrap and switchable from the **Select language** entry in the user-account menu on the toolbar. The active locale persists per browser device in `localStorage`; the API surface and operator-authored content (entity descriptions, glossary terms, custom-metadata field names, namespaces, tag names) remain in their source language regardless of the active locale.

See the dedicated [Multilingual UI](/features/multilingual-ui.md) page for the 7 supported locales, the language-picker affordance in the user-account menu, the per-device-not-per-user persistence model, the missing-key fall-through behaviour, and the contribution workflow for adding new locales.