docs(self-hosting): correct claims that contradict the source

An audit of the 27 self-hosting and enterprise pages checked every concrete
claim against the code it describes. This fixes what it found.

Errors that made a documented path fail:

- `openssl rand -hex 32` prints 64 hex characters, not the "32 hex chars" five
  entries claimed. Only ENCRYPTION_KEY and API_ENCRYPTION_KEY are length-
  validated; the rest are free-form minimums, so the fix differs per variable.
- API_ENCRYPTION_KEY was absent from the whole Kubernetes path and listed as
  required elsewhere. It is optional, and unset means API keys are stored in
  plain text behind one warning — a silent failure documented nowhere.
- The per-purpose S3 fallback was described backwards: knowledge-base, chat,
  copilot and profile-picture buckets resolve to an empty string, not a literal.
  The GCS table carried the mirror-image claim, and Azure had no warning at all.
- Local uploads go to /app/uploads, not /uploads, and no compose file or chart
  mounts a volume there.
- The remote-sandbox table omitted the immutable template and snapshot refs, so
  the documented configuration could not work.
- The GKE BackendConfig snippet set a values key no template renders.
- Retention deletion is scheduled by nothing in the chart, so a deployment that
  followed the docs deleted nothing.
- Every "Settings → Enterprise/Security → X" path named nav groups that do not
  exist, across eleven enterprise pages.

Claims that understated what ships:

- The outbound-proxy section said no platform traffic can be proxied. The server
  runs on Bun, whose fetch honors the proxy variables, so provider SDK and
  Resend traffic already proxies; guarded egress, SMTP, object storage and OTLP
  do not. Replaced with a per-path table, including the constraint that the
  per-request proxyUrl refuses a private address.
- Telemetry is off by default on Helm, not on, and enabling the collector
  collects nothing until NEXT_TELEMETRY_DISABLED is cleared.
- The CronJob count was 18 in two places; there are 22 in both the chart and the
  crontab.
- The permission-group table was stale throughout, named a deployment key that
  does not exist, and inverted the checkbox semantic. About fifteen governed
  toggles were undocumented.

Also documents ~25 environment variables nothing described, the migration
advisory lock and its operational knobs, the CloudWatch metrics that activate on
any deployment with AWS credentials, and sim-setup doctor.

Redundancy removed where a page restated itself: FAQ blocks that repeated their
own body, four drifting copies of the same tables, and three cloud tabs
identical but for a filename.

The sandbox base-image runbook moves from the enterprise enablement page, where
it was out of place, to its own self-hosting page rather than being lost.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015BwsJTEQRzWJaY4BRCkPZt

Author: waleedlatif1

apps/docs/content/docs/platform/enterprise/access-control.mdx

@@ -14,7 +14,7 @@ Audit logs give your organization a tamper-evident record of every significant a
 
 ### In the UI
 
-Go to **Settings → Enterprise → Audit Logs** in your workspace. Logs are displayed in a table with the following columns:
+Go to **Settings → Organization → Audit logs** in your workspace. Logs are displayed in a table with the following columns:
 
 <Image src="/static/enterprise/audit-logs.png" alt="Audit Logs settings showing a table of events with columns for Timestamp, Event, Description, and Actor, along with search and filter controls" width={900} height={830} />
 
