The Technical Dictionary connects business language with physical evidence recorded in a source. Each dictionary field is contextualized by its Repository and can store the available technical data, such as schema, table, column, type, and physical characteristics. When the link is real, the field is associated with an Attribute in the taxonomy to make visible where a business concept is materialized.
The dictionary is editable: metadata from sources provides physical context, and responsible people can complete or correct business descriptions and definitions. It does not automatically translate or modify the dynamic names the organization already uses; the interface language does not alter that data.
Before you begin
Role. The Data Engineer manages fields, metadata, and technical associations with technical.manage in the Repositories assigned to them. The Administrator has this scope across the entire company. Data Stewards and Data Owners can enrich descriptions and definitions in their authorized Domains or Subdomains; their participation does not replace the repository's technical scope.
Module. Technical Dictionary and Data Repositories must be enabled. The former depends on the latter: there is no useful technical dictionary without a registered repository. A disabled module cannot be operated, even if someone knows an access path.
Preconditions. Start with a taxonomy containing the Domain, Entity, and Attribute you intend to document, and a Repository representing the physical source. Also verify that the proposed association is verifiable; do not infer it merely because two names look similar.
Recommended workflow
- Clarify the meaning before associating. Locate the Attribute in its Entity and its Domain or Subdomain context. Review its name and functional definition with the responsible Steward or Owner when necessary.
- Identify the physical context. Select or register the field within the corresponding Repository. Retain the technical data needed to identify it—for example, schema, table, column, and type—without including secrets or access details.
- Record the verified physical relationship. Associate the field with the Attribute only if it represents that information element. The direct association documents the link; the Domain and Subdomain context can be obtained from the Attribute → Entity → taxonomy chain.
- Enrich the record. Add a description explaining the correspondence between the physical name and the business meaning. Clearly distinguish a technical convention from a business definition so that readers know which part came from the source and which is maintained editorially.
- Review it in the context of relationships. In the map's technical detail, you can follow the Attribute ↔ Technical Dictionary Field ↔ Repository path, together with the schema, table, and column when recorded. The absence of a line means there is no documented relationship, not that one should be inferred.
Synthetic example. The “Admission date” Attribute of a Person Entity can be associated with a physical field
fecha_ingresoin a table in the Academic Repository. The record must explain why both represent the same data. If another table contains a date with a different purpose, it should not be associated merely because part of the name is shared.
Dictionary, quality, and SQL
Quality Rules are defined on Attributes and can be linked to Technical Dictionary fields. To generate SQL, GovFrame requires valid associations to physical fields and a configured dialect. If the physical field or dialect is missing, SQL must not be generated. The generated SQL is limited to that documented result: it does not imply automatic execution against the repository or replace review by the responsible person.
This traceability makes it possible to understand whether a rule relies on a specific source, but it does not turn every field in a table into a control or every control into an independent Risks or Controls catalog. Depending on the case, the control is represented by a Quality Rule, Policy or Procedure, Workflow, task, approval, classification, or certification.
Expected result
The result is a readable technical record that identifies a physical field within its Repository and, when applicable, shows its explicit association with an Attribute. The record retains the context needed to navigate from business meaning to the source, analyze impact, and relate the field to Rules, Contracts, or other objects that already have recorded links.
Current-state limitations
- A table's membership in a Repository does not automatically register all its fields in the Dictionary or associate them with Attributes.
- A field can provide technical context even when a complete business definition does not yet exist; this absence must be shown as such, not filled in by inference.
- Relationships, descriptions, and operations are isolated by company and subject to roles, capabilities, modules, and scope.
- Technical codes serve persistence, validation, import, or generated SQL; understandable names must take precedence in the guide and functional interface.