Quickstart
Avvia una cella che serve l’API OSL sul tuo Kubernetes — senza
control-plane, senza phone-home. Token reale e chiamata reale a /osl/retrieve
in pochi minuti. Inizia →
Strutturati e non strutturati, consumati attraverso un'unica spec aperta — verificabile, self-hosted, senza lock-in.
01—Inizia qui
Avvia una cella che serve l’API OSL sul tuo Kubernetes — senza
control-plane, senza phone-home. Token reale e chiamata reale a /osl/retrieve
in pochi minuti. Inizia →
Il modello mentale: due piani fisici (Iceberg + Lance), una spec dichiarativa, “tutto è una Entity” e il loop compile → serve. Leggi i concetti →
I 13 endpoint /osl/* su cui ogni client può contare — query, retrieve,
resolve, domain-map, traverse, sample. Esplora l’API →
Cosa viene rilasciato oggi sotto Apache-2.0 e cosa aggiunge il tier gestito/Enterprise — in modo chiaro, in un unico posto. Confronta le edizioni →
02—Perché OpenDome
OpenDome è una piattaforma dati open-core. Un self-hoster esegue una cella — un namespace per-tenant, autocontenuto — e consuma tutto attraverso la OpenDome Semantic Layer (OSL): un’unica spec aperta che abbraccia tabelle strutturate (Iceberg, via Trino) e collezioni non strutturate (Lance, vettoriale
Trino, Lance e dbt sono motori interni senza endpoint pubblico. Ogni consumatore — BI, script, agenti — parla OSL. Se si può raggiungere il dato senza passare per OSL, è un bug di architettura.
Il piano strutturato è 100% dbt MetricFlow. Se te ne vai, i tuoi
semantic_models/*.yml restano validi in dbt-sl, senza toccare nulla.
Solo le primitive Lance sono OSL-only.
Ogni query, ogni retrieval e ogni decisione di policy è applicata server-side ed emessa come evento di lineage. La PII è dichiarata nel connettore e oscurata nella cella — mai inferita nella UI.
Lo stesso modello è esposto come tool MCP per gli agenti e come REST per le app.
Questa documentazione pubblica un llms.txt per i crawler di IA.