Introduction to Blueprint Designer

Blueprints

A blueprint is a high-level container used to organize and store governance templates. It houses a collection of blueprint versions, allowing you to maintain multiple configurations within a single structure to meet specific regulatory or organizational needs.

For example, a single blueprint can host distinct versions for GxP Compliance (Life Sciences) or the EU AI Act (Risk Assessment).

Types of blueprints

There are three primary categories of blueprints available:

  • Govern blueprints: Used for Standard Govern items such as business initiatives, projects, bundles, models, and model versions.

  • Dataiku blueprints: These embed information directly from the Dataiku Design and the Dataiku Deployer nodes to surface them within the Govern interface. To view Dataiku blueprints, click the three dots button and ensure the “Display locked blueprint” checkbox is selected.

  • Custom blueprints: You can create new types not related to Dataiku items or existing artifacts if you want to track specific workflows or external information.

Managing blueprints

Within the Govern node, you have full control over how blueprints are handled. The primary actions include:

  • Create: Build a new blueprint from scratch to fit your specific governance needs.

  • Import: Upload a JSON blueprint provided by Dataiku or exported from a different Govern node.

  • Export: Save a blueprint as a JSON file to share it or migrate it between environments.

  • Edit: Modify existing blueprints to update their structure or metadata as your requirements evolve.

Blueprint versions

A blueprint version is the actual template applied to Govern items. It determines exactly what information is collected, which workflows are followed, and how metadata is stored for artifacts like business initiatives, projects, or models.

Lifecycle status

To maintain control over your governance standards, every version follows a specific lifecycle:

  • Draft: The template is under construction and cannot be used yet.

  • Active: The version is live and available for use. Only Active versions can be applied to items.

  • Archived: The template is retired; it remains in the system for historical items but cannot be applied to new ones.

  • Delete: Permanently remove the version (only available if not in use).

Creating Blueprint versions

Every blueprint version must reside within a parent blueprint. When creating a new version, you can choose from three primary paths depending on your needs:

  • Import (JSON): This is often the simplest method for quickly deploying a template. You can upload a blueprint version JSON file provided by Dataiku or one exported from another Govern node.

  • Fork: Duplicate an existing blueprint version to preserve built-in logic. You can choose to Fork a System Blueprint (built-in logic) or Fork a Custom Version (previously created).

  • Blank Template: Create a blueprint from scratch. This starts with a completely empty schema and is recommended for advanced users only.

Note

Best Practice: It is strongly advised to start by copying an existing blueprint version. Many versions contain “under-the-hood” fields and workflow steps such as sign-off logic or reviewer settings that are essential for Govern to function correctly.

Once a version is created, you can manage its lifecycle through several actions:

  • Edit: Refine the fields, layouts, or workflows.

  • Export: Save the version as a JSON file for backup or migration.

Handling changes via Migrations

As your governance requirements evolve, you may need to move items from an older blueprint version to a newer one. This is handled through Migrations.

Migrations allow you to map data elements (fields, statuses, etc.) from a source version to a target version, ensuring continuity. Within the Blueprint Designer, you can:

  • Script a new migration: Define the logic and field-mapping rules to transition items safely.

  • Edit a migration: Adjust existing mapping logic if requirements change during the transition period.

  • Remove a migration: Delete migration scripts that are no longer needed or were created in error.

You can learn how to apply a migration in this how-to.

Caution

Migrations can only be applied to blueprint versions within the same blueprint. You can not migrate across blueprints.