Releases

A Release is how a project changes a portal. Instead of one project-wide generate-and-deploy pass, work is delivered in bounded units: each Release has a confirmed outcome and acceptance criteria, a reviewed plan of changes, generated asset specs, an explicit authorize step before anything touches HubSpot, and per-asset verification after it does.

This page covers the Release lifecycle, what generation produces, and how to review and edit the results.

The Release Lifecycle

1. Create. Open the Releases tab and create a Release around one outcome — “Stand up lead routing,” not “assorted changes.” Small Releases review faster, apply faster, and verify cleaner.
2. Confirm the outcome. The Release’s outcome and acceptance criteria are confirmed up front. This is the contract everything downstream is checked against.
3. Plan. Jetty translates the outcome — grounded in Project Knowledge, the Blueprint, and the live Canvas — into concrete changes: assets to create, assets to update. Every accepted requirement gets an explicit disposition in the plan; a requirement that cannot be executed automatically stays visible for review instead of silently disappearing.
4. Generate. Jetty produces a full, reviewable spec for every asset in the plan, in dependency order (data model first, then structural assets, then behaviour, then reporting). Generation runs in the background — leave and come back whenever.
5. Authorize. Nothing has touched the portal yet. Review the specs, check the target mode (sandbox or production), and authorize the apply. This is the only step that grants Jetty permission to change the portal, and it is always yours.
6. Apply. Assets deploy in dependency order via the two-path deploy — see Deployment & Verification.
7. Verify. The portal is read back and each asset is checked against its spec. Every row carries its verbatim HubSpot outcome and the strength of the verification evidence.
8. Complete. A Release closes when its acceptance criteria are met. The record — plan, specs, outcomes, verification — stays in the Release’s history permanently.

The Release Workspace

Each Release has four tabs plus its own chat panel:

Tab	What it holds
Overview	The outcome, acceptance criteria, status, and owner
Changes	The planned changes, each traceable to the requirement it serves
Delivery	The apply surface: per-asset rows, deploy state, outcomes, verification
History	Everything that has happened in this Release, in order

The Release chat is scoped to the Release — ask Jetty about a specific change, request a spec revision, or ask why something was planned the way it was, without polluting the project-level conversation.

Reviewing and Editing Generated Assets

Every generated asset opens into a detail view that renders its spec in the format that fits its type — a pipeline as ordered stages, a workflow as enrollment criteria plus action sequence, a list as filter logic, a report as its chart configuration.

Before authorization, you can:

• Edit the spec directly — renames, threshold tweaks, an extra stage, a changed filter. Small edits save immediately.
• Ask in the Release chat — “split the Lead stage into MQL and SQL, and update the routing workflow to match.” Jetty revises the affected specs and confirms what changed.
• Regenerate a single asset — if a spec is fundamentally wrong, regenerate just that asset; the rest of the Release is untouched.

When an edit affects assets that depend on the edited one, the dependents are flagged for regeneration rather than left silently inconsistent.

Requirements Never Vanish

A planning principle worth knowing: every requirement the Release accepted has a persisted disposition. If a requirement maps to generated changes, you can trace it in the Changes tab. If it cannot be executed automatically — it needs a manual step, a HubSpot feature the APIs don’t cover, or a human decision — it is kept in the plan with that disposition stated, so review always sees the full picture of what the Release does and does not deliver.

Members and Ownership

Projects support members with owner / editor / viewer roles, and each Release has an accountable owner who can be reassigned. Authorization and apply are deliberate, attributed actions — the History tab records who did what.

AI Credits

Generation and AI-driven planning consume your organisation’s AI credits. If a run exhausts the available balance, it pauses rather than fails — top up credits and the same run resumes where it stopped, with nothing lost. Your credit balance and usage live in your organisation’s billing settings.

Next Steps

• Deployment & Verification — What happens after you authorize
• Solution Blueprint — The design the plan draws from
• Troubleshooting & Gotchas — Stuck Releases and recovery flows