Data Products: bundles, contracts, and asset registration¶

A Data Product is a curated, named, owned bundle of registered assets — and the way a metric, term, process, connection or alert rule reaches a Data Contract.

A Data Product wraps the metrics, catalog assets, glossary terms, processes, connections, and alert rules that make up one capability into a single governable noun — you set its owner, domain, and lifecycle once, then govern it at the contract layer.

Contracts attach toData Products · approved tables

Source types9 · polymorphic

Bundle1 product → N assets · shared

Lifecycle5 states · approval-gated

When to choose this¶

Describe a capability that spans assets

Customer 360 = 4 metrics (mrr, arr, churn_rate, nps) + 2 catalog assets (customers, subscriptions) + 1 glossary term (Customer). The product is the single noun; the bundle is what's inside.
Put an asset on a Data Contract

To govern a metric, term, process, connection, or alert rule at the contract layer, wrap it in a product first. A published catalog asset or a harvested table can also go on a contract directly: the contract links them directly.
Own and lifecycle a set at once

A product carries one owner team, one status, one domain, and one product type. The bundled assets keep their own owners and lifecycles; the product is what stewards reach for.
Answer "what does this team ship?"

Consumers find one Data Product instead of chasing four metrics and two tables. If an asset is the answer to that question, it belongs in a product.

When you don't need a Data Product

A one-off, ad-hoc query against the warehouse.
A glossary term nobody outside your team consumes — leave it in the glossary and promote it later if it earns an audience.
An asset that will never go on a contract and is never the answer to "what does this team ship?"

How a Data Product bundles assets¶

A Data Product is a 1-to-many bridge: it wraps any number of underlying assets, and a Data Contract attaches to the product rather than to the assets. That indirection is the point: a metric, term or process reaches a contract only as part of a product. (The tables and catalog assets a contract is about are the exception; the contract links them directly.)

flowchart LR
    DP(["Data Product<br/>owned · named · one lifecycle"])
    M["Metric<br/>e.g. mrr"] --> DP
    C["Catalog asset<br/>e.g. customers"] --> DP
    G["Glossary term<br/>e.g. Customer"] --> DP
    P["Process · Connection<br/>Alert rule · Query"] --> DP
    DP --> CT["Data Contract"]
    DP -.carries.-> OWN["Owner team · domain<br/>product type · status"]
    classDef accent fill:#ff8400,stroke:#e67700,color:#ffffff,font-weight:600;
    class DP accent

Figure 1 — A Data Product wraps any number of registered assets into one owned, named unit. A Data Contract attaches to the product, not to the assets inside it — so the product is the on-ramp to contract-level governance for metrics, terms, processes, connections and alert rules.

Why teams reach for this

One capability becomes one noun. You set owner, domain, product type, and lifecycle once, at the product level, and it's how a metric, term, process, connection or alert rule gets onto a Data Contract — so governance has one place to attach. The same asset can sit in several products, so bundling costs nothing and locks nothing.

What a Data Product looks like¶

Surface	Where	What you see
List	`/data-products`	Filterable table — name, status, product type, owner team, domain, system, tags. KPIs / chart at the top of the lander.
Detail — Overview tab	`/data-products/{id}` (default)	Name, description, owner team, product type, domain, system, tags, status with state-machine actions, external URL, and audit metadata.
Detail — Assets tab	`/data-products/{id}` (Assets tab)	The bundle. One row per wrapped asset: source type, resolved name, added-on date, and a remove (trash) button gated on the `dataproducts.products.write` role. Add Asset wraps more.
"Part of" panel	Every asset detail page (catalog asset, glossary term, metric, BPM process, metadata-engine connection, logic-engine alert rule)	Part of N data products with chips linking to each product. If the asset isn't wrapped yet, the panel offers a Register as Data Product button.

What the bundle means in practice¶

The bundle is a 1-to-many junction between a Data Product and any number of source assets. The same source asset can belong to several Data Products — there is no exclusive ownership.

Property	Behaviour
Cardinality	One product wraps any number of assets (1 → N).
Sharing	The same asset can be wrapped by multiple products — no exclusive lock.
Standalone products	A product with zero assets is valid — create the named product first, decide its contents later.
Nested products	Not supported in v1 — a Data Product cannot wrap another Data Product.
Allowed source types	Catalog asset, catalog table, catalog schema, glossary term, metric, BPM process, metadata-engine connection, logic-engine alert rule, and org-shared warehouse query. Private warehouse queries can't be wrapped until promoted (from Insights or the flow builder). Any other type is rejected.

Delete a Data Product and its bundle rows are removed automatically; the underlying assets stay in their own modules with their own lifecycles.

Setup — what an admin does once¶

There is no per-tenant setup for the bundle bridge itself. The prerequisites are:

