Policies and indicators make it possible to link the governance framework to the monitoring of its results. GovFrame organizes normative documents as Policy → Process → Procedure, with versions and attachments stored externally. These objects can optionally be associated with a Domain or Subdomain and retain responsible parties and approvals. The hierarchy makes it easier to understand whether a document sets a guideline, describes a process or specifies a procedure, without turning the external attachment into technical catalog content.
Objectives can have Domain or Subdomain context and be related to one or more KPIs. KPIs—also called Key Results—have an explicit primary level: Domain, Subdomain, Entity or Attribute. They can add secondary links to terms, assets, rules, the dictionary, repositories, systems, products and contracts. GovFrame supports codes, many-to-many relationships, manual measurements, reviews and statuses for these objects; this guide does not assume status values or automatic measurement capture.
Before you begin
- Role and scope: the Administrator has global scope within the company. The Data Owner needs the applicable capability and an authorized Domain or Subdomain. A Data Steward can collaborate within their capability and scope; other roles can view what their authorization permits.
- Modules: confirm that Policies and Objectives and KPIs are active. Deactivation prevents operating the module, and the backend rejects its procedures; it does not automatically delete data that already existed.
- Prerequisites: for a policy, have the responsible party, context, and external document or reference to be linked. For an Objective or KPI, agree on the code, primary taxonomy level, what is to be measured, and the source of the manual measurement. Check that the planned associations already exist in the catalog.
Synthetic example: the Objective Improve contact completeness can be related to a KPI whose primary level is the Attribute Contact email. The KPI can link to the Completeness Rule and the Contract that declares this commitment, without implying that the measurement is calculated automatically.
Recommended workflow
- Place the normative document in the correct hierarchy. Register the Policy as a guideline, the Process as the development of that guideline, and the Procedure as its operational specification. Associate a Domain or Subdomain only when the scope is genuine, and retain the relevant version and external attachment.
- Define the Objective before choosing its indicators. Relate the Objective to the business scope and to the KPIs that make it possible to assess its progress. Many-to-many relationships allow a KPI to contribute to more than one Objective when appropriate, without duplicating the indicator.
- Set a single primary level for each KPI. Select Domain, Subdomain, Entity or Attribute according to the object the indicator primarily concerns. Secondary links expand the evidence or traceability, but do not replace that primary level.
- Document relationships that can be explained. Link Terms to clarify the language, Rules to identify a control, fields and Repositories for technical traceability, and Products or Contracts for delivery context. Do not infer links merely because they share a Domain or a word in their name.
- Record measurements and reviews as manual. Enter manual measurements and reviews in the relevant object. Aggregated indicators, coverage, charts and dashboard history are monitoring views; they do not in themselves confirm a capture frequency or automated testing.
- Use existing controls, not assumed catalogs. In the current model, there are no independent Risks or Controls catalogs. A Rule can act as a technical control, a Policy or Procedure as a normative control, and a task, approval or Workflow as an operational control when they are related.
Expected outcome
The company can trace from a Policy to its Process and Procedure, and from an Objective to the KPIs and evidence that provide context. Each KPI retains a primary taxonomy anchor and verifiable associations, while manual measurements and reviews keep what is declared separate from what is automated.
The dashboard aggregates indicators, coverage, charts and history at the company level. The visibility of derived risks and Products can be filtered according to a person’s scope where applicable; an item’s absence from the view must not be interpreted as global nonexistence or as an exception to authorization rules.
For more information, see the object and relationship model, how to read the relationship map, roles, capabilities and scope and modules and dependencies.