diff --git a/docs/PULSE_PRO.md b/docs/PULSE_PRO.md
index dc5501d3a..22a9fdcf9 100644
--- a/docs/PULSE_PRO.md
+++ b/docs/PULSE_PRO.md
@@ -17,7 +17,7 @@ User-facing plans map to internal tiers as follows:
 - **Cloud**: `msp` or `enterprise`
 
 Notes:
-- `lifetime` keeps the same runtime feature set as Pro, but grandfathered lifetime entitlements are uncapped for monitored systems and guest access.
+- `lifetime` keeps the same runtime feature set as Pro, but lifetime and grandfathered recurring legacy entitlements remain uncapped for monitored systems and guest access.
 - Items marked **Cloud*** require the `enterprise` tier rather than the base `msp` tier.
 - If you are self-hosting, you can use capability keys and `GET /api/license/features` to discover exactly what is active in your instance.
 
@@ -63,6 +63,18 @@ Migration policy:
 - During grace, existing monitoring keeps working.
 - During grace, only new counted-system additions are blocked until the user removes systems or upgrades.
 
+### Paid Customer Continuity Matrix
+
+| Customer cohort | What happens in v6 | Pricing and capacity outcome |
+|---|---|---|
+| Existing active recurring subscriber from a v5 or earlier Pulse Pro monthly/annual plan | The install can migrate into the v6 activation model without forcing a repurchase. | The existing recurring price stays in place and monitored-system plus guest capacity remain uncapped while the subscription remains continuously active. |
+| Existing lifetime license holder | The license remains valid through the v6 licensing transition. | Lifetime remains permanently valid and monitored-system plus guest capacity stay uncapped. |
+| Former recurring subscriber who already canceled or later lapses/cancels | A later return is treated as a new paid purchase, not as a grandfathered renewal. | The old grandfathered price and uncapped capacity do not resume automatically; current public v6 pricing and caps apply. |
+| New self-hosted v6 purchase | The purchase uses the current Relay / Pro / Pro+ self-hosted plans. | Current public v6 monitored-system and guest caps apply. |
+
+Support rule:
+- If a currently active recurring subscriber or a lifetime customer sees a bounded monitored-system or guest cap in v6, treat it as a bug rather than as intended policy.
+
 ## Feature Matrix
 
 Legend:
diff --git a/docs/UPGRADE_v6.md b/docs/UPGRADE_v6.md
index 72b5a4a9a..2efde58ad 100644
--- a/docs/UPGRADE_v6.md
+++ b/docs/UPGRADE_v6.md
@@ -133,6 +133,17 @@ Pulse v6 uses the activation/grant model for active licensing, but it can migrat
 - If the exchange service cannot complete the migration, retry from the v6 license panel or use the self-serve retrieval flow to fetch the current v6 activation key. Email is only a backup copy of that key.
 - Existing active recurring v5 customers keep their grandfathered recurring price and uncapped monitored-system and guest capacity until cancellation. If they cancel and later return, current v6 pricing and limits apply.
 
+#### Paid Upgrade Truth Table
+
+When an existing paid user asks what changes for them specifically, use this rule set:
+
+- Existing active recurring Pulse Pro subscribers from v5 or earlier keep their current recurring price and uncapped monitored-system plus guest capacity while the subscription remains continuously active.
+- Existing lifetime customers remain permanently valid and uncapped.
+- Former recurring customers who already canceled, or who cancel and later return, do not resume the old grandfathered pricing or uncapped capacity automatically; they re-enter on current public v6 pricing and limits.
+- New self-hosted v6 purchases use the current Relay / Pro / Pro+ plan caps.
+
+If an active recurring subscriber or lifetime customer sees a new monitored-system or guest cap after moving to v6, treat that as a regression, not as expected upgrade behavior.
+
 Practical recommendation:
 
 - Before upgrading, keep console access available so you can retry activation from the v6 license panel if the exchange service is temporarily unavailable.
diff --git a/docs/releases/V6_RC_OPERATOR_SUPPORT_PACK.md b/docs/releases/V6_RC_OPERATOR_SUPPORT_PACK.md
index 35f760703..d0bc1fd06 100644
--- a/docs/releases/V6_RC_OPERATOR_SUPPORT_PACK.md
+++ b/docs/releases/V6_RC_OPERATOR_SUPPORT_PACK.md
@@ -54,12 +54,29 @@ host or VM, a cloned lab machine, or a separate isolated agent installation.
 
 Yes. That is the recommended RC posture.
 
-### What happens to a Pulse v5 Pro or Lifetime license?
+### What happens to an existing paid Pulse Pro customer in v6?
 
 Pulse v6 can migrate valid Pulse v5 Pro or Lifetime licensing into the v6
 activation model. If the auto-exchange does not complete, retry from the v6
 license panel using the existing key.
 
+Use this cohort breakdown:
+
+- Existing active recurring monthly or annual subscribers from v5 or earlier:
+  keep the current recurring price and uncapped monitored-system plus guest
+  capacity while the subscription remains continuously active.
+- Existing lifetime customers:
+  remain permanently valid and uncapped.
+- Former recurring subscribers who already canceled or later lapse:
+  any later return uses current public v6 pricing and caps rather than
+  resuming the old grandfathered terms.
+- New self-hosted v6 purchasers:
+  take the current Relay / Pro / Pro+ caps.
+
+If a currently active recurring subscriber or a lifetime customer sees a
+bounded monitored-system or guest cap in v6, treat that as a product bug, not
+as intended policy.
+
 ### Will old bookmarks and familiar v5 pages still work?
 
 Not necessarily. v6 reorganizes the product around Dashboard, Infrastructure,
@@ -112,6 +129,8 @@ Escalate without asking the user to keep experimenting when the report involves:
 - duplicate or missing agent identity after a v5-to-v6 upgrade
 - monitoring or reporting that stops entirely after upgrade
 - license migration failure that blocks paid functionality unexpectedly
+- an active recurring subscriber or lifetime customer seeing an unexpected
+  monitored-system or guest cap
 - rollback failure or inability to return to the previous stable state
 - data-loss, destructive behavior, or security-sensitive regressions
 
diff --git a/tests/integration/tests/52-ai-settings-provider-setup.spec.ts b/tests/integration/tests/52-ai-settings-provider-setup.spec.ts
index 78e8e02ab..1df7b568a 100644
--- a/tests/integration/tests/52-ai-settings-provider-setup.spec.ts
+++ b/tests/integration/tests/52-ai-settings-provider-setup.spec.ts
@@ -109,7 +109,7 @@ test.describe("AI settings provider setup", () => {
     await page.goto("/settings/system-ai", { waitUntil: "domcontentloaded" });
     await expect(page.getByRole("heading", { name: "Assistant & Patrol", level: 1 })).toBeVisible();
 
-    await page.getByRole("button", { name: /enable ai services/i }).click();
+    await page.getByRole("button", { name: /enable assistant and patrol/i }).click();
     const setupDialog = page.getByRole("dialog", { name: "Set up Pulse Assistant" });
     await expect(setupDialog.getByText("Set Up Pulse Assistant")).toBeVisible();