extension for more business oriented and compliance attributes

Author: agile-lab

README.md

@@ -31,6 +31,10 @@ The fixed structure must be technology-agnostic. The first fields of teh fixed s
 * `Description: [String]` detailed description about what functional area this Data Product is representing, what purpose has and business related information.
 * `Kind: [String]*` type of the entity. Since this is a Data Product the only allowed value is `dataproduct`.
 * `Domain: [String]*` the identifier of the domain this Data Product belongs to.
+* `BusinessFunction: [String]*` A type of activity or role performed in the organization, often cutting across multiple domains. Examples: Accounting, Reporting, Support, Risk Management
+* `Country: [Option[String]]` The primary country associated with the Data Product. This attribute identifies the geographical scope where the Data Product is produced, consumed, or legally relevant. It enables compliance with local regulations, supports regional reporting, and facilitates cross-border interoperability.
+* `LegalEntity: [Option[String]]` The legal entity (e.g., company, subsidiary, branch) accountable for the Data Product. This attribute clarifies ownership and responsibility at a corporate level, ensuring traceability for compliance, contractual agreements, and internal governance processes.
+* `Brand: [Option[String]]` The commercial brand under which the Data Product is positioned or recognized. This attribute links the Data Product to market-facing identities, helping align data usage and reporting with business lines, customer experience, and brand-specific strategies.
 * `Version: [String]*` this is representing the version of the Data Product. Displayed as `X.Y.Z` where X is the major version, Y is the minor version, and Z is the patch. Major version (X) is also shown in the Data Product ID and those fields (version and ID) must always be aligned with one another. We consider a Data Product as an independent unit of deployment, so if a breaking change is needed, we create a brand-new version of it by changing the major version. If we introduce a new feature (or patch) we will not create a new major version, but we can just change Y (new feature) or Z patch, thus not creating a new ID (and hence not creating a new Data Product).
   Constraints:
   * Major version of the Data Product is always the same as the major version of all of its components ,and it is the same version that is shown in both Data Product ID and component IDs.
@@ -55,6 +59,12 @@ The fixed structure must be technology-agnostic. The first fields of teh fixed s
   * `Confidentiality: [Option[String]]` This field indicates the level of confidentiality assigned to the data product. It defines how sensitive the data is and determines the access controls and protections that need to be in place. Common examples might include "Public," "Internal," "Confidential," or "Secret."
   * `Visibility: [Option[String]]` This field defines the scope of visibility for the data product. It dictates which users, teams, or systems can view or access the data. For example, it could specify whether the data is visible to only specific internal departments
   * `GDPR: [Option[String]]` This field indicates whether the data product is subject to the General Data Protection Regulation (GDPR), and if so, what specific measures or classifications apply. Yes or No
+* `Regulations: [Yaml]` Attributes providing information related to specific regulations
+  * `DoraClassification: [Option[String]]` Classification of the Data Product according to the Digital Operational Resilience Act (DORA). Defines the level of criticality (e.g., critical, important, non-critical) for ICT risk management and resilience obligations.
+  * `AIActRelevance: [Option[String]]` Indicates whether the Data Product is used in the context of AI systems as defined by the EU AI Act. Specifies the risk category (minimal, limited, high, prohibited) and ensures transparency, data quality, and traceability for AI training and inference.
+  * `SoxRelevance: [Option[String]]` States whether the Data Product contributes to financial reporting or internal control processes relevant under Sarbanes–Oxley (SOX) compliance.
+  * `EsgDisclosure: [Option[String]]` Identifies if the Data Product is linked to Environmental, Social and Governance (ESG) reporting, ensuring compliance with sustainability reporting standards (e.g., CSRD, ESRS).
+  * `BaselApplicability: [Option[String]]` Indicates whether the Data Product is relevant for risk measurement or reporting under Basel III/IV banking regulations (credit risk, operational risk, liquidity coverage).
 * `BusinessInfo: [Yaml]` 
   * `ValueProposition: [Option[String]]`: Describe the valu eproposition of the data product from a business standpoint
   * `ValueGeneration: [Option[String]]`: Define what kind of value this DP will generate. It could be a Foundation DP ( tipically a source aligned one), otherwise can be "Operation Monitoring" collecting information about the company processes and providing decision support, then "Revenue Generation" for those DP that can be directly monetized.