Blueprint Governance

Blueprint governance protects reporting consistency. Without it, teams create multiple versions of the same report type, lose track of which template is current, and produce outputs that diverge from stakeholder expectations.

This page defines the change control procedure, versioning triggers, decommissioning checklist, and metrics for maintaining a healthy blueprint library.

Blueprint lifecycle stages

Stage	Description	Who acts
Draft	Blueprint is being designed, not yet in use	Blueprint Owner, Designer
Published	Active — editions can be created	Blueprint Owner
Versioned	A new version published; prior version deprecated	Blueprint Owner
Archived	Retired — no new editions can be created	Blueprint Owner, Workspace Admin

Change control procedure

Before publishing any change to a live blueprint, assess the impact:

Step 1 — Classify the change

Change type	Examples	Impact
Minor	Field label, help text, default value, option label rename	No data impact. Safe to publish anytime.
Moderate	Add non-required field, add section, add option to a Select list	Existing editions unaffected. New editions get the updated field.
Major	Add required field, remove field, restructure section order, change field type	Impacts editions in progress. Requires cycle coordination.

Step 2 — Check active edition status

Go to the blueprint → Editions tab.
Filter by status: Draft, Submitted, In review, Changes requested.
Any editions in these states are "active" — contributors and reviewers are working on them.

Step 3 — Coordinate timing

Change type	Timing guidance
Minor	Publish immediately — no coordination needed
Moderate	Notify contributors via comment or external channel before publishing
Major	Wait for all active editions to reach Approved or Closed, then publish

Step 4 — Publish the change

Make the change in the blueprint design view.
Click Publish → write a version note describing the change.
The version note is stored in the blueprint's Version history tab.

Step 5 — Notify stakeholders

For moderate and major changes, send a notification to all project contributors and reviewers explaining:

What changed
Why it changed
How it affects their next edition

Versioning — when to create a new version vs. edit in place

Use in-place editing (edit the published blueprint) for:

Field label and help text updates
Adding options to a Select or Multi-select list
Adding non-required fields
Adding sections

Use a new blueprint version when:

A required field is added or removed
Section order changes materially
An existing field's type changes (e.g. Text → Select)
The report structure changes to the point where the output template needs redesigning

Creating a new blueprint version:

Open the blueprint → click Create new version.
This duplicates the blueprint with "(v2)" appended to the name.
Redesign the new version without affecting the current published version.
Publish the new version.
Archive the old version once all active editions are complete.

Duplicate blueprint policy

Duplication is appropriate when:

Reason	Example
Different audience	One blueprint for client reporting, one for internal PMO
Different structure	Construction report and commercial report have different sections
Different project type	Infrastructure blueprint vs. fitout blueprint

Duplication is not appropriate when:

Reason to avoid duplication	Better alternative
"I want a backup"	Use version history — the blueprint change log is the backup
"I'm not sure if my changes will work"	Use a Draft blueprint for testing
"Each project lead wants their own template"	Standardise — offer a shared blueprint and use project-level field defaults

When you do duplicate, suffix the name clearly: Monthly Progress — Client and Monthly Progress — Internal rather than two copies with similar names.

Decommissioning a blueprint

When a blueprint is no longer needed:

Decommissioning checklist

Confirm with the Blueprint Owner that this blueprint will not be used for future editions
Check all editions in this blueprint are in Approved or Closed status (no active editions)
Verify no active outputs or scheduled exports reference this blueprint
Export a CSV summary of all editions for archival records (optional)
Archive the blueprint: open the blueprint → Blueprint settings → Archive
Notify project members that this blueprint is no longer active

Archive vs. delete

Action	Effect	When to use
Archive	Blueprint removed from the active list; existing editions and outputs preserved	When decommissioning but historical data must be retained
Delete	Blueprint and all editions permanently deleted	Only for test blueprints with no real data

caution

Deleting a blueprint cannot be undone. All editions, outputs, and audit history for that blueprint are permanently removed. Archive instead of delete in almost all cases.

Restoring an archived blueprint

Go to Workspace Settings → Blueprints → filter by Archived.
Click the blueprint → Restore.
The blueprint returns to Published status and editions can be created again.

An audit log entry records who restored the blueprint and when.