Cos'è OpenDome?

OpenDome è una piattaforma dati open-core per i team che hanno bisogno di mettere i propri dati strutturati e non strutturati dietro un’unica interfaccia governata e interrogabile — senza cederli a terzi.

Esegui una cella: un namespace di Kubernetes per-tenant, autocontenuto, che ospita il tuo lakehouse (Iceberg + Lance), le tue pipeline e il motore di consumo. Tutto ciò che legge i dati passa per un’unica superficie — la OpenDome Semantic Layer (OSL).

L’unica regola: OSL è il solo strato di consumo

I dati strutturati, quelli non strutturati, le metriche, le entità e il linguaggio naturale si consumano esclusivamente attraverso OSL. Trino, Lance e dbt sono motori interni: non espongono mai un endpoint pubblico. Nessun consumatore parla con Trino direttamente.

Perché è importante

Se un consumatore può raggiungere il dato senza passare per OSL, è un bug di architettura — scavalca il punto di applicazione delle policy e la catena di audit. Una sola porta significa un solo punto dove governare, un solo punto dove fare audit, un solo punto dove far evolvere il modello.

Due piani, una spec

OSL descrive un modello semantico che abbraccia due substrati fisici con un solo linguaggio dichiarativo in YAML:

Piano strutturato

Tabelle Iceberg via Trino. Entità, metriche, dimensioni, contratti di dati. Qui OSL è un superset di dbt MetricFlow — qualsiasi progetto MetricFlow valido è OSL valido.

Piano non strutturato

Collezioni Lance via LanceDB. Chunk schema, embedding, retrieval ibrido (vector + BM25 + filtri di metadata), ACL row-level. È l’estensione OSL-only.

Il ponte tra i due è la JointEntity: un oggetto logico (Customer, Policy, Order) la cui chiave primaria proviene da un modello strutturato e che espone attributi tratti da entrambi i piani. Una chiamata, una decisione di policy, una traccia di audit. Vedi Concetti per il modello completo.

Cosa ottieni di serie (OSS)

La distribuzione Apache-2.0 è tutto il necessario per eseguire e consumare una cella sulla tua infrastruttura:

• Il data plane della cella — chart Helm per un tenant autocontenuto e standalone.
• Il motore OSL (tenant-semantic-api) che serve i 13 endpoint /osl/*.
• Connettori (tap Singer/Meltano: Postgres, MySQL, Salesforce, custom).
• L’embedder e il retrieval su Lance.
• Valutazione delle policy (SQL allowlist, row filters, projection) — fail-closed.
• La specifica OSL, i JSON Schema e un esempio pratico.

OSS vs EnterpriseCos'è Apache-2.0 oggi e cosa aggiunge il tier gestito/Enterprise — la console, il control-plane, i pack verticali e il compliance.

A chi si rivolge

• Adopter (il team dati del cliente) — modella il tuo dominio in OSL, connetti le sorgenti, servi metriche e retrieval governati. Inizia da Concetti e poi il Quickstart.
• Agent author — costruisci agenti contro i tool MCP e la REST di OSL. Vedi il riferimento API.
• Spec implementer — costruisci un motore OSL-conforme. Vedi Spec e governance.

Prossimo passo

Quickstart (self-hosted)Avvia una cella su kind/Kubernetes senza control-plane, emetti un token e fai la tua prima chiamata governata.