@@ -149,4 +149,13 @@ AUDIT_LOGS_ENABLED=true
 NEXT_PUBLIC_AUDIT_LOGS_ENABLED=true
 ```
 
-Once enabled, audit logs are viewable in **Settings → Enterprise → Audit Logs** and accessible via the API.
+Once enabled, audit logs are viewable in **Settings → Organization → Audit logs** and accessible via the API.
+
+`GET /api/v1/audit-logs` requires a session and an organization on an Enterprise plan, so it is unreachable on a deployment that has no organization yet. The admin-key equivalent has neither requirement:
+
+```http
+GET /api/v1/admin/audit-logs
+x-admin-key: <admin-api-key>
+```
+
+It accepts the same filters as the organization endpoint plus `limit` (max 250) and `offset`, and returns entries across the whole deployment rather than one organization. `GET /api/v1/admin/audit-logs/<id>` returns a single entry. Set `ADMIN_API_KEY` to use it — see the [self-hosted enterprise guide](/platform/enterprise/self-hosted).

apps/docs/content/docs/platform/enterprise/audit-logs.mdx

@@ -35,7 +35,7 @@ Custom blocks turn a workflow one team owns into infrastructure the whole organi
 
 ### 1. Open Custom blocks settings
 
-Go to **Settings → Enterprise → Custom blocks** and click **Create block**.
+Go to **Settings → Organization → Custom blocks** and click **Create block**.
 
 <Image src="/static/enterprise/custom-blocks-list.png" alt="Custom blocks settings page listing a published block with its icon, name, and description, with a Create block button in the header" width={900} height={570} />
 
@@ -102,7 +102,7 @@ Consumers don't need any access to the source workflow. The block runs on its ow
 
 ## Managing blocks
 
-Open a block from **Settings → Enterprise → Custom blocks** to edit or delete it.
+Open a block from **Settings → Organization → Custom blocks** to edit or delete it.
 
 - **Editing** changes only the block's presentation, interface, and trace policy — name, description, icon, input placeholders, exposed outputs, and whether runs are traced in consumer logs. The source workflow can't be re-pointed.
 - **Changing what the block does** is done by editing and **redeploying the source workflow**. The block picks up the new deployment automatically; there's nothing to republish.

apps/docs/content/docs/platform/enterprise/custom-blocks.mdx

@@ -13,7 +13,7 @@ Drains are independent of [Data Retention](/platform/enterprise/data-retention)
 
 ## Setup
 
-Go to **Settings → Enterprise → Data Drains** in your workspace, then click **New drain**.
+Go to **Settings → Organization → Data drains** in your workspace, then click **New drain**.
 
 ![Data Drains settings page showing two configured drains — one exporting workflow logs to Amazon S3 daily, another exporting Copilot chats to an HTTPS webhook hourly](/static/enterprise/data-drains-list.png)
 
@@ -207,10 +207,6 @@ After data lands in your bucket or webhook system, archive lifecycle (transition
     question: "Who can configure data drains?",
     answer: "Only organization owners and admins can view, create, edit, run, or delete drains. On Sim Cloud, the organization must be on an Enterprise plan."
   },
-  {
-    question: "Will drained data be duplicated if a run fails?",
-    answer: "The drain cursor only advances on overall success, so a failure replays the same chunks on the next run. Every row has a stable `id` field and every webhook chunk has an `Idempotency-Key` header so receivers can dedupe."
-  },
   {
     question: "Can I export multiple sources to the same destination?",
     answer: "Yes — create one drain per source, all pointing at the same bucket or endpoint. S3 destinations namespace by source automatically; webhook receivers can branch on the `X-Sim-Source` header."
@@ -240,6 +236,27 @@ DATA_DRAINS_ENABLED=true
 NEXT_PUBLIC_DATA_DRAINS_ENABLED=true
 ```
 
-`NEXT_PUBLIC_DATA_DRAINS_ENABLED` shows the **Settings → Enterprise → Data Drains** page in the UI. `DATA_DRAINS_ENABLED` gates the server-side mutating endpoints and the cron dispatcher — when unset on a self-hosted deployment, drain create/update/delete/run requests return `404` and the dispatcher is a no-op. Both should be set to `true` together.
+`NEXT_PUBLIC_DATA_DRAINS_ENABLED` shows the **Settings → Organization → Data drains** page in the UI. `DATA_DRAINS_ENABLED` gates the server-side mutating endpoints and the cron dispatcher — when unset on a self-hosted deployment, drain create/update/delete/run requests return `404` and the dispatcher is a no-op. Both should be set to `true` together.
+
+### Scheduling the dispatcher
+
+The dispatcher is an HTTP endpoint, not a self-scheduling job — something has to call it:
+
+```
+GET /api/cron/run-data-drains
+```
+
+It authenticates with a bearer token equal to `CRON_SECRET` and returns `401` when that variable is unset, so a self-hosted deployment must set it:
+
+```bash
+CRON_SECRET=$(openssl rand -hex 32)
+```
+
+The Helm chart schedules this endpoint hourly for you (`cronjobs.jobs.runDataDrains`). Outside Helm, schedule it yourself:
+
+```bash
+curl -H "Authorization: Bearer $CRON_SECRET" \
+  https://sim.example.com/api/cron/run-data-drains
+```
 
