A Data Product organizes a value delivery based on assets and business accountability. In GovFrame, it records type, delivery method, criticality, owner, and state, and is associated with a Domain and, optionally, a Subdomain. A Product can group data assets and be related to Contracts. Its record documents the product without automatically turning it into a technical source or a guarantee of availability.
A Data Contract expresses the commitment that accompanies that delivery. It is versioned and can describe purpose, schema compatibility, availability, and freshness. In addition to its Domain, optional Subdomain, and Owner, it can include Products, Attributes, Quality Rules, Technical Dictionary fields, Business Terms, and related Systems. Its associations help explain the scope of the commitment; they do not by themselves turn each related object into an executed control.
Before you begin
- Role and scope: The Administrator manages these objects within the company. The Data Owner requires the relevant scope capability and authorization for the Domain or Subdomain. A Data Steward's or Data Engineer's involvement depends on their capability, scope, and the business or technical object being related.
- Modules: Confirm that Data Products and Data Contracts are active. Products depend on Data Assets and Contracts; Contracts declare dependencies on Assets, the Technical Dictionary, and Quality Rules. A disabled dependency may limit or hide the related operation.
- Prerequisites: Identify the responsible Domain, Owner, Assets that make up the delivery, and intended recipients or uses. For a Contract, gather the purpose and commitments that can be supported by registered associations, rather than inferring them from similar names.
Synthetic example: The Product Weekly service summary can group a reporting asset under the Domain Customer service. Its Contract can link the Attribute Entry date, the completeness Quality Rule that controls it, a Term that defines it, and the related System.
Recommended workflow
- Define the Product based on the delivery. Record its type, delivery method, criticality, owner, and state according to information approved by the company, together with the Domain and Subdomain, if one exists. Use names that describe the value or data service, not just the underlying technology.
- Associate the Assets that make it up. Link datasets, APIs, reports, or other Data Assets only when they are part of the delivery. Association with a Domain does not mean that all assets in that Domain belong to the Product.
- Establish the Contract's purpose. Link the Contract to the same business context where appropriate and document its purpose, schema compatibility, availability, and freshness. Keep these statements linked to the relevant Contract version.
- Build selective traceability. Add Attributes, Terms, Rules, Technical Dictionary fields, Systems, and Products that genuinely define the commitment. A physical field retains its relationship to the Repository, schema, table, and column; it should not be associated by assumption with every Attribute mentioned by the Contract.
- Review declared controls. An included Rule can explain a verifiable commitment, but does not promise automatic execution. If SQL is required, the Rule needs a valid physical field and a configured dialect; the Contract does not remove this condition.
- Maintain versions and responsibilities. Contracts are versioned, and Products and Contracts can reference an Owner. Review the links when assets, terms, or attributes change. The available evidence does not define a workflow, state values, or an approval cadence for these reviews.
Expected result
The Product is understood as a governed delivery: its Assets, taxonomic context, owner, and documented characteristics are known. The associated Contract exposes, by version, the purpose and commitments that can be traced to Attributes, terms, controls, and technical sources when those associations exist.
Availability and freshness listed in a Contract are information about the commitment. They do not imply automatic monitoring, an effective metadata schedule, or the existence of enabled scans. Similarly, Product and Contract states are recorded as information about those objects, but this documentation does not list or infer unconfirmed state values.
For more detail, see the object and relationship model, how to read the relationship map, roles, capabilities, and scope, and modules and dependencies.