Governed Data Sharing With Open Table Formats

Open table formats make sharing technically easier. They do not decide whether the sharing is governed, explainable, or reversible.

The practical problem

Data sharing used to mean exports, SFTP folders, warehouse shares, clean rooms, or vendor-specific exchanges. Open table formats add a different option: share data through portable table contracts that more engines can understand.

That is useful. It is also incomplete. Governed sharing needs policy, consent, identity, lineage, audit, retention, and consumer boundaries. A table snapshot without those controls is just a faster way to distribute risk.

The ODI boundary

The table format defines the shared table state. The catalog defines how consumers discover and access it. Policy defines what each consumer can do. Lineage and audit explain how the data moved and which rules applied.

ODI matters because those contracts should not be trapped in one sharing product. If the table is open but the sharing policy, identity mapping, and audit trail are closed, the organization still has limited control.

Patterns that work

Share governed views, not raw entitlement to everything in a table. A partner, internal team, clean-room workflow, or AI application may need a subset with masked fields, row filters, purpose limits, and time windows.

Use snapshots for reproducibility. If a consumer sees a dataset on Monday and makes a decision on Tuesday, the team should know which table state was used. That matters for audits and disputes.

Attach obligations to the contract. Data use restrictions, retention limits, onward-sharing limits, and deletion requirements should be represented in systems, not only in a contract PDF nobody reads at runtime.

Failure modes

The first failure is assuming open equals shareable. Some data should be portable and still tightly restricted.

The second failure is snapshot ambiguity. A consumer says "the table was wrong," and nobody knows which version they saw.

The third failure is policy split-brain. The catalog allows access, the clean room applies different rules, and the downstream tool keeps a copy beyond the allowed retention window.

Questions to ask

• What exactly is shared: raw table, governed view, snapshot, or derived data product?
• Which policy decides rows, columns, masking, purpose, and retention?
• Can every shared result be traced to source tables and snapshots?
• Can access be revoked or narrowed without breaking unrelated workloads?
• Can consumers use their own engines without bypassing governance?

For adjacent governance topics, read Governance Is Infrastructure, Access Control in ODI, and ODI for Customer 360.

Sources to start with

Start with the primary docs. They are the contracts you can test against, not commentary about the contracts.

• Apache Iceberg table specification
• Apache Iceberg REST Catalog specification
• OpenLineage documentation
• Open Policy Agent documentation
• NIST Privacy Framework