Skip to main content

Governance Model

Qarion's approach to data governance is built around a layered role system that assigns clear responsibilities at every level — from the platform as a whole, down to individual data products. This page explains each layer, how roles interact, and how to manage governance assignments through the API.

Governance Pillars​

The governance model is organized along three dimensions, each addressing a different scope of authority:

  1. Platform Roles control system-level access, determining who can administer the platform itself.
  2. Space Roles define what a user can do within a specific workspace — browsing, editing, or managing settings and members.
  3. Governance Roles assign accountability for individual data products, ensuring every asset has a clear owner, quality steward, and technical custodian.

These three layers work together to create a comprehensive governance structure. A user's effective permissions are the combination of their platform role, their membership and role within each space, and any governance roles they hold on specific products.

Platform Roles​

Platform roles span the entire organization and are independent of any individual space.

Superadmin​

Superadmins are platform-wide administrators — typically the data platform team lead or a small number of infrastructure engineers. They can create and manage spaces, administer users across the entire organization, access the admin panel and global settings, and override any permission when necessary. Because of the breadth of this role, most organizations limit it to one to three people.

Regular User​

Every other user is a Regular User. Their capabilities are determined entirely by the spaces they belong to and the roles they hold within those spaces. Regular users can access any space they've been invited to, perform actions permitted by their space role, and manage their own profile and API keys.

Space Roles​

Space roles define what a user can do within a specific workspace. Qarion supports three levels, each building on the previous one:

RoleViewCreate/EditManage Space
Viewer✓✗✗
Editor✓✓✗
Admin✓✓✓

Viewer​

Viewers have read-only access, which makes this role suitable for business analysts exploring available data, stakeholders reviewing data quality dashboards, or new team members who are still learning the data landscape. Viewers can browse the data catalog, view product details and documentation, search and discover data, and submit access requests for datasets they want to use.

Editor​

Editors are content creators and data practitioners. In addition to everything a Viewer can do, Editors can create and edit data products, add quality checks, create and manage issues, and update documentation. This role is typically assigned to data engineers registering new products, analysts documenting their datasets, and QA teams setting up quality monitoring.

Admin​

Admins handle workspace management and governance. Beyond Editor capabilities, they can invite and remove members, manage source system connections, configure space settings, and assign governance roles to products. Team leads managing their domain and data governance officers overseeing policies are the most common holders of this role.

Governance Roles​

Governance roles operate at the product level, assigning specific accountability for individual data assets. Every data product should have all three roles filled to ensure clear ownership and avoid ambiguity when issues arise.

Owner​

The Owner is the business stakeholder who is ultimately accountable for a data product. They define business requirements, approve access requests, make decisions about data usage, and bear accountability for data quality. In practice, this is usually the product manager for the data domain, a business unit leader, or the domain expert who best understands the data's purpose and audience.

Steward​

The Steward is responsible for data quality and standards on a day-to-day basis. They define quality rules and thresholds, review and resolve data issues, maintain documentation, and ensure compliance with organizational standards. Stewards are typically data analysts within the relevant domain, quality engineers, or subject matter experts who understand the data deeply enough to set meaningful quality expectations.

Custodian​

The Custodian is the technical operator responsible for the infrastructure behind a data product. They manage pipelines and ETL processes, handle schema changes, resolve technical issues, and maintain access controls and security. This role is most commonly held by data engineers, platform engineers, or DataOps practitioners.

Role Assignment via API​

Assign Governance Roles​

You can programmatically assign or update the governance roles for a data product by sending a PUT request with the user IDs for each role:

PUT /catalog/spaces/{slug}/products/{id}/governance
{
  "owner_id": "user-uuid-1",
  "steward_id": "user-uuid-2",
  "custodian_id": "user-uuid-3"
}

Query by Governance Role​

To find all products where a specific user holds the Owner role, use the owner_id query parameter on the products list endpoint:

GET /catalog/spaces/{slug}/products?owner_id={user_id}

This is useful for building dashboards that show a user's governance portfolio — all the products they are accountable for across a space.

Permission Inheritance​

Permissions flow through the hierarchy, with higher-level roles inheriting the capabilities of lower-level ones:

Superadmin (platform-wide)
    ↓
Space Admin → Space Editor → Space Viewer
    ↓
Owner / Steward / Custodian (per product)

There are three important rules to keep in mind. First, higher roles inherit all permissions from lower roles — an Admin can do everything an Editor can, and an Editor can do everything a Viewer can. Second, governance roles add product-specific capabilities on top of space roles; being a product Owner does not automatically grant Admin-level permissions elsewhere in the space. Third, space isolation is strict — membership in one space grants no access whatsoever to another space's resources.

Access Request Workflow​

The access request workflow is where governance roles have their most visible impact. When a user requests access to a data product, the platform routes the request to the product's Owner for approval. The Owner may approve the request directly, delegate the review to the Steward, or reject it:

This flow ensures that every access decision passes through someone who understands the data's sensitivity and the requester's justification — rather than relying on blanket rules or unaccountable automation.

Best Practices​

Assign All Three Roles​

Every data product should have an Owner for business decisions, a Steward for quality oversight, and a Custodian for technical operations. Leaving any of these roles unfilled creates ambiguity about who is responsible when problems arise — and in data governance, ambiguity almost always leads to neglect.

Use Consistent Patterns​

Standardize how you assign governance roles across your organization. Common patterns include assigning roles by team structure (the team lead is always the Owner), by data domain (the domain expert is the Steward), or by product tier (Gold-tier products always have a dedicated Custodian). Consistency makes it easier to audit assignments and onboard new team members.

Document Responsibilities​

Make sure governance role expectations are clearly documented in your organization's data governance policy. The platform-level definitions provided here are general — your organization should define what "quality oversight" and "business accountability" mean concretely in your context.

Conduct Regular Reviews​

Periodically audit your governance assignments. After organizational restructuring, roles may no longer reflect the actual lines of responsibility. Departing employees may still be listed as product owners. And new products may have been created without any governance assignments at all. Scheduling quarterly reviews helps catch these gaps before they cause problems.