Data product asset types and operating model

Updated: April 17, 2026

Data products are created and built based on specific asset types, relations, and attributes. Using the specific data product operating model allows you to scale as Collibra data product features grow over time.

Domain type

The domain type Data Product Catalog can host Data Products assets and their related assets, such as Data Product Ports and Data Contracts.

Asset types and asset type groups

The following asset types are dedicated to data products:

• Data Product
  A data product is a reusable package that provides data to answer a business question or solve a specific business problem.
  The Data Product asset type includes default attributes and relations, and a specific asset type layout. For information on configuring the asset type, go to ...
  
• Data Product Port
  A data product port defines the interface through which a data product interacts with the broader ecosystem. A link between a Data Product Port and a Data Product via the "exposes data as" relation can be considered an "output port" and a link with the "consumes data through" relation can be considered an "input port".

  

  In advanced governance use cases, you can use the child asset types Data Product Output Port and Data Product Input Port, and their relations.
  

• Data Contract
  A data contract defines the commitments a data product owner makes to data consumers. The data contract documents the structure, format, service level, quality, and terms of use.

  For more information about data contracts, go to Data products basics. For information about creating data contracts, go to About data contract creation and maintenance.

The following asset type groups are dedicated to data products.

• Data Product Port Asset: Groups assets linked to data product ports.

  Tip By default, only Tables are part of this group. We recommend only exposing tables. However, Data Sets and Data Elements are fully supported in the community workflows if you include them in this asset type group.

• Data Product Input: The physical input for a data product.
  Use this asset type group only in advanced governance use cases that involve the Data Product Input Port asset type.

Relations

The following relations are specific to data products.

• Data Product exposes data as/is output port for Data Product Port
• Data Product Port is input port for/consumes data through Data Product
• Data Product Port is implemented as/implements Data Product Port Asset

  Note When you create a diagram, you can add this relation type from the Data Product Port asset type to each asset type assigned to the Data Product Port Asset asset type group.

• Data Product Input implements/is implemented as Data Product Input Port
  Although this relation is still available, we recommend using Data Product Port is implemented as/implements Data Product Port Asset instead.
• Data Contract governs functioning of / should operate according to Data Product Port
• Data Contract information to be provided / is mentioned in the terms of Data Attribute
• System implements/is implemented in Data Product Port
• Data Product relates to/is related to Measure
• Data Product relates to/is related to Business Term
• Data Product relates to/is related to Data Domain
• Data Product is explained in/explains Data Notebook

Attributes

Several attributes are specific to data products.

For Data Product

• Data product category: Defines whether a data product is targeting business users or more technical users. The out-of-the-box values are Derived (for business users) and Foundational (for more technical users).
  

For Data Product Port

• Access method: Indicates the method that can be used to access the data.

  Tip This attribute can be used in workflows to create data product port assets per access method. In that case, the values must reflect asset types in Collibra. For information, go to the workflows in Collibra Marketplace or follow training Set up data product workflows.

• Access instructions: Provides instructions on how to access the data.

For Data Contract

• Version: A label or identifier that represents a specific state or iteration, used to track changes over time.
  
• Manifest ID: The unique identifier of a manifest file.
  
• Multiple SLA (Service Level Agreement) attributes.
  • Backup Frequency
    This metric for the backup service level objective documents the expectations around the frequency when a backup of the data is made. For systems with point-in-time recovery (PITR), this can be the frequency a new base backup or differential backup is created.
  • Latency
    This metric for the latency service level objective documents the expectations around what can be the maximum time between source data becoming available and data processing completion to make the data available.
    
  • Most Recent Record Date
    This metric for the freshness service level objective documents the expectations around the maximum age of the most recent entry in the data set. This metric is generally used for static data sets or data sets that are updated infrequently.
  • Processing Frequency
    This metric for the frequency service level objective documents the expectations around the frequency of processing of the source data to make the latest data set available.
    
  • Processing Method
    This attribute type for the frequency service level objective documents the expectations around the way the source data is processed. Sample values are: batch-processing, streaming, and manual refresh.
    
  • Recency
    This metric for the freshness service level objective documents the expectations around the maximum age of the most recent entry in the data set. This metric is generally used for result sets that dynamically evolve over time.
  • Recovery Point
    This metric for the backup service level objective documents the expectations around the size of the period for which data may be lost in case of a restore. For systems with point-in-time recovery (PITR), it is possible that the recovery points are more granular than the backup frequency.
    
  • Recovery Time
    This metric for the support service level objective documents the expectations around what is the maximum time between starting a support request and getting a first response.
    
  • Response Time
    This metric for the support service level objective documents the expectations around what is the maximum time between starting a support request and getting a first response.
  • Retention Period
    This metric for the retention service level objective documents the expectations around how long records in the data set can be retained.
    
  • Retention Unlimited
    This indicator for the retention service level objective indicates whether a limit is defined on the period the data is retrained. It is expected that when a concrete value for the attribute type Retention Period is provided, the value of this field will be false.
  • Support Availability
    This attribute type for the support service level objective documents the expectations around the days/time/period when technical support is available.
  • Uptime Percentage
    This metric for the availability service level objective documents the expectations around uptime of the system where the data can be accessed.
    

Diagram view

Related topics

• About data products
• Using data products
• About data contract creation and maintenance

Helpful resources

• Videos:
  • What's a data product?
  • What is a data contract?
  • Webinar
• Data Product learning path on Collibra University
• Ebook: Six best practices for building and deploying effective data products