Prereq	Where	Why
At least one Product type	`/admin/data-products` (Product Types)	New products pick a type at creation. Dataset, API, Report, Stream, ML Model, and Data Pipeline are platform defaults; admins can add more.
At least one Team	`/admin/teams`	Every Data Product has an owner team.
Roles	Role groups (`/admin/users`)	`dataproducts.products.read` to view; `dataproducts.products.write` to create / edit / delete / wrap / unwrap; `dataproducts.products.approve` to sign off a lifecycle release (separation of duties). Built-in groups: Administrator, Contributor (read), Reader (read), and DataProducts.Approver (read + write + approve).

Registering an existing asset as a Data Product¶

Every path produces the same result: a Data Product whose bundle contains your asset, ready to be linked to a contract. The new product always starts in draft.

From the asset (recommended)From the Data ProductAsk HERC

Open the asset's detail page (a catalog asset, glossary term, metric, BPM process, metadata-engine connection, or logic-engine alert rule).
Find the Part of N data products panel.
Click Register as Data Product.
Choose Create new (default) — name and description are pre-filled from the asset; tweak them and pick an owner team, product type, and domain. The new product starts in draft with your asset already wrapped.
- Or choose Add to existing — pick from the dropdown of products that don't already contain this asset.
Save. The panel updates in place to show Part of 1 data product (or N+1) with a chip pointing at the product.

Open /data-products/{id} and switch to the Assets tab.
Click Add Asset.
Pick a source type (metric, glossary term, catalog asset, process, connection, or alert rule).
Pick the specific asset from the populated dropdown — already-bundled assets are filtered out.
Save. The new row appears in the Assets table.

Ask HERC, the in-app assistant, in plain language:

"Register the metric mrr as a data product called Customer 360 Revenue."
"What data products contain the glossary term Customer?"
"What's in the Customer 360 product?"

HERC registers or answers in one turn, then tells you the new product's name and status (always draft) and suggests the next step — link the product to a contract.

Before you register: the asset must be published¶

A catalog asset carries a lifecycle (draft → under review → published → archived). It can only be registered as a Data Product — or added to an existing one — once its status is published. That is the platform's accepted / green signal: it tells stewards and consumers the asset has earned the right to be governed at the contract layer.

What you'll see in practice:

On a catalog asset's detail page, the Register as Data Product button is greyed out with a tooltip — "Only published assets can be registered as a data product. Move this asset through review first." — until the asset reaches published.
Trying to add a non-published catalog asset (via the API or the Add Asset flow) is rejected with HTTP 422: "Asset cannot be registered as a data product while its status is 'draft'. Only published assets can be wrapped."
The gate fires only for source types whose module has opted in. Today that's catalog assets; the other source types accept any state until their owning module opts in.
Existing wraps are not affected. If a bundled asset later moves back to draft, the wrap stays — the gate only fires on new registration attempts.

To unblock yourself, advance the asset through its review flow until the status badge reads Published (green); the Register as Data Product button then enables.

The product lifecycle¶

A Data Product moves through five states. Reaching Published — the point at which the product is considered live and governable — is approval-gated: you submit a draft for review and a Data Owner approves it. Deprecate, retire, and withdraw are direct status moves.

stateDiagram-v2
    direction LR
    [*] --> Draft
    Draft --> UnderReview: Submit for review
    UnderReview --> Published: Approve
    UnderReview --> Draft: Reject / Withdraw
    Published --> Deprecated: Deprecate
    Deprecated --> UnderReview: Re-publish (re-review)
    Deprecated --> Retired: Retire
    Retired --> [*]
    classDef accent fill:#ff8400,stroke:#e67700,color:#ffffff,font-weight:600;
    class Published accent

Figure 2 — The product lifecycle. Release to Published is approval-gated: a draft is submitted for review and a Data Owner signs off. A deprecated product can be re-submitted to publish again; Retired is terminal.

How the approval gate works

You don't flip a product to Published directly. From a draft, choose Submit for review — this opens an approval task routed to a Data Owner in the Tasks inbox, powered by the Workflows engine. On approval the product becomes Published; on rejection or withdrawal it returns to draft. A deprecated product can be re-submitted for review to publish again. The direct status control performs only the non-published moves — deprecate, retire, and withdraw.

Why does a contract no longer link directly to a metric?¶

This is the most common question after April 2026. The short answer:

To put a metric (or glossary term, process, connection, alert rule) on a contract, wrap it in a Data Product first, then link the Data Product to the contract. A published catalog asset or a harvested table links to the contract directly, on its Linked Assets tab.

The summary you need as a steward:

Before April 2026, a contract's linked entities could be six different types, each with its own lookup path. That polymorphism leaked into every consumer module and made adding a new linkable type expensive.
Now a metric reaches a contract only through a Data Product. Want a metric on a contract? Register the metric as (or add it to) a Data Product, then link that product. The contract's Linked Products tab and the metric's Part of panel surface the same relationship.
Pre-existing direct links (test data) were dropped at migration; if you had a real link that mattered, register the asset as a Data Product and re-attach.
Since September 2026 a contract also links approved tables and catalog assets directly: a published catalog asset, or a table the metadata engine's harvest still finds. See Data Contracts.

