> 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).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

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