DataOps Platform

Data Product Blueprints

Reusable, versioned Git templates that standardize data product creation: define parameters, protect resources, compose modules, and instantiate to one or many repositories.

What is a Blueprint

The Blueprint module in Blindata enables organizations to standardize how data products are created, configured, and governed.

At a high level, it provides a self-service framework where reusable templates - called Blueprints - define how a data product should be built. Instead of starting from scratch every time, teams can rely on predefined, versioned templates that embed best practices, infrastructure setup, and governance rules.

What is a Blueprint?

A Blueprint is a reusable template, backed by a Git repository, that defines the structure and configuration of a data product.

It typically includes: Infrastructure definitions (e.g., IaC), pipeline configurations, governance and compliance settings, parameterized files that adapt to different use cases

Each Blueprint is versioned and repeatable, meaning it can be used multiple times to create consistent data products across teams.

When a Blueprint is used, it generates a new, fully configured data product by applying user-provided parameters to the template.

Key concepts

  • Blueprint: A reusable, versioned template published as a Git repository and made available in the Blueprint catalog.
  • Manifest: The central configuration contract of a Blueprint. It defines: required parameters, validation rules, UI configuration for input forms, Deployment and instantiation behaviord

Why blueprints matter

Blueprints help organizations:

  • Standardize how data products are built
  • Accelerate delivery through reusable templates
  • Embed governance by design
  • Reduce errors by enforcing validated configurations
  • Enable self-service for domain teams

They act as a bridge between platform engineering and domain teams, ensuring that best practices are applied without requiring every team to reinvent the setup.

Instead of manually setting up each new data product, teams can rely on well-designed Blueprints to:

  • Reduce setup time
  • Minimize errors
  • Enforce standards automatically
  • Empower domain teams with self-service capabilities

See how to develop a Blueprint for more information.

Blueprint Lifecycle

The blueprint lifecycle follows four main phases:

1. Register a blueprint

Register a new blueprint by linking it to a Git repository (existing or created on the fly from Blindata) and pointing Blindata to the manifest file. The Register a Blueprint guide covers the catalog UI and the registration wizard.

2. Publish versions

Once the blueprint is registered, publish versions - a version is a Git tag created from a branch, with a human-readable title and release notes. Only published versions can be instantiated; unreleased work-in-progress on branches stays invisible to Blueprint consumers.

3. Instantiate a data product

Blueprint consumers pick a blueprint version from the catalog and run the instantiation wizard. They choose a data product from the catalog or create a newly data product, configure the target repository (or repositories in polyrepo mode), and fill in the parameters declared by the manifest. Blindata renders the manifest, populates all templates with the provided values, and pushes the output to Git.

4. Update a data product

When platform engineers publish a newer blueprint version, the data product owner updates the existing data product onto that version. The update reapplies the template with the product’s parameters. Protected resources stay under policy enforcement : the owner may take the new version, and must not hand-edit the paths the blueprint protects.

Personas and permissions

Blindata assigns platform permissions to users. Those permissions decide what each persona can do in the Blueprint module. The notes below also say what each persona should do: who designs templates, who consumes them, who owns the shared label list, and who must respect protected files.

Global rules (apply before persona checks):

  • Users with DATAOPS_ADMIN bypass all DataOps authorization checks and have full access to Blueprints (and other DataOps services).
  • Users with BLUEPRINTS_ADMIN have full Blueprint module access beyond what viewer and editor roles allow.
  • Blueprint read and write are separate: BLUEPRINTS_VIEWER for browsing the catalog, reading blueprint content, and reading labels; BLUEPRINTS_EDITOR for register, publish, delete, assigning labels to a blueprint, and repository write operations.
  • Instantiate and update use the same platform permissions: BLUEPRINTS_VIEWER, DATAOPS_EDITOR, and DATA_PRODUCTS_EDITOR. An update also requires write stewardship on the data product’s team. DATAOPS_ADMIN can run the update without those individual checks. BLUEPRINTS_ADMIN bypasses Blueprint checks as well.

For the full permission definitions, see Blueprint Permissions and Users and Access .

Platform Engineer

Role: Builds and maintains blueprint definitions, versions, and Git integration. This is the primary blueprint developer persona.

Required permissions: DATAOPS_EDITOR, BLUEPRINTS_EDITOR, BLUEPRINTS_VIEWER, DATA_PRODUCTS_EDITOR

Can do:

  • Register, update documentation for, and delete blueprints, including which labels a blueprint carries
  • Initialize blueprint repository content, create repositories, and publish version tags
  • Publish blueprint versions, update version documentation, and delete versions
  • Browse the blueprint catalog, filter it by label, and read blueprint repository content
  • Instantiate a blueprint version into a data product
  • Update an instantiated data product to a newer blueprint version, when they also have write stewardship on that data product’s team

Cannot do: Create, change, or delete labels in the taxonomy. That requires BLUEPRINTS_ADMIN.

Data Product Owner

Role: Consumes the blueprint catalog and turns published versions into data products. This is the primary blueprint consumer persona. Does not manage blueprint definitions.

Required permissions: DATAOPS_EDITOR, BLUEPRINTS_VIEWER, DATA_PRODUCTS_EDITOR

Can do:

  • Browse the blueprint catalog, filter by label, read blueprint and version details, and inspect repository content
  • Instantiate a published blueprint version into a data product
  • Update an instantiated data product to a newer blueprint version, with write stewardship on that data product’s team

Cannot do: Register, publish, or delete blueprints or versions. Assign or manage labels. Change which files a blueprint protects.

