Engineering · Product architecture
Blueprint
Evolve the template. Preserve the choices.
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.
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