Blueprint Phase

The blueprint is the structured plan that bridges the conversation in context gathering with the concrete assets that get generated and deployed. It is the project’s load-bearing document — once you approve it, every downstream asset is generated to match.

This page explains what the blueprint contains, how to edit it, and the approval mechanics.

What’s in a Blueprint

A blueprint is a single coherent description of the implementation, structured into five sections.

Object Families

The CRM objects the implementation uses, grouped by their role in the business. A typical blueprint contains object families such as:

• Sales — Contacts, Companies, Deals
• Service — Tickets, custom objects for renewals or escalations
• Operations — custom objects for projects, accounts, integrations

For each object, the blueprint shows:

• The HubSpot object type (standard or custom)
• The properties it gains (with field type, group, and option lists where relevant)
• Its lifecycle, if it has one
• The associations it participates in

Properties

A flat list of every custom property the implementation needs, with:

• Name and internal name (auto-derived; you can override)
• Field type — string, number, enum, date, datetime, etc.
• Property group — the HubSpot sidebar group it lives in
• Options — for enum fields, the allowed values
• Description — why the property exists, surfaced in the HubSpot UI tooltip
• Source — derived for properties whose value is set by automation, manual for ones the user fills in

Built-in HubSpot properties (hs_*, standard CRM fields) are referenced but not listed here — Jetty only lists what it is going to create.

Lifecycle Stages

For each object that has a lifecycle (Contacts, Deals, Tickets, custom objects), the blueprint defines the ordered stages and what triggers transitions between them. Example for Contacts:

Subscriber → Lead → MQL → SQL → Opportunity → Customer → Evangelist
                ↑                  ↑
        Form fill +        Demo booked
        Marketing email   in calendar

The transitions become the trigger criteria for the workflows generated later.

Automations

A summary of the workflows, lists, sequences, and forms the implementation needs to operate. Each automation lists:

• Type — workflow / static list / dynamic list / sequence / form
• Purpose — one-line description of what it does
• Trigger — the event or filter that initiates it
• Outcome — the lifecycle stage, property change, or notification it produces

The blueprint does not generate the full workflow logic at this stage — that happens in Asset Generation. The blueprint only commits to what automations exist and what each one is for, so the generated assets stay consistent with the overall design.

Outcomes

The measurable business results the implementation is designed to produce. Each outcome traces back 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 lets Jetty know which assets are load-bearing for which goals — and lets you, the reviewer, confirm the implementation actually delivers what was discussed in context gathering.

Editing the Blueprint

You can change the blueprint in three ways. Use whichever feels right for the size of the change.

Inline Edits

Click any item in the Blueprint tab. You can:

• Rename an object family, property, lifecycle stage, automation, or outcome
• Edit a description to clarify intent before generation runs
• Reorder lifecycle stages by dragging
• Add or remove enum options on a property
• Delete an item if it should not be in the implementation

Inline edits update the blueprint immediately. They do not require a regeneration trigger.

Chat Instructions

For structural changes — adding an entire object family, splitting one stage into two, swapping a property type — type the change as a chat instruction:

“Add a Service Hub ticket pipeline with stages New, In Progress, Waiting on Customer, Resolved, and a workflow that auto-assigns by region.”

Jetty edits the blueprint and confirms what changed. You can then keep iterating in chat or move to approval.

Regenerate from Scratch

If the conversation in context gathering led to a fundamentally different direction than the blueprint reflects, you can ask Jetty to regenerate the whole blueprint:

“Throw this away and start from the new revenue model we just discussed.”

Regenerating starts from the same project context (chat history + uploaded documents), so anything you have told Jetty so far is preserved. It only replaces the structured output.

The Approval Step

Once the blueprint looks right, click Approve Blueprint in the Blueprint tab toolbar.

Approval does three things:

1. Locks the blueprint structure. Inline edits and chat refinements are still possible after approval, but Jetty uses the snapshot taken at approval time as the source of truth when generating assets.
2. Records the approval timestamp. The Blueprint tab shows the approved banner and the time, so you have a clear record of when the design was committed.
3. Triggers asset generation. Within a few seconds Jetty starts producing concrete HubSpot assets that match the blueprint. The Assets tab activates with a live progress strip.

Approval is the inflection point

Edits made before approval are quick — you are only changing a document. Edits made after approval can mean regenerating one or more assets, which takes a few extra moments. The blueprint phase is the right place to slow down and review carefully.

Approving an Incomplete Blueprint

You can approve a blueprint that does not yet cover every business outcome you discussed. Jetty will produce assets for everything the blueprint specifies, and you can come back and add more later.

Two common reasons to approve incrementally:

• You want to see a slice first. Approving a subset (e.g., the sales motion only) lets you review generated assets while you continue designing the service or marketing side in the same project.
• One area is well-defined; another is exploratory. Lock in the parts you are confident about, deploy them, and iterate on the rest as a follow-up.

To add to an approved blueprint later, edit the blueprint in the Blueprint tab and trigger another generation pass — only the new or changed items will be regenerated.

Re-Approving After Changes

If you change the blueprint after approval (in chat or inline), the Blueprint tab shows a “Changes pending re-approval” banner. Click Approve Changes to commit the new state and re-trigger generation for the affected assets. Unchanged assets are left in place.

This pattern — approve, generate, review, edit, re-approve — is the iterative loop the project workspace is built around. Most projects go through it two or three times before the asset list is exactly right.

Next Steps

• Asset Generation — What happens after you approve
• Deployment Phase — Deploying the generated assets to HubSpot
• Troubleshooting & Gotchas — What to watch for during blueprint design