> 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/active-platform-features.md).

# Active platform features

The **Active platform features** section is the home for ODD Platform's event-driven, opt-in behaviours — the features where the platform is itself an actor in the data lifecycle rather than a passive system of record. The role is durable: anything the platform **does** on the operator's behalf (detect a condition and raise an alert, deliver a notification through Slack or email, record a change to an entity, host a discussion thread, broker a question to an external AI service) belongs here.

ODD covers active platform features through six independently-configured subsystems. Each is opt-in — disabled out of the box, enabled per its own configuration surface — so deployments use whatever subset matches their workflow.

Open them either from the entity-level UI (the **Alerts**, **Activity**, and **Discussions** tabs that appear on data-entity pages once each subsystem is wired up), the global **Activity** page, or the platform's HTTP API. There is no single top-level navigation tab named "Active platform features"; the surface area is reached through the sub-features as they apply to the entities and workflows the operator is working in.

## Subsections

* [**Alerting**](/features/active-platform-features/alerting.md) — the platform watches each entity for failed jobs, failed data-quality tests, backwards-incompatible schema changes, and externally-injected distribution anomalies. The **Alerts** section in the navigation pane (with **All / My Objects / Dependents** tabs) lists **open** alerts only; resolved history is read on each entity's own Alerts tab. Auto-resolution and per-entity halt configuration shape the queue size; the lifecycle and cleanup rules are the operator-relevant detail.
* [**Notifications**](/features/active-platform-features/notifications.md) — alerts route out of the platform via Slack incoming-webhook, generic webhook, and SMTP email. The user-facing description (which channels exist, what the operator gets, how to disable) lives here; the operator-side configuration keys (`notifications.*`, the PostgreSQL replication prerequisite, the Gmail SMTP example, the AlertManager inbound webhook) live on the platform's [configuration reference](/configuration-and-deployment/odd-platform.md#enable-alert-notifications).
* [**Activity Feed**](/features/active-platform-features/activity-feed.md) — the platform records every metadata change as an event (entity lifecycle, ownership, tags, terms, dataset-field edits, data-entity-group changes, alerts) on a global **Activity** page and on each entity's **Activity** tab. The feed is the audit trail and the change-driven discovery surface.
* [**Data Collaboration**](/features/active-platform-features/data-collaboration.md) — operators start in-app discussion threads anchored to specific data entities, with replies tracked back into the platform from a Slack workspace. Bidirectional with Slack via OAuth + the [Events API](https://docs.slack.dev/apis/events-api/); distinct from the outgoing-only Slack alert webhook used by Notifications.
* [**GenAI assistant**](/features/active-platform-features/genai.md) — opt-in proxy from a single platform endpoint to an external AI service the operator deploys and operates separately. The platform itself does not embed an LLM; it forwards questions verbatim and returns whatever the service returns. API-only today.
* [**Metrics Ingestion**](/features/active-platform-features/metrics-ingestion.md) — push time-series metrics into the platform through `POST /ingestion/metrics` and surface them on each affected data entity's Metrics tab. Two storage backends (`INTERNAL_POSTGRES` default, `PROMETHEUS` for tenant-isolated multi-deployment setups); the unauthenticated `/ingestion/metrics` endpoint requires perimeter authentication for any non-trusted network.

## Why this is a separate pillar

The [Data Discovery](/features/data-discovery.md), [Data Modelling](/features/data-modelling.md), and [Master Data Management](/features/master-data-management.md) pillars are read-oriented — operators and users navigate the catalog to **find** existing entities, examine **structure** (queries, relationships), and consult **operator-curated reference data**. The platform is a system of record that surfaces what was ingested.

The [Management](/features/management.md) section is operator-mutating — every tab there changes how the platform itself is wired up: register a data source, issue a collector token, author a role, curate a tag, attach an owner.

Active platform features are different from both:

* They are **event-driven**: the platform reacts to ingest events (a failed job triggers an alert; a description edit emits an activity-feed event), to operator actions (a Discussions thread is started; a question is asked of the AI), or to external triggers (Prometheus AlertManager pushes a distribution anomaly through the inbound webhook).
* They produce **side effects**: alerts are stored, notifications go out over Slack / email / generic webhook, activity events are persisted, discussion messages are mirrored into Slack, AI questions are forwarded to an external service.
* They are **opt-in per subsystem**: each one is disabled by default and gated by its own `*.enabled` flag plus the configuration surface that supports it. A deployment can run with all six off and still serve the catalog — none is required.

{% hint style="warning" %}
**If you supply your own configuration, define `notifications.enabled` and `datacollaboration.enabled` explicitly — the platform reads these two flags with no built-in fallback and fails to start if either is missing.** The shipped `application.yml` sets both to `false`, so a default deployment is unaffected. But the platform resolves these two flags at startup with no default value baked in, so a custom or externalized configuration (a mounted `application.yml`, a Spring profile, or environment-variable overrides) that omits either key leaves the platform unable to resolve the flag and it **aborts startup** rather than defaulting the feature off. Always carry both keys forward into any configuration you author. The other subsystem flags (`genai.enabled`, `metrics.storage`) do not share this hazard.
{% endhint %}

That distinction shows up in the configuration footprint: every one of the six subsystems has a dedicated section under [Configure ODD Platform](/configuration-and-deployment/odd-platform.md) (Alert Notifications, Prometheus AlertManager Integration, Data Collaboration, GenAI Configuration, Enable Metrics, plus the platform-level activity-feed partition setting `odd.activity.partition-period`). The other pillars consume configuration but rarely own dedicated config sections — their feature pages link out to per-key references rather than carrying their own configuration footprint.

## Where to next

* For the catalog read-side counterparts — search, the directory, the Catalog Overview home page → see [Data Discovery](/features/data-discovery.md).
* For the operator-mutating UI surface — namespaces, datasources, owners, tags, roles, policies → see [Management](/features/management.md).
* For the operator-side configuration keys behind the six subsystems → see [Configure ODD Platform](/configuration-and-deployment/odd-platform.md).
* For the API surface behind the six subsystems → see [API Reference](/developer-guides/api-reference.md). Per-subsystem sub-pages: [Alerts](/developer-guides/api-reference/alerts.md), [Data Collaboration](/developer-guides/api-reference/data-collaboration.md), [GenAI](/developer-guides/api-reference/genai.md). The Activity Feed, Metrics Ingestion, and notifications dispatch APIs are documented inline on each active-platform-features sub-page where they apply.
* For the broader catalog vocabulary (Data Entity, ODDRN, Plugin, Push adapter) → see [Main Concepts](/introduction/main-concepts.md).
