Open Data Infrastructure
Open Data Infrastructure Policy Portability Tests
How buyers can test whether row rules, masking policy, roles, ownership, lineage, and audit evidence move across platform boundaries.
Policy portability is easy to claim and painful to prove.
Portability has to include policy
Open data infrastructure buyers usually test data portability first. Can the data move? Can another engine read it? Can storage stay under customer control? Those are necessary questions, but they are not enough.
The harder test is whether policy moves with meaning intact. Row rules, masking policy, roles, ownership, lineage, consent, approval evidence, and audit logs are part of the practical data product. If those controls cannot move, the data is portable only in the narrowest sense.
Core idea: A platform is not ODI-ready until policy, ownership, lineage, and audit evidence can move with the data.
Policy systems need exportable evidence
The Open Policy Agent documentation shows policy-as-code patterns outside a single data platform. OpenLineage documentation and OpenMetadata documentation show why lineage and metadata need portable representations.
A buyer test should ask the vendor to prove how policy leaves the platform, how it maps into another enforcement point, and what evidence survives. Slideware does not count. A sample export, translated rule, replayed decision, and lineage record count.
Patterns that work
- Test row filters, masking rules, roles, ownership, and lineage export together.
- Ask vendors to translate sample policies into an external enforcement model.
- Replay allow and deny decisions after policy migration.
- Require audit evidence that names policy version, identity, data object, and decision.
- Score policy portability separately from data-format portability.
For adjacent ODI context, read ODI procurement scorecards, vendor portability tests, and policy enforcement in open data systems.
What breaks first
- The data exports cleanly, but row and masking rules remain trapped in a proprietary model.
- Role names move without the ownership context that made them meaningful.
- Lineage export stops at tables and drops policy decisions.
- Audit logs are available in the old platform but cannot be replayed in the new one.
Questions to ask
- Which policies can be exported in a documented format?
- Can allow and deny decisions be replayed after migration?
- What lineage and audit evidence moves with the data product?
- Which controls have to be rebuilt manually after platform exit?
Sources to start with
These primary sources anchor the technical claims in this guide.
If policy cannot move, the data has not really escaped.