---
title: Getting Started
description: >-
  A suggested path to establish company context, assign responsibilities, and
  connect the governance catalog.
audiencia: Administrator | Data Owner | Data Steward | Data Engineer
roles: >-
  Administrator coordinates; Data Owner and Data Steward define business
  context; Data Engineer provides technical context
modulo: Cross-cutting data governance overview
revision: '2026-10-19'
section: empezar
order: 20
sources:
  - CONTEXT.md
  - Módulosydependencias.md
  - 'Roles,capacidadesyalcance.md'
  - Modelodeobjetosyrelaciones.md
  - Cómoleerelmapaderelaciones.md
locale: en
---
# Getting Started

Getting started with GovFrame means establishing a minimal but connected governance context: an understandable taxonomy, responsible people with scope, and, when the company needs it, traceability to its technical sources. This is a **suggested functional path**; adapt the sequence to the enabled modules and the company’s decisions. It does not assume forms, workflow states, or unconfirmed automations.

## Before you begin

| Aspect | What to check | Usual responsible party |
|---|---|---|
| Company | The company must be `active` to operate normally. | Administrator or authorized platform management |
| Roles and scope | Each participant needs active membership, appropriate capabilities, and scope over a Domain/Subdomain or Repository, depending on their work. | Administrator |
| Modules | Confirm that the necessary modules are active. A disabled module cannot be operated, even through a direct link. | Administrator or authorized platform management |
| Taxonomy model | Agree whether to use Domain → Entity → Attribute or the model with Subdomains. | Administrator with Data Owner |
| Technical sources | A Repository must be registered before a useful Technical Dictionary can be used. | Data Engineer |

Do not try to resolve permissions by changing browser parameters or use a role as a substitute for scope. Owners and Stewards work within their authorized Domains or Subdomains; the Data Engineer administers only Repositories with an assigned technical scope.

## Recommended path

1. **Define the first scope.** Choose a Domain whose language, responsible person, and traceability needs are recognizable. If the organization needs a stable subdivision, add Subdomains. Avoid creating an exhaustive structure before it can be used.

2. **Name responsible people and assign scope.** Document business responsibility and assign people the scopes that allow them to act. Distinguish the session role from a governance role: the former controls operational capability; the latter documents responsibility in the catalog.

3. **Build the vocabulary and business objects.** Document relevant Entities and Attributes and, if the module is active, add Business Terms to express shared definitions. Keep names readable for people; technical codes do not replace those names in the functional guide.

4. **Add technical context when available.** The Data Engineer registers the Repository within their scope and can synchronize metadata according to the company’s configuration. Then, the Technical Dictionary connects physical fields to catalog Attributes. Do not assume that every table or field from a source is already associated with a business object.

5. **Express controls and deliverables using existing objects.** A Quality Rule is associated with an Attribute and may be related to physical fields. Generating SQL requires both these valid associations and a configured dialect; it is not a promise of automatic execution. Assets, Products, and Contracts let you document what is delivered and which related attributes, terms, rules, fields, or systems apply when their modules and dependencies are available.

6. **Connect pending work.** Use the Workflows, requests, tasks, comments, classifications, or certifications that are enabled to maintain traceability of decisions and follow-up. Do not turn Risks or Controls into separate inventories: in the current model, they are represented through combinations of rules, policies/procedures, workflows, tasks, approvals, and stewardship objects.

7. **Review relationships before expanding.** The Relationship Explorer helps check an object’s context in Overview, analyze registered dependencies in Impact, and follow the physical link in Technical Detail. A missing line indicates that no relationship is registered; a dependency must not be inferred merely because objects share the same Domain.

> **Illustrative example:** for “Customers,” an initial delivery may include the Customers Domain, the Customer Entity, the “Registration date” Attribute, an Owner and a Steward with scope, and an associated technical field if it has already been documented. A rule or contract is added on that basis only when the corresponding module and relationship exist.

## Expected outcome

At the end of this path, the company should have an initial, navigable scope with documented responsibilities and scope, business objects with clear meaning, and, when incorporated, a verifiable technical link to fields and Repositories. The outcome is not a complete catalog, nor does it automatically certify quality, compliance, or process execution. It is a traceable foundation for expanding coverage without losing the context of each relationship.

If a metadata schedule is configured, it can be manual, daily, weekly, or monthly, and its snapshots are versioned. Check the effective configuration before relying on it: this path does not assume automated schedules or active production jobs.

## References for continuing

- [Object and relationship model](/en/explicaciones/modelo-de-objetos-y-relaciones/)
- [How to read the relationship map](/en/guias/como-leer-mapa-de-relaciones/)
- [Roles, capabilities, and scope](/en/referencia/roles-capacidades-y-alcance/)
- [Modules and dependencies](/en/referencia/modulos-y-dependencias/)