Your data is your asset.
Not your engine vendor’s.
Technology leaders tell us the same thing: the data must stay the company’s own asset, not be bound to whichever engine processes it today. That is what we mean by data sovereigntyhere — your data in your storage, in an open format, with the governance held in your own tables, so that engines are replaceable. Open table formats freed the files. The governance— lineage, quality evidence, ownership — still lives inside each engine. DATAP.AI is the layer that carries it across. We proved it on our own environment: three engines, two clouds, one column-level lineage.
The problem: data is still coupled to the engine
Your asset is bound to someone else’s engine
Adding an engine, or leaving one, turns into a migration. So the choice gets made once, under pressure, and lived with for a decade — and the vendor knows it at every renewal.
Open files solved half of it
Apache Iceberg freed the files. Lineage, quality rules and ownership evidence stayed inside each engine, so the audit trail stops at every engine boundary — exactly where an auditor looks hardest.
Sovereignty has to be evidenced, not asserted
Boards and regulators ask where the data lives, who controls it and whether you could leave a provider. Those answers need to come from your own records, not from a vendor’s console.
Where the standard tools stopped, and what DATAP.AI adds
From our own build. The engines and dbt-core did their jobs well; this is the part none of them is designed to do, because each one looks after its own side.
| The question | Out of the box, in our build | With the DATAP.AI layer |
|---|---|---|
| Where did this number come from, across engines? | Each engine, and each dbt target, showed its own part. Three separate graphs; the path stopped at every engine boundary. | One column-level path across all three engines, back to the raw source. |
| Where is the evidence kept? | In each tool’s own catalog and screens. | In plain tables in your own database. One SQL view lists every column that crossed an engine. |
| Is this lineage of real tables, or of code? | Not distinguished. | Every table is marked built or not built, so a picture cannot claim what has not run. |
| How long to connect the engines safely? | Several days of catalog, role and trust configuration, with the traps in the full note. | Repeatable kits that render the exact policies and statements for an environment; your own admins apply them. |
The same layer also generates the pipelines, their tests and a personal-data map on a single engine — see Data Governance. Carrying personal-data flags across the engine boundary is on our roadmap and is not part of this build.
The proof
The same dbt-core models run on three engines through three catalogs. The shared tables and marts exist once, as Iceberg files in one bucket of object storage the customer owns (S3 in our build; the format is the same on Azure Data Lake Storage or Google Cloud Storage). One lineage spans all of it. We built this first as a single dbt project, the simplest shape for a demonstration, then again as three repositories owned by three teams. Same lineage, same numbers. The multi-team build →
A value computed on Databricks matched an independent calculation in Snowflake to six decimals. Correctness checks on sample data in our demo environment, 22 September 2026. Not a benchmark.
See it live
Click any column. Its provenance lights up in both directions, across every engine it passes through.
What it means for the business
The data stays your asset
Files in an open format in your storage, governance in a layer that belongs to no engine. Where a workload runs becomes a choice you can revisit as prices and needs change — including at renewal time.
Sovereignty you can show
Your storage, your cloud and region, and the lineage held in your own tables. One answer to “where did this come from”, however many engines the data passed through.
A position each engine vendor is unlikely to take
Every engine’s tooling naturally centres on that engine. A layer that belongs to none of them can follow data across all of them. That is where DATAP.AI sits.
Then the same for AI: AI sovereignty
Decoupling data from the engine is the first half. The second is decoupling AI from the model provider: models you choose, running in your own cloud and region, answering only from data whose lineage and classification you hold.
The governed tables in this build are the foundation for that. The AI layer on top of them is not part of this demonstration; it is what we add next. How our AI governance works →
Three things we learned
Rebuild versus merge
A table that is dropped and re-created got a new Iceberg identity each run, and our downstream engine quietly stopped refreshing. Shared tables are now merge models.
The catalog matters as much as the files
Open files were not enough for us. Which catalog owns a table decided which engines could find it.
A green build is not a correct table
One model built, passed its tests and held zero rows. We now test meaning, not only shape.
What this does not show
It is a demonstration on sample data and small compute, not a production reference or a benchmark. It runs on public cloud services: questions of legal jurisdiction, encryption-key control and who operates the platform are separate, and this build does not address them. Not every engine read every file directly: Databricks read the Snowflake-produced tables from the Iceberg files, and the Athena-produced tables through Snowflake. Cross-cloud reads cost money and time. Lineage covers what runs through the project.
Apache Iceberg is a trademark of The Apache Software Foundation. dbt is a trademark of dbt Labs. Amazon Athena, AWS Glue and Amazon S3 are trademarks of Amazon.com, Inc. or its affiliates. Snowflake is a trademark of Snowflake Inc. Databricks and Unity Catalog are trademarks of Databricks, Inc. Microsoft Azure is a trademark of Microsoft. DATAP.AI is not affiliated with, endorsed by or sponsored by any of them. Product behaviour described here is what we observed in our own configuration in September 2026 and may differ in yours or change over time.