Create a data taxonomy

The taxonomy is the backbone of the GovFrame catalog: it provides the context for defining information, assigning responsibilities, documenting controls, and connecting the business to its technical sources. Each taxonomy belongs to a company; its names, descriptions, and definitions are that company’s own content. The interface may use different languages, but it does not automatically translate or modify those business names.

GovFrame supports two structures. The standard structure follows Dominio → Entidad → Atributo. The expanded structure adds an optional level: Dominio → Subdominio → Entidad → Atributo. A Domain represents a business and responsibility scope; an Entity, an object or concept within that scope; and an Attribute, an information element of the Entity. A Subdomain is used only when enabled for the company and when it provides a useful division of the Domain.

Before you begin

• Role and scope: an Administrator operates with global scope in the company. Data Owners and Data Stewards need the applicable capability and the corresponding Domain or Subdomain scope. Viewing an object does not by itself grant permission to modify it.
• Module and company: work in an active company and confirm that the catalog operation is available for it. Module configuration and backend validations limit the operation, even if someone knows an interface route.
• Prerequisites: agree with the scope owner on whether to use the standard or expanded model; define readable names, a business description, and who will be accountable for each Domain. Decide what information must be documented down to the Attribute level before creating rules or technical associations.

Synthetic example: Atención a clientes → Solicitudes → Fecha de ingreso uses the standard model. If the business needs to separate channels, it could use Atención a clientes → Canales digitales → Solicitudes → Fecha de ingreso in the expanded model.

Recommended workflow

1. Define the Domain. Record a scope that is understandable to those who manage the data and has clear accountability. Avoid using a Domain as a generic container for projects, applications, or technical tables.
2. Decide whether a Subdomain adds context. In the expanded model, use it for a stable business division. Do not duplicate the Domain in the Subdomain name or create alternative levels outside the available hierarchy.
3. Model Entities and Attributes. Add the Entities that the scope needs to explain, and go down to the Attribute level when meaning, quality control, classification, or mapping to a physical field must be documented. An Attribute retains its context through the Entity and, when present, the Subdomain.
4. Assign responsibility and scope. Link Data Owners and Data Stewards to the relevant nodes and keep people’s scopes aligned with that area. A catalog governance role does not replace the session profile or its capabilities.
5. Review relationships before expanding the catalog. Check that Terms, Technical Dictionary fields, Rules, Products, and Contracts are connected at the appropriate level. The relationship map makes it possible to distinguish a recorded link from a relationship that only seems likely based on its name.
6. Maintain context as the taxonomy evolves. Taxonomy change requests are part of catalog operations, but this guide does not assume stages, approvals, or states for each change. Document the reason for the adjustment according to the company’s current practice.

Expected outcome

At the end, the company has a coherent business hierarchy isolated from other companies: each Attribute can be traced back to its Entity and Domain—and Subdomain, if applicable; owners and scopes reflect the actual area; and subsequent objects have an unambiguous point of association.

The taxonomy does not imply that all fields in a technical source are linked to all its Attributes. Nor does it turn a high-level association into a physical dependency. These distinctions are essential before interpreting coverage, impact, or controls. When a related module is disabled, its data may be retained, but its operation is unavailable until it is re-enabled according to the company’s configuration.

For more information, see the object and relationship model, how to read the relationship map, roles, capabilities, and scope and modules and dependencies.