Qu’est-ce qu’OpenDome ?

OpenDome est une plateforme de données open-core pour les équipes qui doivent mettre leurs données structurées et non structurées derrière une interface unique, gouvernée et interrogeable — sans les céder à un tiers.

Vous faites tourner une cellule : un namespace Kubernetes par tenant, autonome, qui héberge votre lakehouse (Iceberg + Lance), vos pipelines et le moteur de consommation. Tout ce qui lit des données passe par une seule surface — la OpenDome Semantic Layer (OSL).

La règle unique : OSL est la seule couche de consommation

Les données structurées, les non structurées, les métriques, les entités et le langage naturel se consomment exclusivement à travers OSL. Trino, Lance et dbt sont des moteurs internes : ils n’exposent jamais d’endpoint public. Aucun consommateur ne parle directement à Trino.

Pourquoi c’est important

Si un consommateur peut atteindre la donnée sans passer par OSL, c’est un bug d’architecture — cela contourne le point d’application des politiques et la chaîne d’audit. Une seule porte signifie un seul endroit où gouverner, un seul endroit où auditer, un seul endroit où faire évoluer le modèle.

Deux plans, une spec

OSL décrit un modèle sémantique qui couvre deux substrats physiques avec un seul langage déclaratif en YAML :

Plan structuré

Tables Iceberg via Trino. Entités, métriques, dimensions, contrats de données. Ici OSL est un superset de dbt MetricFlow — tout projet MetricFlow valide est un OSL valide.

Plan non structuré

Collections Lance via LanceDB. Chunk schema, embeddings, retrieval hybride (vector + BM25 + filtres de metadata), ACL row-level. C’est l’extension OSL-only.

Le pont entre les deux est la JointEntity : un objet logique (Customer, Policy, Order) dont la clé primaire vient d’un modèle structuré et qui expose des attributs tirés des deux plans. Un appel, une décision de politique, une trace d’audit. Voir Concepts pour le modèle complet.

Ce que vous obtenez d’office (OSS)

La distribution Apache-2.0 contient tout le nécessaire pour faire tourner et consommer une cellule sur votre propre infrastructure :

• Le data plane de la cellule — des charts Helm pour un tenant autonome et standalone.
• Le moteur OSL (tenant-semantic-api) servant les 13 endpoints /osl/*.
• Des connecteurs (taps Singer/Meltano : Postgres, MySQL, Salesforce, custom).
• L’embedder et le retrieval adossé à Lance.
• L’évaluation des politiques (SQL allowlist, row filters, projection) — fail-closed.
• La spécification OSL, les JSON Schemas et un exemple travaillé.

OSS vs EnterpriseCe qui est Apache-2.0 aujourd’hui, et ce qu’ajoute le tier géré/Enterprise — la console, le control-plane, les packs verticaux et compliance.

À qui cela s’adresse

• Adopters (une équipe data cliente) — modélisez votre domaine en OSL, connectez des sources, servez des métriques et du retrieval gouvernés. Commencez par Concepts puis le Quickstart.
• Agent authors — construisez des agents contre les tools MCP et la REST d’OSL. Voir la référence de l’API.
• Spec implementers — construisez un moteur OSL-conforme. Voir Spec & gouvernance.

Étape suivante

Quickstart (auto-hébergé)Mettez en route une cellule sur kind/Kubernetes sans control-plane, émettez un token et faites votre premier appel gouverné.