# Overview 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 three navigation views (All / My Objects / Dependents). For the alert types and what triggers each, the lifecycle and auto-cleanup rules, the halt-notification UI and its `Distribution anomaly` caveat, the manual-resolve-deletion bug, 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 six locale translations — English (default), Spanish, Chinese, French, Ukrainian, Armenian — loaded at SPA bootstrap and switchable through a gear-icon picker 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 6 supported locales, the gear-icon picker affordance, the per-device-not-per-user persistence model, the missing-key fall-through behaviour, and the contribution workflow for adding new locales. --- # 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/features.md?ask= ``` 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.