From governed metadata to trusted, consumable data products: Technical solution brief

Systems store data. Businesses need answers.

Data systems store data in physical terms — schemas, tables, columns, pipelines — while businesses define and talk about data in conceptual terms: Customer, Transaction, KYC, Financial Crime. That mismatch creates friction at every level.

For human analysts, navigating this gap is time-consuming. Finding the right data means traversing dozens of data catalog entries, inferring which of several tables represents the authoritative “Customer,” and applying judgment about quality and fitness for purpose, often without enough context to be confident. 

For AI agents and automated pipelines it gets worse. They scale whatever they are given as they cannot reliably distinguish between the right table from the wrong one, fresh data from stale, a canonical source from a shadow copy. The absence of business meaning and context at the data layer is not a governance inconvenience; it is a blocker for AI-native architectures and AI-driven workflows.

Ataccama data products: Governed data, ready to use

A data product is not a new copy of your data and it is not another table. It is a reusable package built on your data and context, ready to be consumed under a clear contract of ownership, quality, and trust, and exposed via APIs for applications, AI tools and teams.

A data product packages data with everything a consumer would otherwise have to reconstruct on their own: a contract that states what the data promises, the business context that explains what it means, the quality signals that show whether it holds up to the standards, and the ownership and criticality that say who stands behind it and how much it matters.

The data itself never moves. Your sources — Snowflake, Oracle, PostgreSQL, Databricks, S3 — stay the system of record, and the product points to the authoritative copy instead of spawning another one. What gets added is the layer of trust.

That layer is the difference between data you can find and data you can act on. Without it, every consumer repeats the same work — tracing lineage, second-guessing freshness, hunting for an owner — before they can rely on what they pulled. With it, that work is done once, travels with the data, and is inherited by everyone downstream. Trust stops being something each team re-establishes and becomes a property of the data product itself — which is what lets governance accelerate consumption instead of gating it, and makes trusted data the default input to every analytics, BI, and AI workflow.

How Ataccama connects the data product to the data

Ataccama keeps the business meaning and the physical reality cleanly separated but always linked. A data product is defined once as a business concept — Customer, Transaction, Risk Exposure — independent of where the data physically lives. That definition is then linked to one or more physical implementations across your platforms, with one flagged as the recommended asset for consumers.

Everything Ataccama already does at the physical level — automated metadata harvesting, profiling, classification, DQ monitors, lineage, ownership, and versioning — flows up into the data product through that link. The result is a logical concept consumers can reason about, anchored to a physical source they can trust, without anyone needing to know a schema to use it.

Inside a data product

That link between business meaning and physical reality lives inside a single governance object: the data product itself. It is the shell that holds everything which makes “Customer” more than a label — its data elements, its domain, its steward, the business process it serves, and the contract its data is expected to meet — while staying independent of where that data physically sits.

• Use case, status, and stewardship define what the data product is for, where it sits in its certification lifecycle (e.g. In Progress, Managed/Certified, Deprecated), and who owns it. Stewardship is assigned to a group, not an individual, so ownership survives personnel changes.
• Business domain and business processes anchor the data product organizationally. Business domains scope it within the enterprise (Customer, Risk, Asset); business processes link it to the workflows that produce or consume it, and are the primary source of criticality propagation.
• Criticality starts at the business process and propagates automatically through the model: mark KYC as critical, and that criticality flows down to linked data elements, through to the physical attributes and tables that contain them, and up to any data product associated with those elements. CDE lists become derived rather than curated, coverage reporting becomes a query, and governance prioritization reflects actual business decisions rather than manual flags.
• Data elements contain the logical attributes the product is expected to contain — Customer ID, Email Address, Citizen ID Number — declared independently of physical column names. Whether the recommended physical asset actually delivers on this contract is an answerable question: a compliance indicator surfaces the gap between logical expectation and physical reality, including whether DQ rules are in place for critical elements.
• Linked catalog items connect the data product to one or more physical implementations, with one marked as recommended. The recommended asset is the linchpin: it is what consumers are directed to, what the Data Trust Index is anchored to, and what DQ aggregation is computed from. 
• Data Trust Index surfaces from the recommended physical asset once it is linked. The Data Trust Index calculates a weighted trust score across data quality, ownership completeness, and data context, giving every consumer an explainable breakdown of exactly why a data product scores the way it does. 

What makes this different

1. Context-first data products for people: Data is only useful when people understand it. Ataccama puts business context and trust at the center of every data product so teams can instantly see whether data is trustworthy right now, not just technically valid.
2. Agentic data trust for AI workflows: Ataccama exposes trusted data products as a context system for AI tools and agentic workflows, so AI outputs are based on consistent, governed data instead of fragmented or ambiguous inputs.
3. Operationalized data value connected to real usage: Ataccama connects governed data products directly to the tools and workflows where decisions happen, turning governance from a documentation exercise into a driver of adoption and business outcomes.

Who this is built for

• Data stewards get a single workspace for all stewardship activity: term assignment, criticality, status, contract declaration, recommended asset designation, and trust monitoring — on one screen, directly from a catalog item.
• Data consumers A consumer arrives at a logical concept — Customer Master Data — not at a table. They see what the data is, who owns it, how critical it is, what it is expected to contain, which physical asset is recommended, active alerts, and the Data Trust Index — everything needed to decide whether this data is safe to use for their purpose, without needing to know a schema. 
• CDOs and data leaders get enterprise-wide consistency in how critical data is defined and governed, regardless of system sprawl. Governance investments reach beyond the catalog — into the analytics and AI workflows where work actually happens. Trusted data access extends to the entire organization, not just teams with direct platform access. Coverage and KPIs fall out of the model directly, as queries and filters, not custom reports.
• AI agents and orchestration systems query a structured, explicit model: concept identity, recommended asset pointer, trust score, criticality, governance lineage — all available as structured inputs to agentic pipelines without requiring the agent to navigate physical schemas. The same metadata is exposed via API today and via MCP in upcoming releases.