Stewardship brings together the ongoing work that keeps the catalog understandable and accountable: Owner and Steward assignments, tasks, comments, favorites, classifications, and certifications. It does not create a parallel taxonomy. Each intervention is handled in relation to an object and its context, so Domain, Subdomain, Entity, or Attribute continue to serve as the reference for navigation, responsibility, and authorization.
The stewardship panel lets users track work and coverage. The dashboard aggregates company-level indicators and history and applies the relevant scope filters. Risks and Controls are not independent catalogs: they are represented through existing objects and their relationships.
Before you start
- Role: The Data Steward maintains definitions, tasks, comments, classifications, and certifications within their Domains or Subdomains. The Data Owner approves decisions when required. A User participates in permitted tasks. The Administrator has global scope within their company; the Data Engineer operates Repositories under technical scope, not under an implicit taxonomic scope.
- Module: Verify that the modules exposing the object to be worked on are enabled. A disabled module is hidden and rejects operations on it, even if its data is retained. Stewardship operations do not bypass this validation either.
- Preconditions: Identify the target object, its company, and its taxonomic relationship. Confirm the Owner or Steward assignment when relevant, the required capability, and the current scope. A person may be able to view more than they can modify or approve.
A governance role expresses responsibility for objects; the session profile, together with capability and scope, determines whether a person can perform the action.
Recommended workflow
- Start with the object and its context. Locate the Domain or Subdomain and navigate down to the object that needs attention. For an Attribute, review quality rules and technical fields; for a Repository, do not assume that all its fields are associated.
- Confirm who should act. Compare the recorded business responsibility with the session role and effective scope. A Steward can prepare and maintain information; an Owner makes decisions when the process requires approval. Assignments do not authorize action outside the authorized scope.
- Turn the pending work into traceable work. Create or handle the permitted task, record a comment when it adds context, and use favorites to prioritize objects to follow up on. If the work requires a formal decision, link it to the corresponding Workflow or case instead of representing the decision only in a comment.
- Maintain governance signals. Apply or review classifications and certifications in accordance with authorization. They support tracking, but do not replace the taxonomic association or prove a physical condition of the source.
- Approve and review. When governance requires it, the Owner or another person with
stewardship.approvemakes the decision within their scope. Review the result in the panel and, to investigate dependencies, use the relationship map: a line represents a recorded link, and its absence must not be made up through inference. - Connect coverage and improvement. Use tasks, certifications, and classifications to guide coverage. SQL requires an associated physical field and a configured dialect; its execution is not part of the documented stewardship process.
Synthetic example. A Steward notices that a relevant attribute does not have a sufficiently detailed description. They review the Entity context, leave a work comment, and prepare an update within their Domain. If the company requires confirmation, the corresponding Owner approves the decision and the applicable certification is recorded. The example does not assume values, states, or a certification cadence.
Expected outcome
The object retains its business context and verifiable signals: responsible parties, a task or intervention, comments, classifications, certifications, and, where appropriate, an approval or Workflow case. The company tracks pending work and coverage without confusing business definitions, technical relationships, and operational decisions.
Actions remain within the company and the scope of the person performing them; indicators do not expose objects outside the applicable policy; the backend retains final authority over permissions.
Limits of current behavior
- This guide does not list task or certification states, renewal dates, forms, escalation rules, or review frequencies because they are not documented as a common contract.
- Classifying or certifying does not by itself create a Quality Rule, Policy, or technical Control. Risks and Controls are not independent catalogs in the current model.
- The metadata synchronization schedule can be manual, daily, weekly, or monthly and retains versioned snapshots, but its scheduling and effective automation depend on configuration; do not assume that production jobs are enabled.
- A Data Engineer's technical scope is independent of Domain or Subdomain scopes. Work on connectors, repositories, and metadata requires the corresponding technical authorization.