-Data Drains otherwise rely on the standard Trigger.dev background job infrastructure used elsewhere in Sim — no additional setup is required. The cron dispatcher runs hourly and fans out due drains as background jobs.
+Each due drain is then fanned out as a `run-data-drain` background job, so the deployment also needs `TRIGGER_DEV_ENABLED` with a configured Trigger.dev project, or the local job backend. See [background jobs](/platform/self-hosting/background-jobs).

apps/docs/content/docs/platform/enterprise/data-drains.mdx

@@ -18,7 +18,7 @@ Both are configured once at the **organization level** and apply to every worksp
 
 ## Setup
 
-Go to **Settings → Enterprise → Data Retention** in your workspace.
+Go to **Settings → Organization → Data retention** in your workspace.
 
 <Image src="/static/enterprise/data-retention.png" alt="Data Retention settings showing the Retention policies list with the Organization default row and its summary of retention periods and PII stages" width={900} height={537} />
 
@@ -97,10 +97,10 @@ The **Workflow input** and **Block outputs** stages alter what the workflow comp
 
 For each stage, choose the **entity types** to redact from the searchable grid. They are grouped as:
 
-- **Common** — person name, email, phone, credit card, IP address, URL, IBAN, crypto wallet, medical license, VIN
+- **Common** — person name, email, phone, credit card, IP address, location, date or time, URL, IBAN, crypto wallet, nationality/religious/political group, medical license, VIN
 - **United States** — SSN, passport, driver's license, bank account, ITIN
 - **United Kingdom** — NHS number, National Insurance number
