About the 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.

Understanding the User Personas

Blindata assigns platform permissions to users; those permissions define what each persona can do in the Blueprint module. The sections below map each persona to the permissions they need and the Blueprint actions they can perform.

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 and reading blueprint content; BLUEPRINTS_EDITOR for register, publish, delete, and repository operations.

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
• Initialize blueprint repository content, create repositories, and publish version tags
• Publish blueprint versions, update version documentation, and delete versions
• Browse the blueprint catalog and read blueprint repository content
• Instantiate a blueprint version into a data product

Data Product Owner

Role: Consumes the blueprint catalog and instantiates 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, read blueprint and version details, and inspect repository content
• Instantiate a published blueprint version into a data product

Cannot do: Register, update, or delete blueprints or versions.

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, versions, and repository content

Cannot do: Instantiate blueprints (requires DATAOPS_EDITOR and DATA_PRODUCTS_EDITOR), or any write or delete operation.

Platform Administrator

Role: Platform-wide operator with unrestricted DataOps access.

Required permissions: DATAOPS_ADMIN

Can do: Everything in the Blueprint module—all register, publish, instantiate, and read operations—without needing individual Blueprint permissions.

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

Init, Publish & Instantiate

The blueprint lifecycle follows three 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. A three-step wizard collects the Data product information, the blueprint identity and the repository settings that Blindata will use to read the manifest.

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.

The Blueprint catalog

The Blueprints page is the catalog for your organization. It lists every registered blueprint with name, short description, and a direct link to the detail page.

Open a blueprint to reach its detail page. The header shows the blueprint name, creation/update timestamps, a version selector (defaulting to the latest release), and the actions available to the current user.

The detail page exposes two tabs:

• Documentation - Renders the README.md shipped with the selected blueprint version. Use this as the primary place to describe what the blueprint provisions, its pre-requisites, and any post-instantiation steps.

  

• Parameters - Renders, from the manifest, every parameter the user must provide at instantiation time, grouped by the ui.group values declared in the manifest. Each row shows the description, type, default value, required/optional flag, and validation rules.

  

From the top right you can:

• Switch version - Pick any published version of the blueprint; the Documentation and Parameters tabs re-render against the selected version.
• ALL VERSIONS - Jump to the versions list for the blueprint (see Publish versions ).
• CREATE DATA PRODUCT - Start the instantiation wizard with the current blueprint and version pre-selected.

Permissions

For details, see DataOps Platform – Users and Access . For how permissions map to product personas, see Understanding the User Personas .

How to Use This Guide

This guide walks you through the essential steps to build, publish, and consume 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.

• 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.