Prompt 11 — Global platform operations control plane

Required context

• Approved platform-operator permissions and support-access model
• Current all-tenants and create-tenant screens
• Plans, entitlements, regions, audit, and operational architecture

Prompt

Build a distinct platform control plane for Capablio global operators. It must support SaaS operations without treating tenant content as ordinary operator data.

1. Visual and security separation

• Use the shared design system but a clearly identified Platform operations workspace.
• Display privileged-session status and current operator identity.
• Do not reuse tenant subject context as if the operator were a tenant user.
• Require step-up authentication for high-impact actions where supported.

2. Platform overview

Show operational metadata only:

• Active/trial/suspended tenants
• Provisioning jobs and failures
• Active subject seats and usage by plan
• Notification delivery health
• Import/sync job health
• Integration health
• Incident/maintenance status
• Support-access sessions
• Release/feature rollout status

No plaintext responses, comments, or private PDP content.

3. Tenant directory

Upgrade the tenant list with:

• Search and filters
• Tenant ID/slug/name
• Lifecycle/status
• Plan and contract state
• Active/allocated seats
• Region/data policy where implemented
• Owner/admin/contact
• Auth/integration status
• Last activity
• Health/risk flags
• Created/renewal dates where authorized
• Actions in overflow with reason/confirmation

4. Tenant detail

Tabs or sections:

• Overview
• Provisioning
• Plan/entitlements and overrides
• Usage
• Domains/authentication metadata
• Integration health
• Jobs/delivery
• Support cases/access
• Audit
• Lifecycle/offboarding

Tenant config changes from the platform must be explicit, scoped, and audited. Prefer tenant-admin self-service.

5. Create tenant wizard

Replace the four-field form with:

1. Identity and slug/domain validation
2. Plan, contract, and seat allocation
3. Region/data-policy selection from actually supported options
4. Initial owner/admin and authentication method
5. Branding/default content seed
6. Integration/onboarding choices
7. Review and provision
8. Provisioning progress and launch checklist

Use idempotency to prevent duplicate tenants. Do not send secrets or bootstrap tokens through insecure copy-only flows without expiry and audit.

6. Plans and entitlements

Build versioned plan definitions and tenant overrides with:

• Effective dates
• Limits and boolean capabilities
• Add-ons
• Reason/owner
• Preview of impact
• Audit
• Server-side evaluation

Feature flags and entitlements are separate. A feature flag cannot grant unpurchased access.

7. Global content catalog

Support author/review/publish/release/retire for global constructs, question families, variants, packs, translations, and framework versions. Show tenant adoption and update impact before release.

8. Support access

Implement the approved case-bound workflow:

• Request, reason, tenant, scope, data classes, duration
• Approval
• Visible banner
• Allowed operations
• Automatic expiry/revoke
• Immutable audit
• Tenant notification where policy requires

Prefer metadata-only diagnostics. Block plaintext feedback unless a separately approved recovery process authorizes it.

9. Tests and runbooks

• Operator versus tenant-admin separation
• Support-session scope/expiry
• Entitlement override effective dates
• Tenant creation idempotency and rollback
• Suspend/reactivate/offboard flows
• Audit completeness
• Operational runbooks linked from errors

Acceptance gates

• Operators can provision and diagnose tenants without entering routine tenant content.
• Tenant creation is a trackable job, not a one-shot form.
• Entitlements are versioned, server-enforced, and auditable.
• Support access is case-bound, time-limited, visible, and revocable.