-- **Other regions** — Singapore, Australian, and Indian identifiers
+- **Other regions** — Spanish (NIF, NIE), Italian (fiscal code, driver's licence, VAT code, passport, identity card), Polish (PESEL), Singaporean (NRIC/FIN, UEN), Australian (ABN, ACN, TFN, Medicare), Indian (PAN, Aadhaar, vehicle registration, voter ID, passport), and Finnish (personal identity code) identifiers
 
 The **Block outputs** stage is restricted to regex- and checksum-based recognizers, so it can run in-flight over large payloads without a performance penalty. Types that need name-model detection — person name, location, date or time — are not offered for that stage.
 
@@ -182,7 +182,30 @@ NEXT_PUBLIC_DATA_RETENTION_ENABLED=true
 DATA_RETENTION_ENABLED=true
 ```
 
-Once enabled, retention settings are configurable through **Settings → Enterprise → Data Retention** the same way as Sim Cloud.
+Once enabled, retention settings are configurable through **Settings → Organization → Data retention** the same way as Sim Cloud.
+
+### Scheduling the deletion pass
+
+`DATA_RETENTION_ENABLED` permits deletion; it does not perform it. Deletion runs when a scheduled request reaches one of three endpoints, each authenticated with a bearer token equal to `CRON_SECRET`:
+
+| Category | Endpoint |
+|----------|----------|
+| Execution and job logs | `GET /api/logs/cleanup` |
+| Soft-deleted resources | `GET /api/cron/cleanup-soft-deletes` |
+| Chats and Chat runs | `GET /api/cron/cleanup-tasks` |
+
+<Callout type="warn">
+The Helm chart does **not** schedule these three endpoints. An operator who sets `DATA_RETENTION_ENABLED=true` on the chart alone still deletes nothing. Add them to `cronjobs.jobs`, or call them daily from an external scheduler.
+</Callout>
+
+```bash
+CRON_SECRET=$(openssl rand -hex 32)
+
+curl -H "Authorization: Bearer $CRON_SECRET" \
+  https://sim.example.com/api/logs/cleanup
+```
+
+Each call fans the work out as background jobs, so the deployment also needs `TRIGGER_DEV_ENABLED` with a configured Trigger.dev project, or the local job backend.
 
 ### PII redaction
 
@@ -193,4 +216,4 @@ PII redaction runs against a standalone [Presidio](https://microsoft.github.io/p
 PII_URL=http://localhost:5001
 ```
 
-All PII stages are configurable under **Settings → Enterprise → Data Retention**.
+All PII stages are configurable under **Settings → Organization → Data retention**.

apps/docs/content/docs/platform/enterprise/data-retention.mdx

@@ -29,7 +29,7 @@ On Sim Cloud, your organization may also need the feature turned on for your acc
 
 ### 1. Open Forks
 
-Go to **Settings → Enterprise → Workspace Forks** in the workspace you want to fork from (or manage).
+Go to **Settings → Organization → Workspace forks** in the workspace you want to fork from (or manage).
 
 <Image src="/static/enterprise/forks-list.png" alt="Workspace Forks settings page showing Parent and Forks sections with Docs, See activity, and Create fork actions" width={900} height={369} />
 
@@ -62,7 +62,7 @@ Click **Fork**. The child workspace is created immediately. Deployed workflows l
 
 ### 3. Open the parent edge (from the child)
 
-Open the **child** workspace → **Settings → Enterprise → Workspace Forks**. On the **Parent** row, open the menu and choose **Edit mappings**.
+Open the **child** workspace → **Settings → Organization → Workspace forks**. On the **Parent** row, open the menu and choose **Edit mappings**.
 
 Child rows (when you are on the parent) only offer **Open workspace** and **Disconnect** — mapping and sync are owned by the child configuring how it relates to its parent.
 
@@ -373,13 +373,8 @@ Schedules, webhooks, and triggers are not live in the child until you **deploy**
 
 <FAQ items={[
   { question: "Why is Sync greyed out?", answer: "Usually a blocking reference, an unmapped credential or secret, or a required dependent field (label, channel, document, …) still empty. Open Blocking sync and the mapping sections — each row explains what to fix. Sync also stays disabled while details are loading or if loading failed (reload the page)." },
-  { question: "Why weren’t my credentials copied into the fork?", answer: "Credentials are never copied, for security. Fields are cleared on fork. On sync you map each source credential to a credential that already exists in the target, then re-pick dependent fields." },
-  { question: "Do secret values get copied?", answer: "No. Only names like {{API_KEY}} appear in workflow text. Create the values under Secrets in each workspace, and map key names on sync if they differ." },
-  { question: "Can I sync with a grandparent or another fork?", answer: "No. Sync only works along a direct parent↔child edge." },
-  { question: "What if I deselect resources when creating a fork?", answer: "References to those resources in the forked workflows are cleared in the child. You will see a warning in the modal before you confirm." },
   { question: "Is sync a merge?", answer: "No. Deploy is like a commit; sync is a force push or force pull of deployed workflows onto the target. Use Rollback only for the last sync into a workspace, and remember copied resources may remain." },
-  { question: "What happens to chat URLs?", answer: "Deployed chats are carried with a new URL on fork. On sync, a chat is created on the target only if that workflow does not already have one. Existing target chats are not replaced." },
-  { question: "Who can disconnect a fork I cannot open?", answer: "Any admin on your side of the edge. Disconnect does not require access to the other workspace — so you are not stuck if the other side lost membership." },
+  { question: "Who can disconnect a fork I cannot open?", answer: "Any admin on your side of the edge. Disconnect does not require access to the other workspace — so you are not stuck if the other side lost membership." }
 ]} />
 
 ---
@@ -392,4 +387,4 @@ Self-hosted deployments turn Forks on with an environment variable instead of th
 |----------|-------------|
 | `FORKING_ENABLED`, `NEXT_PUBLIC_FORKING_ENABLED` | Enables workspace forking when billing is not used as the entitlement gate |
 
-Once enabled, use the same **Settings → Enterprise → Workspace Forks** UI as Sim Cloud. Only workspace admins can manage forks.
+Once enabled, use the same **Settings → Organization → Workspace forks** UI as Sim Cloud. Only workspace admins can manage forks.

apps/docs/content/docs/platform/enterprise/forks.mdx

@@ -3,31 +3,29 @@ title: Enterprise
 description: Enterprise features for business organizations
 ---
 
-import { FAQ } from '@/components/ui/faq'
-
 Sim Enterprise adds fine-grained access control, SSO, audit logging, compliance features, and workspace forking on top of Team plans.
 
 ---
 
-## Access Control
+## Permission groups
 
-Define permission groups on a workspace to control what features and integrations its members can use. Permission groups are scoped to a single workspace — a user can belong to different groups (or no group) in different workspaces.
+Define permission groups to control what features, models, blocks, and integrations your members can use. A permission group belongs to an **organization**. The organization's single **default group** governs everyone org-wide; every other group targets a specific set of workspaces and, by default, governs all members of those workspaces — or only named members once you add them. A user is governed by exactly one group in any given workspace.
 
-External workspace members can be assigned to permission groups just like internal organization members, but they remain outside the organization roster and do not consume seats.
+External workspace members can be governed by permission groups just like internal organization members, but they remain outside the organization roster and do not consume seats.
 
-### Features
+### What a group controls
 
-- **Allowed Model Providers** - Restrict which AI providers users can access (OpenAI, Anthropic, Google, etc.)
-- **Allowed Blocks** - Control which workflow blocks are available
-- **Platform Settings** - Hide Knowledge Base, disable MCP tools, disable custom tools, or disable invitations
+- **Model providers** - Restrict which AI providers members can use, and deny individual models within an allowed provider
+- **Blocks** - Control which workflow blocks are available, and deny individual tools within an allowed integration
+- **Platform** - Revoke modules (Chat, Knowledge Base, Tables, Files, Sim Mailer), deployment surfaces, tool types, log detail, collaboration actions, and credential access
 
 ### Setup
 
-1. Navigate to **Settings** → **Access Control** in the workspace you want to manage
+1. Navigate to **Settings** → **Organization** → **Permission groups** from any workspace in your organization
 2. Create a permission group with your desired restrictions
-3. Add workspace members to the permission group
+3. Scope it to workspaces, and optionally add named members
 
-Any workspace admin on an Enterprise-entitled workspace can manage permission groups. Users not assigned to any group have full access. Restrictions are enforced at both UI and execution time, based on the workflow's workspace.
+Only organization owners and admins can manage permission groups. Users not governed by any group have full access. Restrictions are enforced at both UI and execution time, based on the organization that owns the workflow's workspace.
 
 See the [Access Control guide](/platform/enterprise/access-control) for full details.
 
@@ -41,9 +39,9 @@ See the [SSO setup guide](/platform/enterprise/sso) for step-by-step instruction
 
 ---
 
-## Whitelabeling
+## White-labeling
 
-Replace Sim's default branding — logos, product name, and favicons — with your own. See the [whitelabeling guide](/platform/enterprise/whitelabeling).
+Replace Sim's default branding — logos, wordmark, product name, and theme colors — with your own. Instance-wide branding environment variables additionally cover the favicon and custom CSS. See the [white-labeling guide](/platform/enterprise/whitelabeling).
 
 ---
 
@@ -77,14 +75,6 @@ Clone a workspace into a linked child, then push or pull **deployed** workflow c
 
 ---
 
-<FAQ items={[
-  { question: "Who can manage Enterprise features?", answer: "Workspace admins on an Enterprise-entitled workspace. Access Control, SSO, whitelabeling, audit logs, data retention, data drains, and forks are all configured per workspace under Settings → Enterprise." },
-  { question: "Which SSO providers are supported?", answer: "Sim supports SAML 2.0 and OIDC, which works with virtually any enterprise identity provider including Okta, Azure AD (Entra ID), Google Workspace, ADFS, and OneLogin." },
-  { question: "How do access control permission groups work?", answer: "Permission groups are created per workspace and let you restrict which AI providers, workflow blocks, and platform features are available to specific members of that workspace. Each user can belong to at most one group per workspace. Users not assigned to any group have full access. Restrictions are enforced at both the UI level and at execution time based on the workflow's workspace." },
-]} />
-
----
-
 ## Self-hosted setup
 
 Self-hosted deployments unlock enterprise features through environment configuration instead of billing. One switch turns on the whole set: