Data products only deliver value when specifications translate into reliable, usable products. This is the challenge Entropy Data aims to address. The vendor combines data contracts, semantics, a data product marketplace, and access processes. The individual components are not new. What is new is how Entropy Data combines them and makes the resulting context available to people as well as coding agents.
Entropy Data is a standards-based, platform-independent data product marketplace for companies that have already established data products as an operating model and now want to operationalize and scale them for people and AI agents.
Who Is Entropy Data?
Entropy Data is a spin-off of IT consultancy INNOQ. The product has been available since 2023, while Entropy Data has operated as an independent company for about a year. Entropy Data has six employees and 13 paying customers across eight countries, including Kuehne+Nagel, GEODIS, and DKB. With approximately one million euros in recurring license revenue, the company is small but, according to its own figures, profitable and growing organically.
Its open-source strategy creates visibility: the Data Contract CLI is downloaded about one million times per month. This is complemented by more than 1,000 GitHub stars for ODCS and the CLI, as well as several thousand pulls of the Community Edition. This does not yet prove broad enterprise adoption, but it is a strong signal of interest in the topic.
What Does the Platform Actually Offer?
Entropy Data describes itself as a Data Product Marketplace. The label is accurate, but the offering goes further than marketplaces that merely list data products. Entropy Data manages data products and contracts, makes them discoverable, organizes access requests, and can use events to trigger permission provisioning in connected data platforms.
Portfolio overview: The core product is called Entropy Data (formerly Data Mesh Manager and Data Contract Manager) and is divided into three functional areas.
- The Marketplace supports discovery, access requests, and approvals.
- In the Studio, data product owners create and manage their data products and data contracts.
- Governance brings together policies, compliance checks, and responsibilities.
In addition, Semantics represents business concepts, metrics, and relationships as a shared ontology. The Data Product Builder provides coding agents with the context needed to implement new products. The platform is complemented by the standalone open-source component Data Contract CLI, which tests contracts and integrates them into development and CI/CD workflows, as well as the Data Contract Editor for editing data contracts.
Entropy Data is primarily built for data product owners: they describe, create, publish, and take responsibility for products. On the consumption side, the platform addresses two target groups. Human users should be able to find, understand, and request data products, while AI agents can consume the same standardized, semantically enriched context in machine-readable form. The platform therefore supports both human-ready data and AI-ready data.
The underlying data remains in platforms such as Snowflake and Databricks, while transformation workloads can continue to run through tools such as dbt. Entropy Data provides a lightweight metadata layer and a unified access and control layer above them. The application can be operated as software as a service (SaaS) or self-hosted. This is particularly relevant for companies that use several data platforms, want to retain sovereignty over their metadata, and do not want to become fully dependent on a platform vendor’s proprietary model.
Entropy Data therefore competes less with traditional data catalogs and more with platform-native offerings from Databricks and Snowflake, as well as custom-built solutions. Compared with these offerings, the strongest differentiation lies in consistent support for open standards and platform independence.
How Does Product Creation Work?
The Open Data Contract Standard (ODCS) and Open Data Product Standard (ODPS) are central to the approach. Among other things, ODCS describes schemas, quality requirements, service-level agreements (SLAs), and terms of use, while ODPS structures the data product. Entropy Data uses these standards as exchange formats and as the foundation for its marketplace and automation.

The underlying semantics are not simply assumed to exist; they can be built and maintained in Entropy Data Semantics. Data product owners and subject-matter experts model company-specific entities, attributes, metrics, and relationships through the user interface or as YAML. They can begin with their own ontology or import existing industry ontologies and Resource Description Framework and Web Ontology Language (RDF/OWL) models.
On this basis, a data product can be modeled in two ways. In the semantic-first approach, the owner selects entities and attributes from the ontology maintained in Entropy Data. Business definitions and classifications are transferred into the contract. In the reuse-first approach, the owner uses tables, fields, or output ports from existing data products as inputs for a new product.

The coding agent works with four layers of context: ontology, data contract, skills, and marketplace. The ontology provides the business meaning, the contract describes the desired product and its requirements, the customer-specific skill codifies the technical implementation requirements, and the marketplace provides existing data products and access options. On this basis, the agent identifies suitable inputs, requests access, generates implementation artifacts such as dbt transformation logic, and reports lineage and implementation details back to the platform.
The completed data product is published and can in turn serve as an input for further products.
Control and Governance
Policies, the Data Product Score, data-quality tests, and drift detection support the lifecycle. Quality rules are defined in the contract and executed in the target environment, for example through the Data Contract CLI. Entropy Data aggregates and visualizes the results, but does not have its own data profiler. Breaking changes are handled through new output ports and a migration period.
The patent-pending Purpose-Based Access Control is particularly interesting. It checks whether a query is consistent with the agreed purpose of use and the conditions of the contract. An AI-based control can stop a SQL query in the execution path and is also intended to identify critical results, such as possible re-identification caused by very small result sets. The approach extends conventional access controls, but its reliability, auditability, and scalability still need to be proven across a broader range of production environments.
Who Should Consider Entropy Data?
The best fit is larger companies with multiple data platforms that are looking for an independent marketplace and a standardized metadata layer. The platform may also suit smaller teams that already work consistently with data products and data contracts.
Successful adoption requires clearly assigned and capable data product owners, an established product mindset, and a commitment to maintaining contracts and semantic models over time. Entropy Data supports owners technically with standardized models, inherited definitions, policies, scores, lineage, drift detection, and coding agents.
However, as with many other solutions, it assumes the necessary operating model and subject-matter accountability are already in place. The vendor’s methodology, enablement resources, and network of experienced implementation partners are still developing.
My Assessment
Entropy Data’s strongest aspect is the consistent combination of open standards and platform independence. ODCS and ODPS are not used merely for import and export; they underpin the product model. This is a compelling position between proprietary data platforms and custom-built solutions, particularly for companies that want to retain control over their metadata.
The agentic approach to product creation is also coherent. Ontology, contract, skills, and marketplace establish a business and technical framework within which the coding agent generates implementation artifacts. This goes beyond generic code generation. I find it particularly relevant that the same context serves two target groups: people receive understandable and reliable data products, while AI agents can process the standardized and semantically enriched information in machine-readable form.
The approach depends on the data product owners. Entropy Data does not follow a centralized governance model; instead, it equips decentralized owners with standardized contracts, inherited definitions and classifications, policies, scores, lineage, drift detection, and coding agents. This is consistent: responsibility remains where the domain knowledge resides, and the technical support is substantial.
However, the solution does not remove decisions and accountability from the owners. They must understand the data, semantics, quality rules, changes, and access, and they must use the provided capabilities consistently. Without this competence or discipline, even good user interfaces and AI agents will not produce a reliable data product. The ontology is both the greatest value lever and a potential bottleneck; AI can make its maintenance easier, but it replaces neither the operating model nor business alignment.
I still see room for development in governance. Many of the current controls provide information, assessments, or notifications. Policies generate guidance and scores, but do not consistently block actions. Multi-stage approvals, mandatory gates, exceptions, and cross-platform enforcement are not yet comprehensively developed. For a young vendor, focusing on core capabilities is understandable. However, anyone seeking to scale across many data products must automate control.
Entropy Data is therefore clearly a Data Product Marketplace today, but not yet a comprehensive Control Plane. The product’s strategic direction is clear. The key question is whether Entropy Data can add stronger governance enforcement, support more technology stacks out of the box, and build a partner ecosystem that helps customers develop semantic models and implementation skills.
My conclusion: Entropy Data is particularly worth considering for companies experienced with data products that prioritize open standards, platform independence, and metadata sovereignty, and that have owners capable of actively fulfilling their responsibilities. The solution supports these owners with a well-designed mechanism and a forward-looking agentic extension, but it does not replace their subject-matter expertise and discipline. The vision of a control plane is plausible. Delivering on it will require stronger policy enforcement, broader evidence from production deployments, and capable data product owners.