Active platform features

Platform behaviours where ODD is itself an actor — alerts, notifications, activity, discussions, AI assistance, metrics ingestion. Six opt-in subsystems, each independently configured.

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

• Activity Feed — 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 — 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; distinct from the outgoing-only Slack alert webhook used by Notifications.

• GenAI assistant — 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 — 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, Data Modelling, and Master Data Management 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 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.

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.

That distinction shows up in the configuration footprint: every one of the six subsystems has a dedicated section under Configure ODD Platform (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.

• For the operator-mutating UI surface — namespaces, datasources, owners, tags, roles, policies → see Management.

• For the operator-side configuration keys behind the six subsystems → see Configure ODD Platform.

• For the API surface behind the six subsystems → see API Reference. Per-subsystem sub-pages: Alerts, Data Collaboration, GenAI. 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.