A Quality Rule expresses a control over a Attribute in the taxonomy. In GovFrame, it can document a dimension, an expression, a threshold, and a frequency. Its Domain, Subdomain, and Entity context is obtained from the associated Attribute: the rule remains an Attribute-level object even when it appears in filters at higher levels.
The rule can be related to fields in the Technical Dictionary and included in a Data Contract. This association connects the business control to a registered physical source. SQL is generated only from valid associations to physical fields and a configured dialect; without both elements, the Rule can exist as a governance definition, but it must not be presented as generated SQL or as an executable validation.
Before you begin
- Role and scope: the Administrator has global scope within the company. Data Owners and Data Stewards need the corresponding business capability and scope over the Domain or Subdomain inherited by the Attribute. The Data Engineer manages the technical context only in Repositories included in their technical scope.
- Module: confirm that Quality Rules is active. To work with physical associations, Technical Dictionary and Data Repositories are also relevant; they are declared dependencies of the module.
- Prerequisites: have a taxonomy with the target Attribute. If SQL generation is intended, a physical field associated in the Technical Dictionary must exist, and the corresponding dialect must be configured. Identify the dimension, control expression, and threshold that the business can explain.
Synthetic example: for the Attribute Contact email, a completeness rule can state that the value must not be left blank and record the agreed threshold. It can generate SQL only if it is linked to a valid physical field and a dialect is configured for that context.
Recommended workflow
- Start from the Attribute, not an isolated table. Select the Attribute whose meaning is being protected and verify its Entity and Domain. This gives the control an unambiguous business responsibility and scope.
- Describe the control. Record a readable name, the quality dimension, the expression, the threshold, and the frequency that correspond to the current definition. Avoid naming a Rule only after a column, because the same physical name can have different contexts.
- Check the technical association. When needed, relate the Rule to the Technical Dictionary field that materializes the Attribute. Verify that the physical association documents the relevant Repository, schema, table, column, and type; a Repository relationship alone does not associate all of its columns.
- Treat SQL as a conditional artifact. Request SQL only when the field association is valid and the dialect is configured. The result is SQL generated for the Rule, not a promise of automatic execution, connection to the source, or a quality result.
- Relate commitments and tracking. If the Rule is relevant to a delivery, associate it with the corresponding Data Contract. You can retain histories, states, and versioned SQL scripts with auditing, but this guide does not define state values or an approval workflow.
- Review the context when metadata changes. Metadata can handle previews, manual/daily/weekly/monthly scheduling, and versioned snapshots. Scheduling and any effective automation depend on the company's configuration; do not assume that enabled production jobs exist or that a snapshot executes the Rule.
Expected result
The company has an explainable Rule starting from the Attribute it controls, with its dimension, expression, threshold, and frequency documented. When valid technical traceability exists, the physical field and dialect that enable generated SQL can also be identified; when it does not, the limitation remains visible rather than simulating an execution.
A Quality Rule can function as a technical control within the current model, but GovFrame does not have independent Risks or Controls catalogs equivalent to Rules. Regulatory or operational tracking is represented using existing objects—for example, policies, procedures, contracts, tasks, or approvals—according to their registered relationship.
For more information, see the object and relationship model, how to read the relationship map, roles, capabilities, and scope and modules and dependencies.