For metrics specifically, the old direct contract link, the metric-to-contract lineage view, and the save-time validation that required a metric's columns to sit on a linked contract are all retired. Save the metric, then govern it through Data Product membership.

Name resolution and cascade¶

Resolved names. Every row in a product's bundle shows a human-readable name — Monthly Recurring Revenue for a metric, customers for a catalog asset, Customer for a glossary term. Datahub asks each source module for the name of the asset it owns. If that module's name lookup is temporarily unavailable (during a partial deployment, say), the row falls back to the raw ID in muted italic text rather than failing — so one misconfigured module never breaks the bundle view.

Cascade. What happens to the bundle when assets or products change:

What you do	What happens to the bundle
Delete a Data Product	All its bundle rows are removed. The bundled assets are untouched.
Delete a bundled asset out of band	The bundle row is orphaned. The platform's archive-before-delete rule prevents this in normal flows.
Unwrap an asset	The bundle row is removed; the product and the asset are both untouched.

Limitations¶

Limit	Why	Workaround
No nested products — a Data Product cannot wrap another Data Product.	Nested bundles create cyclic membership and ambiguous transitive ownership; not worth the cost in v1 without a real ask.	Use several products that share contracts, or model the parent as a higher-level product whose description references the others.
Hard-deleting a bundled asset out of band orphans its bundle row.	The bundle points at a polymorphic `(type, id)` reference that a normal foreign key can't enforce across modules.	Use the platform's archive-before-delete flow. Hard delete is a guarded admin action and rare in practice.
A metric, term, process, connection or alert rule cannot link to a contract directly.	Replaced by contract → product → asset.	Register the asset as (or add it to) a Data Product, then link the product to the contract.
A contract's Linked Products picker shows only Data Products.	Products have their own tab; approved tables and catalog assets are linked on the Linked Assets tab.	Wrap the asset first, then link its product (see Why does a contract no longer link directly to a metric?).
Catalog assets must reach Published before they can be wrapped.	Only accepted (green) assets may flow into contract-bound bundles.	Move the asset through review; the Register as Data Product action enables once the badge turns green. The same gate applies to Add Asset inside an existing product.

Audit & compliance¶

Question a CISO might ask	Where to look
"Which contracts does this metric / asset / term flow into?"	Open the asset's detail page → the Part of N data products panel → click a product chip → the product page lists every linked contract.
"Who can register an asset as a data product?"	Only users with the `dataproducts.products.write` role. The action is hidden for read-only users.
"Can a user bypass the bundle and link an asset straight to a contract?"	Only an approved table or catalog asset, which links directly by design (a published catalog asset, or a table the latest harvest still finds, from a source the user may read). A metric, term, process, connection or alert rule cannot: a contract's product link accepts only a Data Product, enforced at both the database and the model layer.
"What happened to the legacy direct links?"	They were deleted at the lockdown migration, and the deletion was logged for audit.
"What's recorded when an asset is wrapped or unwrapped?"	Each wrap and unwrap records who did it and when; the product's audit metadata reflects the change. Wrapping or removing an asset follows the product's domain, like editing the product: only members of that domain can, unless the product has no domain.

Troubleshooting¶

Symptom	Likely cause	Fix
The Register as Data Product action is missing on an asset page	The user lacks the `dataproducts.products.write` role	Ask an admin to grant the role group, then sign in again.
The Add Asset dropdown is empty after picking a source type	Every asset of that type is already bundled, or the user lacks that source module's read role	Check the source module's read role; if all are already bundled, that's expected.
A bundled row shows a raw ID in muted italic instead of a name	The source module's name lookup isn't available (partial deployment)	Let the deployment finish / restart the backend; the row resolves on the next load.
Wrapping the same asset twice in one product returns 409	The asset is already in this product (duplicate wrap)	Intentional — the first wrap is already there; nothing to do.
Registering a product whose name is taken returns 409	Product names are unique per tenant	Pick a different name; the modal surfaces a clear message.
The Register as Data Product action is greyed out with a status tooltip	The catalog asset isn't Published (it's draft, under review, or archived)	Move it through review until the badge reads Published, then reopen the asset page.
Adding a non-published catalog asset to an existing product returns 422	The same status gate, enforced server-side on both the register and Add Asset flows	Publish the catalog asset first, then add it.
A contract's Linked Products tab is empty even though you linked things before April 2026	Pre-bundle direct links were deleted at the lockdown migration	Re-register the relevant assets as Data Products, then link them to the contract.

If something is broken that this page doesn't cover, ping your Datahub contact with the data product ID (visible in the URL) and the error text from the toast or banner.

Arriving from a domain's detail page narrows this list to that domain automatically — a banner names it, with a one-click way back out. See Domains.