Solution Blueprint

The Solution Blueprint is the project’s design document: a single coherent description of the HubSpot implementation the engagement is building, derived from Project Knowledge. It is a document you consult and refine, not a gate you approve — generation is authorized per Release, never by the Blueprint itself.

What’s in a Blueprint

Object Families

The CRM objects the implementation uses, grouped by their role in the business — Sales (Contacts, Companies, Deals), Service (Tickets, renewal objects), Operations (custom objects for projects, accounts, integrations). For each object: its type (standard or custom), the properties it gains, its lifecycle if it has one, and the associations it participates in.

Properties

Every custom property the design calls for, with name and internal name, field type, property group, enum options where relevant, and a description of why it exists. Built-in HubSpot properties (hs_*, standard CRM fields) are referenced but not listed — the Blueprint only specifies what will be created.

Lifecycle Stages

For each object with a lifecycle, the ordered stages and what moves a record between them. These transitions become the trigger criteria for workflows generated later.

Automations

The workflows, lists, sequences, and forms the design needs — each with its type, purpose, trigger, and the outcome it produces. The Blueprint commits to what automations exist and why; the concrete logic is generated inside a Release.

Outcomes

The measurable business results the design serves, each traceable to the assets that support it:

Outcome: Sales leaders can see SQL conversion rate per rep per week. Requires: Lifecycle stage SQL, property Sales Owner, workflow Set SQL Date on stage entry, dashboard Rep SQL Performance.

This trace is what lets you confirm the design actually delivers what was discussed — and what lets Release planning tie every change back to a requirement.

The Blueprint Lifecycle

The Blueprint moves through a small set of states, always visible in the workspace:

State	Meaning
Deriving	The workspace is composing a new version from current Project Knowledge
Current	The Blueprint reflects the latest published knowledge
Update available	The brief has changed since this version was derived — bring it current when ready
Failed	The last derivation hit an error; retry from the Blueprint view

There is no approval, no lock, and no snapshot-at-approval semantics. When you want the design brought up to date with new knowledge, trigger the update; until then, the current version stays honest about being behind.

Version History and Provenance

Every derived Blueprint is a version, kept forever:

• The version history shows when each version was derived and what it was derived from — which knowledge version, and what changed.
• Any past version opens read-only, so you can see exactly what the design said at any point in the engagement — useful when a client asks “why did we build it this way?”
• Versions are never edited in place; refinement produces a new version.

Refining the Blueprint

The Blueprint improves the same way the brief does — through knowledge:

• Talk to Jetty. “The renewals motion needs its own pipeline — separate it from new business.” Jetty updates the design through the knowledge → derivation path, so the change is attributable like everything else.
• Answer open decisions. If the design is generic, it is almost always because the brief is thin. Resolving open questions and conflicts in the Knowledge review sharpens the next derivation more than any direct edit would.
• Add sources. A single uploaded process doc or transcript often reshapes a whole section of the design.

How the Blueprint Feeds Releases

When a Release is planned, its changes are pinned to the Blueprint version that informed them — so a Release in flight is not destabilised by a design update landing mid-delivery. New Releases pick up the current version. If the Blueprint moves significantly while a Release is still in planning, re-plan the Release to pull in the new design.

Next Steps

• Releases — Where the design becomes portal changes
• Project Knowledge — The brief the Blueprint derives from
• Troubleshooting & Gotchas — What to watch for during design