Compliance Officer

Role: Read-only visibility across DataOps, blueprints, and data products for governance and audit.

Required permissions: DATAOPS_VIEWER, BLUEPRINTS_VIEWER, DATA_PRODUCTS_VIEWER

Can do:

  • Same read access as the Data Product Owner: catalog, labels, versions, and repository content

Cannot do: Instantiate or update a data product (that requires DATAOPS_EDITOR and DATA_PRODUCTS_EDITOR), assign or manage labels, or any write or delete operation. This persona is not the one bound by protected-resource checks, because they do not publish the data product.

Platform Administrator

Role: Platform-wide operator with unrestricted DataOps access. This persona owns the blueprint label taxonomy.

Required permissions: DATAOPS_ADMIN

Can do: Everything in the Blueprint module—register, publish, assign labels, instantiate, update a data product, and read—without the individual Blueprint permissions, because DATAOPS_ADMIN bypasses DataOps authorization. Creating and deleting labels is authorized the same way. Seeing and using Manage labels in the catalog still requires BLUEPRINTS_ADMIN.

Business Sponsor

Role: Business stakeholder with read-only data product visibility. Defined in the product model but not involved in blueprint workflows.

Required permissions: DATA_PRODUCTS_VIEWER

Can do in Blueprints: Nothing—no blueprint or DataOps permissions are assigned, so all Blueprint module actions are denied. This persona can use Dashboards and other areas scoped to data product visibility.

Persona quick reference

Persona Required permissions In the Blueprint module
Platform Engineer DATAOPS_EDITOR, BLUEPRINTS_EDITOR, BLUEPRINTS_VIEWER, DATA_PRODUCTS_EDITOR Register, publish, and delete blueprints and versions; assign labels; browse catalog; instantiate and update data products (team write); declare protected resources on blueprints
Data Product Owner DATAOPS_EDITOR, BLUEPRINTS_VIEWER, DATA_PRODUCTS_EDITOR Browse catalog; instantiate and update data products (team write); subject to protected-resource policy at publish
Compliance Officer DATAOPS_VIEWER, BLUEPRINTS_VIEWER, DATA_PRODUCTS_VIEWER Read-only: catalog, versions, labels, repository content
Platform Administrator DATAOPS_ADMIN Full Blueprint module access via DataOps bypass; label taxonomy changes still need BLUEPRINTS_ADMIN for Manage labels in the catalog
Business Sponsor DATA_PRODUCTS_VIEWER No Blueprint module access
Action Required permissions
View blueprints, versions, labels, repository content, and git-provider read operations BLUEPRINTS_VIEWER
Register blueprints, publish versions, update documentation, assign labels to a blueprint, and git-provider write operations BLUEPRINTS_EDITOR
Manage the label taxonomy (create, update, or delete labels) BLUEPRINTS_ADMIN
Instantiate a blueprint into a data product BLUEPRINTS_VIEWER, DATAOPS_EDITOR, DATA_PRODUCTS_EDITOR
Update an instantiated data product to a newer blueprint version BLUEPRINTS_VIEWER, DATAOPS_EDITOR, DATA_PRODUCTS_EDITOR, plus write stewardship on the data product’s team. DATAOPS_ADMIN can run the update without those individual checks.
Define protected resources No separate permission. Declared in the parent blueprint manifest and published with BLUEPRINTS_EDITOR.
Protected-resource policy check No extra Blueprint permission. The check stays off until the platform team turns the validator on. When it is on, it runs when a data product version is published, and the data product owner is bound by the result. Policy list and validation require DATAOPS_VIEWER and GOVERNANCE_POLICIES_VIEWER.

For details, see DataOps Platform – Users and Access .

How to Use This Guide

This guide walks you through the essential steps to build, publish, consume, and update blueprints in Blindata.

  • Develop a Blueprint - Learn the anatomy of a blueprint repository and the full schema of the YAML manifest (parameters, validation, UI metadata, protected resources, composition, instantiation strategies).

  • Register a Blueprint - Register a new blueprint in the catalog and wire it to a Git repository that hosts the manifest and templates. While registering, assign blueprint labels from the shared taxonomy so consumers can filter the catalog.

  • Publish a Blueprint version - Publish immutable versions of a blueprint from Git tags, add release notes, and make them available to Blueprint consumers.

  • Instantiate a Blueprint - Run the three-step wizard to create a new data product from a blueprint version, configure target repositories, and provide parameter values.

  • Update a Blueprint - Move an instantiated data product onto a newer published blueprint version.

  • Policy Enforcement - How blueprint developers declare protected resources, and how those rules are checked for data product owners.

In this section

Develop a Blueprint Anatomy of a blueprint repository and the complete specification of the YAML Blueprint Manifest: parameters, validation, UI hints, protected resources, composition, target repositories, and instantiation routes. Register a Blueprint Register a blueprint or blueprint module in the Blindata catalog, assign catalog labels, and wire it to a Git repository that hosts the manifest, templates, and supporting content. Publish a Blueprint Version Release version management for blueprints: publish immutable versions from Git tags, add release notes, and make them available for instantiation. Instantiate a Blueprint Create a new data product from a blueprint version: pick a data product, configure target repositories, and fill in the manifest parameters using the three-step wizard. Update a Blueprint Bring an already instantiated data product forward to a newer blueprint version on an update branch, review parameter changes, and merge them through a pull request. Policy Enforcement Mark files in generated data product repositories as protected so governance and compliance guardrails survive team edits, and see how publication checks enforce them.

Updated on 08 Oct 2026