Active platform features

Platform behaviours where ODD is itself an actor — alerts, notifications, activity tracking, in-app discussions, AI assistance. Distinct from the passive cataloguing pillars and from the operator-muta

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

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

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

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

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