# ODD Platform ## ODD Platform - [Overview](https://docs.opendatadiscovery.org/introduction/readme.md): ODD is an open-source, community-driven data discovery platform — ML-first, end-to-end microservices lineage, flexible data quality integration, and catalogs ML experiment metadata and lineage. - [Main Concepts](https://docs.opendatadiscovery.org/introduction/main-concepts.md): Core vocabulary and mental model for the Open Data Discovery project — what the pieces are, how they fit together, and where to dive deeper. - [Architecture](https://docs.opendatadiscovery.org/introduction/architecture.md): The structural mental model of an Open Data Discovery deployment — five-stage data flow, the components that run where, and the architectural concerns that cross every component. - [Overview](https://docs.opendatadiscovery.org/features/features.md): One-page index of ODD Platform's most important features — a quick-scan surface that points each feature at its canonical home, API surface, and operator-configuration keys. - [Data Discovery](https://docs.opendatadiscovery.org/features/data-discovery.md): Top-level UI section for the catalog's two entry paths — query-oriented Search and hierarchy-oriented Directory — surfaced together on the Catalog Overview page. - [Catalog Overview page](https://docs.opendatadiscovery.org/features/data-discovery/catalog-overview.md): The catalog's home page — a unified surface combining Search, Directory cards, Top tags, Domains, the per-class Entities report, Recommended quick-jumps, and (when auth on) Owner association. - [Directory](https://docs.opendatadiscovery.org/features/data-discovery/directory.md): Directory — the browsable catalog. Walk down data source types → data sources → entity types → entities without typing a query. - [Search and Filtering](https://docs.opendatadiscovery.org/features/data-discovery/search.md): Search and Filtering — the catalog's query-oriented entry point. Free-text search across entity names plus seven faceted filters. - [Data entity detail page](https://docs.opendatadiscovery.org/features/data-discovery/entity-detail-page.md): The data entity detail page — composition of the Overview tab, class-driven panel matrix, badges, sidebar list truncation, and per-panel permission map. Where every catalog discovery lands. - [Entity description](https://docs.opendatadiscovery.org/features/data-discovery/entity-description.md): Operator-authored Markdown description on each data entity — the platform's primary free-text annotation, persisted verbatim and rendered through the same component as terms and columns. - [Custom metadata](https://docs.opendatadiscovery.org/features/data-discovery/custom-metadata.md): Operator-curated metadata on data entities — a paired surface combining a deployment-wide field catalogue with per-entity value assignments. Surfaced on the entity's Overview tab. - [Per-column annotation](https://docs.opendatadiscovery.org/features/data-discovery/per-column-annotation.md): Per-column annotation on a dataset's Structure tab — description, tags, glossary terms, enum values, and business name editors on each column row, plus the write-path and UI caveats. - [Manual Object Tagging](https://docs.opendatadiscovery.org/features/data-discovery/tagging.md): Manual Object Tagging — apply tags to data entities and columns; the read-side counterpart to Management → Tags. - [Data Entity Groups & Domains](https://docs.opendatadiscovery.org/features/data-discovery/groups-domains.md): Data Entity Groups + the Domain framing — logical containers for related entities, how the Domain flag surfaces them on the Catalog Overview, and the relationship to ML experiments. - [Business names](https://docs.opendatadiscovery.org/features/data-discovery/business-names.md): Business names for data entities and dataset fields — operator-assigned alternative names that surface alongside the original technical names everywhere the entity is rendered. - [Data Entity Statuses](https://docs.opendatadiscovery.org/features/data-discovery/statuses.md): Data Entity Statuses — UNASSIGNED / DRAFT / STABLE / DEPRECATED / DELETED lifecycle on every catalogued entity, plus the soft-delete TTL configured by the platform's housekeeping job. - [Data Entity Attachments](https://docs.opendatadiscovery.org/features/data-discovery/attachments.md): Files (images, PDFs, CSVs, TXT) and remote-URL links attached to data entities for additional context. Storage backend is operator-configurable; the LOCAL default is ephemeral. - [Vector Store metadata](https://docs.opendatadiscovery.org/features/data-discovery/vector-stores.md): Vector Store cataloguing — datasets containing vector-typed columns recognised as a first-class dataset type, with per-column metadata reflecting the vector data type. - [Dataset schema diff](https://docs.opendatadiscovery.org/features/data-discovery/schema-diff.md): Dataset schema diff — visual side-by-side comparison of dataset schema revisions, with per-revision history and automatic alert raising for backwards-incompatible schema changes. - [Metadata stale](https://docs.opendatadiscovery.org/features/data-discovery/metadata-stale.md): Per-entity orange icon shown when an entity has not been re-ingested for longer than \`odd.data-entity-stale-period\` (default 7 days) — signals possible collector or source-side issues. - [Data Modelling](https://docs.opendatadiscovery.org/features/data-modelling.md): Top-level UI section for data-modelling artefacts — Query Examples and Relationships / ERDs. - [Query Examples](https://docs.opendatadiscovery.org/features/data-modelling/query-examples.md): Operator-curated SQL / KQL / Spark snippets attached to data entities and terms — the canonical "how to use this dataset" surface. - [Relationships](https://docs.opendatadiscovery.org/features/data-modelling/relationships.md): Entity-to-entity relationships in the catalog — ERD edges from foreign keys and graph edges between graph-store nodes. - [Master Data Management](https://docs.opendatadiscovery.org/features/master-data-management.md): Master Data Management aspect of Data Governance — operator-curated reference data managed inside the platform. - [Lookup Tables](https://docs.opendatadiscovery.org/features/master-data-management/lookup-tables.md): Operator-curated reference tables managed inside the ODD Platform — schema, data, RBAC, and API surface. - [Data Quality](https://docs.opendatadiscovery.org/features/data-quality.md): Catalog-side data-quality signals — test results from Great Expectations / dbt / odd-collector-profiler / custom frameworks, the cross-catalog Quality Dashboard, and dataset SLA statuses. - [Test Results Import](https://docs.opendatadiscovery.org/features/data-quality/test-results-import.md): How DQ test results land in ODD — push-client integrations with Great Expectations and dbt, statistical profiles via odd-collector-profiler, and the custom-framework ingestion endpoint. - [Quality Dashboard](https://docs.opendatadiscovery.org/features/data-quality/dashboard.md): The catalog-wide Data Quality Dashboard at /data-quality — three breakdown rings, six anomaly-class metrics, and the per-side filter sets for tables and tests. - [Dataset Quality Statuses (SLA)](https://docs.opendatadiscovery.org/features/data-quality/sla-statuses.md): Operator-set Minor / Major / Critical severities on dataset test results, the dataset-level aggregate SLA colour, and the /sla (PNG) and /sla\_report (JSON) endpoints for BI import. - [Test Run History](https://docs.opendatadiscovery.org/features/data-quality/test-run-history.md): Per-test history of every individual run — every status, every duration, every status-reason diagnostic. The drill-in counterpart to the Quality Dashboard's tests-by-latest-status summary. - [Data Lineage](https://docs.opendatadiscovery.org/features/data-lineage.md): Top-level UI section for upstream / downstream lineage across the ODD entity model — both data-object lineage and microservices-tracing lineage. - [Data Objects Lineage](https://docs.opendatadiscovery.org/features/data-lineage/data-objects.md): Per-entity upstream / downstream lineage across the full ODD entity model, plus the dedicated group-lineage endpoint for Data Entity Groups and ML experiments. - [Microservices Lineage](https://docs.opendatadiscovery.org/features/data-lineage/microservices.md): Microservice call lineage — OpenTelemetry traces ingested through odd-tracing-gateway and rendered alongside data-object lineage. - [Data Glossary](https://docs.opendatadiscovery.org/features/data-glossary.md): Top-level UI section for the in-app Business Glossary — term entities, term-to-term linking, term-to-data-entity descriptive associations, ownership, and RBAC. - [Business Glossary](https://docs.opendatadiscovery.org/features/data-glossary/business-glossary.md): Full reference for the in-app Business Glossary — term entities, the Dictionary tab UI, namespace scoping, ownership and RBAC, term-to-term linking, and term-to-data-entity descriptive associations. - [Active platform features](https://docs.opendatadiscovery.org/features/active-platform-features.md): Platform behaviours where ODD is itself an actor — alerts, notifications, activity, discussions, AI assistance, metrics ingestion. Six opt-in subsystems, each independently configured. - [Alerting](https://docs.opendatadiscovery.org/features/active-platform-features/alerting.md): Per-entity alerts for failed jobs, failed DQ tests, backwards-incompatible schema changes, and injected distribution anomalies — tracked through an OPEN → RESOLVED lifecycle with per-entity halt. - [Notifications](https://docs.opendatadiscovery.org/features/active-platform-features/notifications.md): How alerts move in and out of ODD Platform — outbound through Slack incoming webhook, generic webhook, or SMTP email; inbound from Prometheus AlertManager as Distribution Anomaly alerts. - [Activity Feed](https://docs.opendatadiscovery.org/features/active-platform-features/activity-feed.md): ODD Platform records every metadata change as a typed event on a global Activity feed and on per-entity Activity tabs — the catalog's audit trail and change-driven discovery surface. - [Data Collaboration](https://docs.opendatadiscovery.org/features/active-platform-features/data-collaboration.md): In-app discussion threads anchored to specific data entities, with replies tracked back from a Slack workspace via OAuth + the Slack Events API. Per-entity scope; opt-in. - [GenAI assistant](https://docs.opendatadiscovery.org/features/active-platform-features/genai.md): GenAI assistant — proxy natural-language questions to an external AI service. API-only today; configuration, contract, and operator caveats. - [Metrics Ingestion](https://docs.opendatadiscovery.org/features/active-platform-features/metrics-ingestion.md): Push time-series metrics via \`/ingestion/metrics\` and surface them on each entity's Metrics tab — covers payload shape, two storage backends (PostgreSQL + Prometheus), and operator caveats. - [Management](https://docs.opendatadiscovery.org/features/management.md): The operator-facing surface for everything configured inside the platform UI — nine tabs covering data sources, integrations, collectors, ownership, RBAC, taxonomy, and namespacing. - [Namespaces](https://docs.opendatadiscovery.org/features/management/namespaces.md): Logical scoping unit across terms, tags, data sources, collectors, and entity groups — covers the CRUD lifecycle, the four-sister-service auto-create side-door, and the audit-silence caveat. - [Multilingual UI](https://docs.opendatadiscovery.org/features/multilingual-ui.md): Seven locale translations for the ODD Platform UI shell — loaded at SPA bootstrap, switched via the toolbar, persisted per browser in localStorage. Operator-authored content stays verbatim. - [Overview](https://docs.opendatadiscovery.org/use-cases/use-cases.md): Cross-role use-case index — data compliance for data scientists, safe deprecation for data engineers, DQ visibility for QA, BI preparation for viz engineers, pre-sales for consultants. - [Data compliance for Data Scientists](https://docs.opendatadiscovery.org/use-cases/use-cases/dc-data-compliance.md): Data scientist walkthrough — using ODD Platform's catalogue search, tags, labels, and metadata to identify confidential data and develop GDPR-compliant ML models. - [Deprecation for Data Engineer \ Analyst](https://docs.opendatadiscovery.org/use-cases/use-cases/de-deprecation.md): Data engineer and analyst walkthrough — using ODD lineage and ownership to deprecate data objects safely, informing stakeholders, and mitigating downstream pipeline failure risk. - [Visibility for Data Quality Engineer](https://docs.opendatadiscovery.org/use-cases/use-cases/dq-visibility.md): Data quality engineer walkthrough — ingesting Great Expectations, dbt tests, DataProfiler statistics, and custom DQ framework results into ODD Platform for cross-team visibility. - [Data preparation for Visualization Engineer](https://docs.opendatadiscovery.org/use-cases/use-cases/viz-preparation.md): Visualization engineer walkthrough — consulting ODD tags and metadata to predict BI-tool performance, set dashboard security levels, and prepare data for chart development. - [Service Provider and Pre-Sales](https://docs.opendatadiscovery.org/use-cases/use-cases/service-presales.md): Service-provider and pre-sales consultant walkthrough — using the Platform API to gather a client's architectural landscape and toolset for better discovery-phase scope planning. - [Overview](https://docs.opendatadiscovery.org/integrations/integrations.md): Hub for every way metadata reaches the ODD Platform — pull adapters (collector-hosted), push adapters (in-process plugins, standalone gateways, direct SDK use). - [odd-collector (generic)](https://docs.opendatadiscovery.org/integrations/integrations/odd-collector.md): Generic ODD Collector — 41 pull adapters for databases, data warehouses, BI tools, streams, and MLOps platforms. - [odd-collector-aws](https://docs.opendatadiscovery.org/integrations/integrations/odd-collector-aws.md): AWS-services pull collector — 11 adapters for Glue, S3, Athena, Kinesis, SageMaker, and more. - [odd-collector-azure](https://docs.opendatadiscovery.org/integrations/integrations/odd-collector-azure.md): Azure-services pull collector — adapters for PowerBI, Azure SQL, Blob Storage, and Data Factory. - [odd-collector-gcp](https://docs.opendatadiscovery.org/integrations/integrations/odd-collector-gcp.md): GCP-services pull collector — adapters for BigQuery, BigTable, Google Cloud Storage, and GCS Delta Lake tables. - [odd-collector-profiler](https://docs.opendatadiscovery.org/integrations/integrations/odd-collector-profiler.md): Statistical data-profiling collector — runs DataProfiler against datasets and pushes per-dataset statistics to the platform. - [odd-airflow-2](https://docs.opendatadiscovery.org/integrations/integrations/odd-airflow-2.md): Airflow plugin that captures DAG, task, and task-run metadata via Airflow Listeners and pushes it to the ODD Platform. - [odd-dbt](https://docs.opendatadiscovery.org/integrations/integrations/odd-dbt.md): CLI push adapter that ingests dbt test results and model lineage into the ODD Platform. - [odd-spark-adapter](https://docs.opendatadiscovery.org/integrations/integrations/odd-spark-adapter.md): Spark Listener that captures Spark job lineage and pushes it to the ODD Platform. - [odd-great-expectations](https://docs.opendatadiscovery.org/integrations/integrations/odd-great-expectations.md): Great Expectations checkpoint ValidationAction that pushes expectation results to the ODD Platform. - [odd-cli](https://docs.opendatadiscovery.org/integrations/integrations/odd-cli.md): Operator-side CLI for pushing local file metadata, running dbt ingestion, and managing platform tokens. - [odd-tracing-gateway](https://docs.opendatadiscovery.org/integrations/integrations/odd-tracing-gateway.md): Optional standalone push-adapter service that ingests OpenTelemetry traces from operator microservices and exposes the inferred services as ODD entities for the Platform to pull. - [Ingestion filters](https://docs.opendatadiscovery.org/integrations/integrations/ingestion-filters.md): Ingestion filters — collector-side regex include / exclude rules that scope what schemas, tables, files, datasets, or pipelines a plugin ingests. Configured per-plugin in \`collector\_config.yaml\`. - [Integration Wizard](https://docs.opendatadiscovery.org/integrations/integrations/integration-wizard.md): The Integration Wizard — the in-app UI under Management → Integrations that generates collector\_config.yaml snippets for the integrations the platform recognises. - [Deployment Options](https://docs.opendatadiscovery.org/configuration-and-deployment/deployment.md): Pick a deployment path for ODD Platform and Collector — Docker Compose, Helm, AWS EKS, or from source — with step-by-step setup and pointers to the config deep-dives. - [Try locally](https://docs.opendatadiscovery.org/configuration-and-deployment/trylocally.md): Run ODD locally with docker-compose — a demo sandbox with the platform, sample database, lightweight pull collector, and metadata enricher. For production paths see Deployment Options. - [Deploy to Amazon Elastic Kubernetes Service (EKS)](https://docs.opendatadiscovery.org/configuration-and-deployment/quick_launch_on_amazon_elastic_kubernetes_service.md): Quick Launch of Open Data Discovery platform and collector on Amazon Elastic Kubernetes Service (EKS) - [Configure ODD Platform](https://docs.opendatadiscovery.org/configuration-and-deployment/odd-platform.md): This section defines how to configure ODD Platform in order to leverage all of its functionality and features. - [Health and monitoring](https://docs.opendatadiscovery.org/configuration-and-deployment/health-and-monitoring.md): Wire liveness/readiness probes to ODD Platform's /actuator/health and scrape metrics from /actuator/prometheus — what the health verdict does and does not cover. - [Collector secrets backend](https://docs.opendatadiscovery.org/configuration-and-deployment/collectors-secrets-backend.md): Load collector secrets (Platform token, DB passwords, cloud credentials) from an external backend — AWS SSM today, pluggable for additional providers — instead of plaintext YAML. - [Enable security](https://docs.opendatadiscovery.org/configuration-and-deployment/enable-security.md): ODD's two independent authentication surfaces — the UI/API surface (auth.type) and the ingestion endpoint (auth.ingestion.filter.enabled). Enabling one does not protect the other. - [Authentication](https://docs.opendatadiscovery.org/configuration-and-deployment/enable-security/authentication.md): ODD Platform's four supported authentication mechanisms for the UI/API surface — Disabled, Login form, OAuth2/OIDC, and LDAP — plus the S2S API-key surface for programmatic clients. - [Disabled authentication](https://docs.opendatadiscovery.org/configuration-and-deployment/enable-security/authentication/disabled-authentication.md): Disable platform authentication entirely — the default configuration for local deployments and demo sandboxes where no security is required. - [Login form](https://docs.opendatadiscovery.org/configuration-and-deployment/enable-security/authentication/login-form.md): Simplest auth mode — username/password credentials via auth.login-form-credentials. All login-form users receive ADMIN privileges; not suitable for production deployments. - [OAUTH2/OIDC](https://docs.opendatadiscovery.org/configuration-and-deployment/enable-security/authentication/oauth2-oidc.md): Configure ODD Platform to authenticate users via OAuth2/OIDC against AWS Cognito, GitHub, Google, Azure AD, Okta, Keycloak, or any custom OIDC-compliant identity provider. - [LDAP](https://docs.opendatadiscovery.org/configuration-and-deployment/enable-security/authentication/ldap.md): Configure ODD Platform to authenticate users against an existing LDAP server, including group-to-role mapping and the cross-mode user-name collision caveat for multi-mode deployments. - [Server-to-server (S2S)](https://docs.opendatadiscovery.org/configuration-and-deployment/enable-security/authentication/s2s.md): Configure server-to-server (S2S / M2M) API-key authentication for programmatic clients — CI/CD jobs, automation scripts, and non-human callers — alongside the configured interactive auth mode. - [Authorization](https://docs.opendatadiscovery.org/configuration-and-deployment/enable-security/authorization.md): ODD's RBAC model — permissions, policies, roles, owners, and user-owner association — centred on the user-identity / owner-identity bridge that resolves who-can-do-what. - [Policies](https://docs.opendatadiscovery.org/configuration-and-deployment/enable-security/authorization/policies.md): Policies are JSON-defined permission grants attached to owners through roles. Reference for policy structure, JSON Schema validation, resources, conditions, and the permissions a statement can grant. - [Permissions](https://docs.opendatadiscovery.org/configuration-and-deployment/enable-security/authorization/permissions.md): The five permission classes in ODD Platform — data entity, term, query example, lookup table, and management — with the full enumeration of permission keys and the surfaces each one gates. - [Roles](https://docs.opendatadiscovery.org/configuration-and-deployment/enable-security/authorization/roles.md): Roles bundle permissions. User roles (auth-chain-derived) versus Owner roles (operator-curated), and the precedence rule that resolves which wins for a given signed-in user. - [Owners](https://docs.opendatadiscovery.org/configuration-and-deployment/enable-security/authorization/owners.md): Owners are catalog-side data-steward identities, distinct from authenticated users. Reference for the Owner CRUD model, Owner roles, and the operator caveats around lifecycle and audit. - [User-owner association](https://docs.opendatadiscovery.org/configuration-and-deployment/enable-security/authorization/user-owner-association.md): Link a signed-in user to an Owner entity for owner-scoped permissions — three write-paths — self-request, self-request with auto-approve, and admin direct-bind. - [Admin promotion across providers](https://docs.opendatadiscovery.org/configuration-and-deployment/enable-security/admin-promotion.md): Single reference for ADMIN-promotion divergence across the four auth modes and the six OAuth2 provider sub-shapes — the matrix, the per-provider knobs that look the same but behave differently. - [Audit trail scope](https://docs.opendatadiscovery.org/configuration-and-deployment/enable-security/audit-trail-scope.md): ODD's bifurcated audit posture — what the platform records (activity feed + owner-association log), what it does not, and the compensating controls for SOX / HIPAA / GDPR / SOC2 reviews. - [Architectural Decision Log](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log.md): Architecture Decision Records for ODD Platform — the significant decisions the codebase embodies, reconstructed from the source with the code evidence to verify each one. - [ADR-0001: Contract-first HTTP layer](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0001-openapi-generated-controller-interfaces.md): ODD Platform's REST controllers are thin delegates over OpenAPI-generated interfaces — the HTTP contract lives in the spec, and routes change by regenerating it, not by editing controllers. - [ADR-0002: Centralised path-matcher authorization](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0002-centralised-path-matcher-authorization.md): ODD Platform centralises endpoint authorization in one path-matcher rule table — controllers carry no @PreAuthorize, so the entire access matrix lives in one auditable place. - [ADR-0004: GenAI ships disabled by default](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0004-genai-disabled-by-default.md): ODD Platform ships GenAI off by default — a runtime guard rejects requests until an operator sets genai.enabled and supplies the url and timeout, which have no working defaults. - [ADR-0007: Uniform reactive controller pipeline](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0007-uniform-reactive-controller-pipeline.md): ODD Platform's reactive controllers share one shape — methods return Mono\> via ResponseEntity::ok, and error translation is centralised in a single advice class. - [ADR-0008: OpenAPI tags scope the generated API interfaces](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0008-openapi-tag-per-resource-scoping.md): Every ODD Platform OpenAPI operation carries exactly one tag, and the generator emits one Java interface per tag — so a tag is the unit that shapes the generated \*Api interfaces. - [ADR-0012: Attachment storage backend is selected at boot](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0012-attachment-storage-backend-boot-selection.md): ODD Platform picks its attachment storage backend at boot from attachment.storage — LOCAL is the implicit default, REMOTE is S3/MinIO, and switching backends needs a restart. - [ADR-0018: Outbound-integration config is fail-fast at boot](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0018-fail-fast-outbound-config-at-boot.md): ODD Platform validates an outbound integration's config when its bean is built — a missing value fails startup, not the first message; an unconfigured channel is simply off. - [ADR-0019: Data Collaboration ships disabled by default](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0019-data-collaboration-disabled-by-default.md): ODD Platform ships Data Collaboration off by default — a conditional gates the whole controller on datacollaboration.enabled, so every route returns 404 until an operator opts in. - [ADR-0020: Outbound Slack delivery is decoupled via a Postgres queue](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0020-decoupled-outbound-slack-delivery.md): ODD Platform accepts a Slack message with 202, persists it, and delivers it from a background worker that holds a Postgres advisory lock — so delivery needs no message broker, only Postgres. - [ADR-0040: Notifications ship disabled by default behind one condition](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0040-notifications-disabled-by-default.md): ODD Platform ships notifications off by default — one Condition reads notifications.enabled and a single meta-annotation gates every component, so the whole subsystem turns on from one switch. - [ADR-0041: Notification channels activate by the presence of their keys](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0041-notification-per-channel-presence-activation.md): Each notification channel — Slack, webhook, email — turns on by the presence of its own config key; an unset key means no bean and no delivery, with no separate per-channel enable flag. - [ADR-0042: Notification fan-out is fail-soft per channel](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0042-notification-fail-soft-fan-out.md): When ODD Platform fans an alert out to its notification channels, a failure in one channel is logged and the rest still receive it — one broken channel never blocks the others. - [ADR-0043: The notification WAL consumer is a leader-elected singleton](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0043-notification-wal-single-leader.md): ODD Platform consumes the Postgres WAL for notifications from one thread on one replica, elected by a Postgres advisory lock — so a multi-replica deployment emits each alert once, with no broker. - [ADR-0044: Postgres replication artefacts are lazy-created, never dropped](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0044-postgres-artefact-lazy-create-no-drop.md): ODD Platform creates its notification replication slot and publication on first run if absent, but never drops them — cleanup is the operator's responsibility, by design. - [ADR-0021: Activity streams use cursor pagination](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0021-activity-stream-cursor-pagination.md): ODD Platform paginates its append-only activity streams by a (lastEventId, lastEventDateTime) cursor rather than offset/limit — list endpoints keep offset paging; the shape follows the data. - [ADR-0022: Activity view-modes are a single enum parameter](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0022-activity-view-modes-single-parameter.md): The activity feed selects its view (all / my objects / upstream / downstream) with one ActivityType enum parameter dispatched server-side, rather than a separate endpoint per view. - [ADR-0028: High-volume tables are range-partitioned ahead of need](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0028-range-partition-lifecycle.md): ODD Platform creates range partitions ahead of need — one job runs at boot (Postgres advisory lock) and nightly (ShedLock), making double-width partitions per high-volume table. - [ADR-0045: Housekeeping is a separate subsystem from partition management](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0045-housekeeping-partition-separation.md): ODD Platform separates TTL row-cleanup (housekeeping) from partition creation; the one bridging task, dropping empty partitions, lives in housekeeping but calls the partition service. - [ADR-0046: Housekeeping ships enabled by default (opt-out)](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0046-housekeeping-opt-out-by-default.md): ODD Platform ships data housekeeping on by default — it deletes aged rows out of the box, so bounded DB growth is the default posture and an operator must opt out to keep data indefinitely. - [ADR-0073: ODDRN is the universal identity for every entity](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0073-oddrn-universal-identity.md): Every entity carries a stable ODDRN string — the same ODDRN always means the same entity across ingests and producers, which is what makes idempotent ingestion and cross-system lineage possible. - [ADR-0071: PostgreSQL is the only required runtime dependency](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0071-postgres-only-runtime-dependency.md): ODD Platform needs no broker, ZooKeeper, or Redis — queuing, leader election, notifications, lineage, and full-text search are all built on PostgreSQL, the only required runtime dependency. - [ADR-0070: Ingestion is one wire contract shared by pull and push producers](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0070-pull-push-ingestion-contract.md): Pull collectors poll on a schedule, push adapters emit on the source's cadence; both speak one ODD Specification contract, and the platform processes every payload identically. - [ADR-0072: The platform is a contract-first, reactive, two-language stack](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0072-contract-first-reactive-stack.md): ODD Platform is a reactive Spring WebFlux + R2DBC backend and a React/TypeScript SPA, with one OpenAPI contract generating both the server interfaces and the browser client. - [ADR-0003: The catalog is read-collaborative — only mutations are permission-gated](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0003-read-collaborative-authorization.md): Once authenticated, any ODD user can read the whole catalog — entities, lineage, search, activity. Only mutations are permission-gated; reads are authenticated-only by design. - [ADR-0058: Deletion is soft — DELETED is a status, not a row removal](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0058-soft-delete-deletion-model.md): Deleting a data entity sets its status to DELETED, not removing the row; list and search hide it, the detail view still shows it, and housekeeping physically purges it after a TTL. - [ADR-0074: Authentication is a pluggable mode selected by auth.type, defaulting to DISABLED](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0074-pluggable-auth-modes.md): Auth is one of four modes set by auth.type (DISABLED, LOGIN\_FORM, OAUTH2, LDAP). It ships DISABLED, which is fully open — enable a real mode for any networked deployment. - [ADR-0075: Heavyweight features ship off by default; operational-hygiene jobs ship on](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0075-feature-gating-posture.md): Outbound features (GenAI, Data Collaboration, Notifications) ship disabled and need explicit wiring; housekeeping and other hygiene jobs ship enabled, keeping the database bounded. - [ADR-0076: In-context concept help is an information icon in a hover tooltip](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0076-inline-info-tooltip-affordance.md): Inline help for an ambiguous label is a small information (i) icon wrapped in a hover tooltip carrying a short explanation - the platform's one established affordance, reused rather than reinvented. - [ADR-0078: Editing a consequential field uses a change-preview confirmation that reduces into the store](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0078-confirm-and-store-reduce-field-edits.md): A field that drives downstream display or semantics (status, DQ severity) is edited via a change-preview confirmation that reduces the result into the store - never an optimistic instant save. - [ADR-0079: Ingestion authentication is one gate over /ingestion/\*\*, not per-route filters](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0079-ingestion-authentication-filter-coverage.md): When auth.ingestion.filter.enabled=true, a single WebFilter authenticates the whole /ingestion/\*\* surface against a registered collector/datasource token — replacing the two exact-path filters that le - [API Reference](https://docs.opendatadiscovery.org/developer-guides/api-reference.md): Canonical reference for the ODD Platform HTTP API — hub page with per-feature sub-pages plus the OpenAPI specifications and Swagger UI walkthrough that span the whole API. - [Alerts](https://docs.opendatadiscovery.org/developer-guides/api-reference/alerts.md): Alert HTTP endpoints — global tab listings, per-entity listings, status mutation, halt-notification configuration, and the inbound AlertManager webhook. - [Data Collaboration](https://docs.opendatadiscovery.org/developer-guides/api-reference/data-collaboration.md): Data Collaboration HTTP endpoints — outbound to the provider, per-entity threads & history, and the inbound Slack Events webhook. Gated by \`@ConditionalOnDataCollaboration\`. - [Directory](https://docs.opendatadiscovery.org/developer-guides/api-reference/directory.md): Directory HTTP endpoints — four \`GET\` calls under \`/api/directory\` backing the four-level drill-down (data source types → data sources → entity types → entities). - [GenAI](https://docs.opendatadiscovery.org/developer-guides/api-reference/genai.md): GenAI HTTP endpoint — proxy natural-language questions to an external AI service through the platform's \`POST /api/genai/ask\`. - [Glossary](https://docs.opendatadiscovery.org/developer-guides/api-reference/glossary.md): Business Glossary HTTP endpoints — term CRUD + lookup, term-side and resource-side linkage, faceted search, ownership and tags. - [Integrations](https://docs.opendatadiscovery.org/developer-guides/api-reference/integrations.md): Integration Wizard HTTP endpoints — list registered integrations and fetch their content blocks plus code snippets. - [Lineage](https://docs.opendatadiscovery.org/developer-guides/api-reference/lineage.md): Lineage HTTP endpoints — per-entity upstream / downstream graphs and group lineage, with \`lineage\_depth\` and \`expanded\_entity\_ids\` query parameters. - [Query Examples](https://docs.opendatadiscovery.org/developer-guides/api-reference/query-examples.md): Query Examples HTTP endpoints — CRUD, faceted search, and per-entity / per-term lookup and linking. 16 endpoints across three groups. - [Reference Data](https://docs.opendatadiscovery.org/developer-guides/api-reference/reference-data.md): Lookup Tables HTTP endpoints — Table CRUD, Column CRUD, Row CRUD, and faceted search. 16 endpoints under \`/api/referencedata/\`. - [Relationships](https://docs.opendatadiscovery.org/developer-guides/api-reference/relationships.md): Relationships HTTP endpoints — paginated list with type filter (ERD / GRAPH / ALL) plus per-type detail endpoints. - [How to contribute](https://docs.opendatadiscovery.org/developer-guides/how-to-contribute.md): Developer guide for contribution to the OpenDataDiscovery - [GitHub organization overview](https://docs.opendatadiscovery.org/developer-guides/github-organization-overview.md): Overview of all repositories inside of ODD GitHub organization - [Build and run](https://docs.opendatadiscovery.org/developer-guides/build-and-run.md): Build-and-run entry point for ODD developers — Platform backend + frontend, the ODD Collectors family, and the SDK path for authoring brand-new collectors / adapters. - [Build and run ODD Platform](https://docs.opendatadiscovery.org/developer-guides/build-and-run/build-and-run-odd-platform.md): Developer guide on how to build and run ODD Platform backend and frontend - [Build and run ODD Collectors](https://docs.opendatadiscovery.org/developer-guides/build-and-run/build-and-run-odd-collectors.md): Developer guide on how to build and run ODD Collectors - [Build a custom collector](https://docs.opendatadiscovery.org/developer-guides/build-and-run/custom-collectors.md): Build a custom ODD collector or adapter against the odd-collector-sdk.