# 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 five 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. Open and resolved alerts surface on the **Alerts** section in the navigation pane (with **All / My Objects / Dependents** tabs) and 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. ## 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 with retention, 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 five off and still serve the catalog — none is required. That distinction shows up in the configuration footprint: every one of the five subsystems has a dedicated section under [Configure ODD Platform](/configuration-and-deployment/odd-platform.md) (Alert Notifications, Prometheus AlertManager Integration, Data Collaboration, GenAI Configuration, 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 five subsystems → see [Configure ODD Platform](/configuration-and-deployment/odd-platform.md). * For the API surface behind the five 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). The Activity Feed, GenAI, 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: 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= ``` 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.