> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Vertical bundles: activation lifecycle semantics

> What happens on a second activation: overlap, re-activation (duplicate vs idempotent), version N→N+1 behavior, checklist visibility scope, and how Orbit signals a shipped bundle update.

# Vertical bundles: activation lifecycle semantics

The [plugin marketplace](/compliance/plugin-marketplace) documents what a bundle is and how to activate it. This page answers what happens when you activate more than once: overlapping bundles, re-activating the same bundle, version upgrades, and who can see the resulting checklist.

## What a bundle is, and why draft-only

A bundle is a pre-wired industry pack: one draft compliance profile, a few draft campaign templates, a draft AI agent, an opt-in flow config, and a go-live checklist recorded on the profile. Activation provisions every piece as a draft and wires nothing to a carrier — the draft-only shape and the four shipped bundles are documented on the [plugin marketplace](/compliance/plugin-marketplace) page.

Keep one thing in mind below: **the activation record lives on the compliance profile it created.** Every state this page describes — the bundle key, the version snapshot, the checklist — is anchored to a profile, and `GET /api/v1/compliance/vertical-bundles/activations/:profileId` reads it back from there.

## Overlap semantics — two activations, overlapping use cases

Activation never merges with an existing profile. Each `POST /api/v1/compliance/vertical-bundles/:key/activate` call creates a **new** draft compliance profile, new draft campaigns, and a new draft agent, even when the bundle overlaps a profile you already have. The four bundles are use-case-disjoint (US 10DLC business messaging per vertical) — they provision **resource drafts**, not a message inventory. Duplicate profiles in overlapping verticals do not duplicate sends; they split the review burden.

**Operator rule: one activation per use case — click each bundle once.** A second activation of the same bundle, or of two bundles covering the same traffic, produces two independent draft profiles with independent checklists, agents, and campaigns — and two journeys through carrier verification. Do not react to a failed review by re-activating: use the activate body overrides (`brand_name`, `help_contact`, `country_code`, `countries`) on the **first** call or edit the provisioned drafts; a re-call never rewrites the previous profile.

## Idempotency — re-activating the same bundle duplicates, on purpose

The activate call is **not idempotent**. There is no dedupe check: activating `healthcare_hipaa` twice creates two draft profiles, two sets of draft campaigns, two draft agents, and two `compliance.vertical_bundle.activated` audit entries.

Each duplicate is a full record, so the API side-affects of a retry are mechanical (double the drafts; nothing else resolves differently), but the operator cost is real — two checklists to review, two profiles in the verification queue. Build one-click activation as a **once-per-bundle click in the dashboard**, and gate any scripted call behind a read of `GET /api/v1/compliance/vertical-bundles/activations/:profileId` on the profile id you already recorded: if it returns a record, you have already activated.

The read endpoint is keyed on the **profile id**, not the bundle key, so a duplicate pair returns two distinct records — there is no "latest activation wins" behavior and no auto-cleanup of an earlier copy.

## Version N → N+1 — existing activations keep their version

Each activation record pins the bundle's version at the moment of the call (`version` today: `"1.0.0"` for every shipped bundle). When Orbit ships a bundle update, the version field on shipped manifests advances; **the version on your existing activation record does not change**. An activation carries:

| Field                                                    | Upgradable?                                          |
| -------------------------------------------------------- | ---------------------------------------------------- |
| `version`                                                | No — frozen at activation time.                      |
| `checklist[]` (step ids, titles, descriptions, statuses) | No — the entire checklist is inside the record.      |
| `campaigns[]` (provisioned campaign ids + names)         | No — the drafts are yours once created.              |
| `agentId`                                                | No — the provisioned agent is a regular draft agent. |

An activation is a **snapshot, not a subscription.** The bundle update never rewrites a profile, campaign, or agent after the fact, and the old activation continues to resolve to the version it recorded.

### Known remote changes

What an operator does when the catalogue ships a bump:

| Orbit change                            | Existing activations                              | Notification                                                                    | Flagged steps                                                                                                                                                                                                                          |
| --------------------------------------- | ------------------------------------------------- | ------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Bundle revision shipped (new `version`) | Keep their version snapshot — no in-place upgrade | The changelog announces template changes; per-tenant notifications are not sent | None are auto-flagged. Diff the new manifest (`GET /api/v1/compliance/vertical-bundles/:key`) against the provisioned copies; for a material revision (new/moved checklist steps, changed copy), delete the old drafts and re-activate |

The audit entry for every re-activation (`compliance.vertical_bundle.activated`) records the new version, so the org audit log shows the upgrade as a second activation, never as a silent rewrite.

## Checklist data visibility — tenant-scoped, not user-scoped

The checklist the bundle provisions is **tenant-scoped**. The activation record (including every checklist step's status) sits on the tenant's compliance profile, and `GET /api/v1/compliance/vertical-bundles/activations/:profileId` returns that single shared record to any workspace role (owner, admin, developer, viewer). There is no per-owner checklist copy: if one teammate marks `review_optin_copy` done, everyone sees it done.

Two consequences:

* **Review is a shared queue.** Assign steps by step id (`attach_documents`, `submit_profile`, `review_optin_copy`, `review_quiet_hours`, the bundle-specific gate, `review_campaign_copy`) in your team's tracker; the API checklist is the state of record, not a per-person to-do list.
* **Toggles are org-wide writes.** Every `PATCH` writes one `compliance.vertical_bundle.checklist_updated` audit entry into the **org audit log** — the same log your compliance officer exports — stamped with the step id and the new status. Workforce visibility into who moved a step is exactly the org audit log; the API does not retain a separate per-user view.

(Owner, admin, or developer can toggle a step; viewers read the checklist but cannot change it.)

## Related

* [Compliance plugin marketplace](/compliance/plugin-marketplace) — the catalogue, the activation call, and draft-only semantics
* [Compliance evidence binder](/compliance/evidence-binder) — the other pack kind on the marketplace page
* [Troubleshooting pending surfaces](/compliance/troubleshooting-pending-gated-surfaces) — clearing stuck draft resources left by a duplicate activation