GovFrame uses the taxonomy as its backbone. The taxonomy organizes business context; the other objects relate to one or more levels to explain what data means, who is responsible for it, where it lives, how it is controlled, and how it is published.
This page answers two questions:
- At which taxonomy level does each object relate?
- How are business, technical, and operational objects connected to one another?
1. The taxonomy is the navigation axis
The tenant can work with one of these models:
Standard taxonomy: Domain → Entity → Attribute
Expanded taxonomy: Domain → Subdomain → Entity → Attribute
| Level | What it represents | What typically depends on it |
|---|---|---|
| Domain | Broad business area and responsibility. | User scope, ownership, products, contracts, policies, and high-level objects. |
| Subdomain | Optional division of the Domain. | More precise scope, Entities, products, contracts, policies, and operational use cases. |
| Entity | Business concept or object. | Attributes, Business Terms, governance roles, inherited repositories, and unstructured data. |
| Attribute | Information element within an Entity. | Quality Rules, Technical Dictionary fields, classifications, and contracts. |
An object can have a direct association with a level or reach it through a derived relationship. For example, a technical field points directly to an Attribute; the Domain is obtained by traversing Attribute → Entity → (Subdomain) → Domain.
2. Direct and inherited association rule
- Direct: the record explicitly stores the link to the taxonomy level. Example: a Product stores
domainIdand, optionally,subdomainId. - Through a component: the link is stored in a reusable relationship that allows an object to be associated with one or more nodes. Example: a Repository can be associated with several Domains or Subdomains.
- Inherited: the system calculates the context from a child object. Example: a Quality Rule inherits the Domain and Subdomain from the Attribute to which it belongs.
- Derived through composition: a Data Contract can reach Attributes, rules, fields, and terms through its association tables, even though its primary scope is Domain/Subdomain.
An inherited association does not change the object's original level. It is used for filters, authorization, navigation, coverage, and impact analysis.
3. Object and relationship level matrix
| Object | Current primary association | Relationship level | Relevant relationships |
|---|---|---|---|
| Business Term | Domain and links to one or more Entities. | Domain or Entity; it can be linked to other nodes through components. | Defines business language; can be part of a Data Contract and document a KPI. |
| Governance role | Domain and links to Entities. | Domain and Entity. | Represents an Owner/Steward or another responsibility; can be responsible for a Product or Data Contract. |
| Quality Rule | Attribute. | Attribute, with inherited context from Entity, Subdomain, and Domain. | Uses a Dimension; is associated with valid technical fields and can be included in Data Contracts and Workflows. |
| Technical Dictionary field | Attribute and Repository. | Attribute; the Repository provides the physical context. | Stores schema, table, column, type, and physical characteristics; materializes a link to the source. |
| Data Repository | One or more Domains/Subdomains through high-level associations; may retain an inherited Entity. | Domain/Subdomain; optionally Entity for compatibility or legacy context. | Connects through a Connector; contains metadata, snapshots, and Technical Dictionary fields; may belong to a System. |
| Information System | One or more Domains/Subdomains through high-level associations; may retain an inherited Entity. | Domain/Subdomain; optionally Entity for legacy context. | Relates to Repositories, Products, and Data Contracts. |
| Unstructured data | Entity and/or component association. | Entity, with inherited Domain/Subdomain. | Can be an architecture asset and participate in governance relationships. |
| Data Asset | Domain. | Domain; it can receive additional taxonomy associations. | Can be part of a Product and be certified, classified, or commented on. |
| Data Product | Domain and optional Subdomain. | Domain/Subdomain. | Groups Assets and relates to an Owner and Data Contracts. |
| Data Contract | Domain, Subdomain, and Owner. | Domain/Subdomain. | Includes Attributes, Quality Rules, Technical Dictionary fields, Business Terms, Systems, and Product. |
| Policy, Process, and Procedure | Optional Domain/Subdomain. | Domain/Subdomain. | Maintain the Policy → Process → Procedure hierarchy, versions, responsible parties, and approvals. |
| Objective | Optional Domain/Subdomain. | Domain/Subdomain. | Relates to one or more KPIs and maintains measurements and reviews. |
| KPI or Key Result | Explicit primary level: Domain, Subdomain, Entity, or Attribute. | Any of the four levels. | Can have secondary links to the taxonomy and to Business Terms, Assets, Rules, Technical Dictionary, Repositories, Systems, Products, and Data Contracts. |
| Workflow and case | Optional Domain/Subdomain and target object. | Direct or derived context from the affected object. | A case can point to any object in the ecosystem; its tasks, decisions, evidence, and notifications depend on the case. |
| Access request | Requested object and Workflow case. | Derived from the object: table, dashboard, dataset, or another permitted destination. | Can group multiple requests, have partial approval, masking, and provisioning. |
| Stewardship | Owner assignments, scopes, classifications, certifications, comments, and tasks. | Resolved from the target object and its taxonomy context. | Adds responsibility and status without replacing the object's taxonomy relationship. |
Risks and Controls: precision of the current model
The current implementation does not include a separate catalog module called Risks or Controls with its own tables equivalent to those for Business Terms or Rules. Control is represented through combinations of existing objects, for example:
- a Quality Rule as a technical control;
- a Policy/Procedure as a regulatory control;
- a Workflow, task, or approval as an operational control;
- a Rule included in a Data Contract as a verifiable commitment;
- a classification, certification, or stewardship task as follow-up.
The interface may show risks, alerts, or coverage derived from the dashboard and tasks, but this documentation does not present them as an independent inventory until that module and its data contract exist.
4. How the ecosystem is formed
The typical functional path is:
Taxonomy
↓
Responsible parties and scope
↓
Business Terms ────────────────────────────┐
↓ │
Entities and Attributes │
↓ │
Technical Dictionary ← Repository ← Connector / source
↓
Quality Rules ─────────────────────────┐ │
↓ │ │
Data Product ← Assets ←────────────────┘ │
↓ │
Data Contract ← Terms, Attributes, Rules, Fields, Systems
↓
Workflows, requests, tasks, approvals, and audit
KPIs and Objectives span the ecosystem: they take a primary taxonomy level and can document their formula, measurement source, control, evidence, product, or contract through typed links.
5. How to read a relationship in the interface
- Start with the Domain or Subdomain to understand the context and scope.
- Go down to Entity and Attribute to find the precise meaning.
- From an Attribute, review Quality Rules and Technical Dictionary fields.
- From the field, identify the Repository, schema, table, column, and System when recorded.
- Follow Products and Data Contracts to understand what is delivered, to whom, and under what commitments.
- Use Workflows, tasks, and requests to follow pending decisions, changes, and access.
The Relationship Explorer has three perspectives: Overview for discovery, Impact for analyzing dependencies, and Technical Detail for following the link between the taxonomy and physical sources. The usage guide is at How to read the relationship map.
6. Important limits
- All relationships are isolated by company and must respect the user's scope.
- Technical codes identify records, but functional guides must display readable names.
- A high-level association does not imply that every field in a source is associated with every attribute.
- A Quality Rule generates SQL only when it has valid associations to physical fields.
- Disabling a module hides and blocks its operation for the tenant, but does not automatically delete its data.