Ethan McNamara

Engineering · Product architecture

Blueprint

Evolve the template. Preserve the choices.

Concept 42s film 5 stages · 2 paths Illustrative data

01

In plain English

What it is
Reusable project plans that can improve over time while keeping the changes each team has made.
How it works
A team would start from a template and customise it. When the template changes, Blueprint would preview the update, keep the team’s choices, and ask about anything unclear.
Why it matters
To share better ways of working without undoing local decisions.

02

The product film

A better plan. Still your plan. A task, a deliberate gesture and its result, inside a reconstructed Signal Studio. It plays on its own while it is on screen; pause it, scrub it, slow it down, or read it as stills.

Scene rendered by preview-review-blueprint.js · 42s · 4 beats · 3 stills

03

What it is worth

A better starting point. Still your team’s call.

When someone finds a better way to run a project, everyone should be able to benefit. Preview improvements to the shared plan, bring in what helps, and keep the decisions your team has already made.

  • Build on shared experienceStart with a plan the team can improve together.
  • Choose what helpsReview each improvement before bringing it in.
  • Keep your team’s decisionsPreserve the dates and details you’ve agreed.

04

How it is built

A template improves; a team has already customised it. The gesture shows the merge being previewed rather than applied — the moment where a person can still say no.

ease-out cubic
cubic-bezier(0.33, 1, 0.68, 1)
Template changes arrive
2400ms
Local choices are held
2500ms
The unclear part is asked about
2700ms

Three layers move at once — incoming, local, and merged — so the animation has to make ownership legible at a glance. Each layer keeps its own colour and its own vertical band; nothing crosses.

The unresolved item does not resolve. It sits there at the end of the film, asking a question. A demonstration that closed it would be selling a merge tool that cannot exist.

The whole sequence is transform and opacity only. On a mid-tier phone it holds frame rate because there is nothing for the browser to lay out.

05

The working model

The original default explains intent: an inherited field may evolve, an override stays, and a deliberate removal is remembered.

The boundary that matters Blueprints provide supported configuration. Apply only a validated preview against the project revision that the owner reviewed.

Two paths: Standard flow and Project changes during preview · 5 stages each

06

How it fits together

A person acts, the system checks, a result follows — and one other path, for when the check does not pass. This describes proposed responsibilities and decisions, not deployed infrastructure.

Read the diagram source
%% Director-friendly architecture. Maturity and limits are recorded in accDescr.
flowchart TB
  accTitle: How Project Blueprint works
  accDescr: A project owner requests an updated template. A proposed comparison shows new defaults while preserving customer changes and deliberate removals. The owner approves a preview. Signal applies it only if the project still matches what was reviewed; later changes require a fresh preview. Existing template foundations do not establish this proposed update workflow.
  A(["Project owner<br/>Requests a template update"])
  B("Update preview<br/>Personal changes stay protected")
  C(["Project owner<br/>Approves the preview"])
  D{"Project unchanged<br/>since preview?"}
  E("Updated project<br/>Approved changes only")
  X("Project changed<br/>Review a fresh preview")
  A --> B
  B -->|Changes explained| C
  C --> D
  D -->|Still current| E
  D -->|Changed meanwhile| X
  classDef human fill:#faf7f2,stroke:#bf8c53,color:#24211c;
  classDef work fill:#ffffff,stroke:#a3a5ad,color:#25262a;
  classDef decision fill:#f3efff,stroke:#967bcb,color:#30244c;
  classDef result fill:#f0f6ff,stroke:#7b9dca,color:#1d365b;
  classDef exception fill:#fff5ec,stroke:#ce9b63,color:#64431e;
  class A,C human;
  class B work;
  class D decision;
  class E result;
  class X exception;

07

The case study

A reusable project template becomes architecture when it can evolve without erasing customer intent.

The problem

Copying a template is easy. Updating it after customers change dates, rename milestones, or remove tasks is harder: a blanket update overwrites decisions, while never updating leaves every project permanently forked.

The insight

Keep the original defaults as well as the current values. The difference between those states reveals which fields still inherit a default and which represent a customer decision.

The system

Templates and relative dates provide an existing foundation. The proposed versioning layer compares immutable blueprint definitions, the original defaults, and the customised project. Inherited values can advance; overrides remain. Conflicts, removals, and new relationships appear in a preview applied against a checked project revision.

The rationale

Shared behaviour can serve different audiences without cloning an entire product. Explicit evolution rules reduce the hidden support burden of maintaining many customised projects.

Responsibilities

Versioned defaults
Immutable definitions with stable task and milestone IDs.
Project provenance
Inherited values, overrides, and deliberate removals remain distinguishable.
Upgrade preview
Three-way comparison explains changes and surfaces conflicts.
Validated apply
Commit only against the project revision the user reviewed.

The boundary

Blueprints define supported configuration, not arbitrary executable customer code. The engine validates the resulting project and owns the rules that configuration cannot override.

The trade-off

Provenance and three-way comparison add data and migration complexity. That cost buys understandable upgrades; uncertain intent should become an explicit choice rather than an aggressive automatic merge.

When it fails

A customer changed the date

Keep the override when the blueprint default moves. Show both proposed and retained values so the upgrade explains its effect.

A task was deliberately removed

Record an explicit removal marker. Do not re-create the task during an upgrade merely because its stable ID appears in the new blueprint.

The project changes during preview

Reject an apply request against a stale project revision. Recalculate the upgrade so approval always refers to the changes that will actually be committed.

Evidence Design proposal · local demonstration uses synthetic data