Analysis updated 2026-05-18
Catch breaking schema changes in a data pipeline before they reach production dashboards.
Enforce that a data product's PII flags stay consistent with its schema fields.
Require producers to publish a new major version and deprecation window for breaking changes.
Check that data products conform to a shared enterprise data model.
| open-dpm/dpm | 0311119/free_registertool | 18597990650-lab/multi-agent-game | |
|---|---|---|---|
| Stars | 24 | 24 | 24 |
| Language | Python | Python | Python |
| Setup difficulty | moderate | hard | moderate |
| Complexity | 4/5 | 4/5 | 3/5 |
| Audience | data | developer | developer |
Figures from each repo's GitHub metadata at analysis time.
Requires setting up a Python virtual environment and integrating the CLI into GitLab CI or GitHub Actions.
DPM stands for Data Product Manifest, an open source toolkit that treats a company's data products the way software teams treat code. Instead of a database schema, its meaning, and who owns it living only as informal team knowledge, DPM stores all of that as versioned files in a Git repository, and checks those files automatically in continuous integration whenever something changes. The problem it addresses is common in data teams: someone renames or removes a column, and overnight several dashboards or a machine learning pipeline quietly break because nobody was warned. With DPM, a producer's change goes through a merge request, and DPM checks in CI whether the manifest is complete, whether it follows quality and governance rules, and whether the change would break existing consumers. A backward compatible change merges normally, but a breaking change cannot simply replace the old version. Instead the producer must publish a new major version of the manifest alongside the old one, mark the old version as deprecated, and give consumers a defined window to migrate before the old version is retired. Privacy and access details also live in the manifest rather than being an afterthought. Each schema field can be flagged as containing personal information, and DPM checks that this flag stays consistent with the product's overall privacy metadata, failing the pipeline if they disagree. The manifest can also document how data is accessed, such as through a specific authentication method at an API gateway, though DPM itself only versions and reviews that description rather than enforcing it at runtime. Beyond individual contracts, products can optionally conform to a shared Enterprise Data Model, a central registry defining business entities like Customer or Order and their required attributes. DPM can then render a graph showing which data products conform to which canonical entities. The project includes a command line tool with commands to validate manifests, detect breaking changes, suggest version bumps, check governance rules, and render this conformance graph, and it ships integration guides for both GitLab CI and GitHub Actions.
An open-source toolkit that treats data product schemas, ownership, and rules as versioned files checked automatically in CI, like code.
Mainly Python. The stack also includes Python, YAML, Avro.
AGPL-3.0 licensed, meaning modified versions used over a network must also make their source code available.
Setup difficulty is rated moderate, with roughly 30min to a first successful run.
Mainly data.
This repo across BitVibe Labs
Verify against the repo before relying on details.