zuplo 7.9.5 → 7.9.8

package/docs/ai-gateway/managing-apps.mdx

@@ -2,7 +2,7 @@
 title: Managing Apps
 description:
   Create, edit, and delete AI Gateway apps. Apps are created with just a name
-  and a team; models, app-specific budgets, and other behavior live on the app's
+  and a pool; models, app-specific budgets, and other behavior live on the app's
   policy chain.
 ---
 
@@ -11,16 +11,16 @@ feature in a larger codebase. Each app has its own API key, which the gateway
 checks once you add the
 [authentication policy](./policy-chains.mdx#authentication); usage is tracked
 per app whether or not that policy applies. Each app belongs to a
-[team](./teams.mdx), which controls who can access and manage the app. Provider
+[pool](./pools.mdx), which controls who can access and manage the app. Provider
 access is governed separately by the user's Zuplo account and Zuplo project
 roles. A Zuplo account contains one or more projects; this AI Gateway and its
-providers, teams, and apps belong to one Zuplo project. See
+providers, pools, and apps belong to one Zuplo project. See
 [Role Permissions](../articles/accounts/roles-and-permissions.mdx).
 
 :::note{title="App permissions"}
 
-A team **Admin** can create, edit, and delete apps owned by that team. A team
-**Member** can access the team's apps but can't manage them. Both roles require
+A pool **Admin** can create, edit, and delete apps owned by that pool. A pool
+**Member** can access the pool's apps but can't manage them. Both roles require
 permission to view the Zuplo project that contains the AI Gateway.
 
 :::
@@ -29,25 +29,25 @@ permission to view the Zuplo project that contains the AI Gateway.
 
 <Stepper>
 
-1. Open the [Apps & Teams](https://portal.zuplo.com/+/account/project/ai/apps)
-   tab of your AI Gateway project in the Zuplo Portal.
+1. Open the [Apps](https://portal.zuplo.com/+/account/project/ai/apps) tab of
+   your AI Gateway project in the Zuplo Portal.
 
-1. Select the team that will own the app, then click **Create App** in the
-   team's header. An app always belongs to a team, so the tree's own create
-   action is **New Team**.
+1. Select the pool that will own the app, then click **Create App** in the
+   pool's header. You can also choose **New App** from the menu next to **New
+   Pool** above the tree.
 
 1. Enter the **App name**.
 
-1. Confirm the **Team**—it's prefilled with the team you started from.
+1. Confirm the **Pool**—it's prefilled with the pool you started from.
 
 1. Click **Create app**
 
 </Stepper>
 
 That's the whole dialog. The portal then takes you to the app's **Policies**
-tab. If the app's team defines a [policy template](./policy-templates.mdx), the
+tab. If the app's pool defines a [policy template](./policy-templates.mdx), the
 new app starts with that chain; otherwise the chain is empty and the app is
-subject to no app-specific controls until you add policies. Team and gateway
+subject to no app-specific controls until you add policies. Pool and gateway
 usage limits still apply.
 
 ## Restricting models
@@ -88,24 +88,24 @@ over—see [Dynamic model routing](./cookbooks/dynamic-model-routing.mdx).
 App budgets live on the **Budgets and Costs** policy in the app's chain. Open
 the app's **Policies** tab and add budget rules capping spending, tokens, or
 requests over an hourly, daily, weekly, or monthly period—either for the app as
-a whole or per metadata value, so each caller gets its own budget. Team and
+a whole or per metadata value, so each caller gets its own budget. Pool and
 gateway limits apply to every app automatically, even when the app's chain
 doesn't include Budgets and Costs. See [Usage Limits](./usage-limits.mdx).
 
 ## Editing an App
 
 To edit an app, open the
-[Apps & Teams](https://portal.zuplo.com/+/account/project/ai/apps) tab of your
-AI Gateway project in the Zuplo Portal. Select the app you want to edit. The
-app's behavior—models, app-specific budgets, caching, guardrails—is edited on
-the **Policies** tab; the app's name lives on the **Settings** tab. Make your
+[Apps](https://portal.zuplo.com/+/account/project/ai/apps) tab of your AI
+Gateway project in the Zuplo Portal. Select the app you want to edit. The app's
+behavior—models, app-specific budgets, caching, guardrails—is edited on the
+**Policies** tab; the app's name lives on the **Settings** tab. Make your
 changes and click the **Save** button. Policy chain changes apply within about a
 minute.
 
 ## Deleting an App
 
 To delete an app, open the
-[Apps & Teams](https://portal.zuplo.com/+/account/project/ai/apps) tab of your
-AI Gateway project in the Zuplo Portal. Select the app you want to delete, open
-its **Settings** tab, and click the **Delete App** button. You will be prompted
-to confirm the deletion.
+[Apps](https://portal.zuplo.com/+/account/project/ai/apps) tab of your AI
+Gateway project in the Zuplo Portal. Select the app you want to delete, open its
+**Settings** tab, and click the **Delete App** button. You will be prompted to
+confirm the deletion.

package/docs/ai-gateway/managing-pools.mdx

@@ -0,0 +1,87 @@
+---
+title: Managing Pools
+description:
+  Create pools and sub-pools, add members, and set pool-level policy templates
+  and usage limits in your AI Gateway project.
+---
+
+Pools in the Zuplo AI Gateway grant users access to apps. Pools are
+hierarchical, so access propagates to sub-pools only when the user also has
+permission to view the Zuplo project that contains the AI Gateway. Pool or
+sub-pool membership doesn't grant Zuplo project access. Pools are also where you
+define usage limits and [policy templates](./policy-templates.mdx).
+
+## Creating a Pool
+
+Creating a pool requires Admin rights on the Zuplo project or Zuplo account for
+a top-level pool, or on the parent pool for a sub-pool. As a convenience, the
+Portal disables the **New Pool** button when you don't have the required rights.
+
+<Stepper>
+
+1. Open the [Apps](https://portal.zuplo.com/+/account/project/ai/pools) tab of
+   your AI Gateway project in the Zuplo Portal.
+
+1. Click **New Pool** above the tree.
+
+1. Choose where the pool sits. Once the gateway has at least one pool, the
+   dialog shows a parent picker above the name field; leave it on **No parent
+   pool** for a top-level pool, or pick a pool to create a sub-pool under it.
+
+1. Enter the name of your pool.
+
+1. Click **Create Pool**
+
+</Stepper>
+
+You can also create a sub-pool from the parent itself: select it in the tree and
+click **Create Sub-Pool** in the pool's header.
+
+After creating a pool, use its tabs to configure it:
+
+- **Policy Template**—the pool's [policy template](./policy-templates.mdx), the
+  starting policy chain for apps created in the pool.
+- **Usage & Limits**—shared budgets for the pool, its sub-pools, and their apps.
+  See [Usage Limits](./usage-limits.mdx).
+- **Members**—who belongs to the pool.
+
+## Adding Pool Members
+
+Pool members are the users who belong to a pool and can access its apps,
+provided they also have permission to view the Zuplo project. AI provider access
+is separate and depends on the user's Zuplo account or Zuplo project role.
+
+<Stepper>
+
+1. Open the [Apps](https://portal.zuplo.com/+/account/project/ai/pools) tab of
+   your AI Gateway project in the Zuplo Portal.
+
+1. Select the pool you want to add members to.
+
+1. Click the **Members** tab.
+
+1. Click **Add member**.
+
+1. Type the email address of the user you want to add. If the user is already a
+   member of your Zuplo account, they are added directly to the pool. Otherwise,
+   they are invited to join the Zuplo account and then added to the pool.
+
+1. Select the role for the user:
+   - **Member**: Can access apps owned by the pool.
+   - **Admin**: Can manage the pool's settings, members, and apps.
+
+     :::caution{title="The Member role requires RBAC"}
+
+     Role-based access control (RBAC) is an optional enterprise add-on on your
+     Zuplo account. Without it, every invited user is an **Admin**. For more
+     information see the
+     [document on roles and permissions](../articles/accounts/roles-and-permissions.mdx).
+
+     :::
+
+1. Click **Add member** to confirm.
+
+1. The user will receive an email notification if they're being invited to the
+   Zuplo account.
+
+</Stepper>

package/docs/ai-gateway/managing-providers.mdx

@@ -18,7 +18,7 @@ project role grants access only to that project. Adding, editing, or deleting
 providers and their models requires the **Edit** permission granted to Zuplo
 account and Zuplo project **Admins**. A Zuplo account **Developer**, or a Zuplo
 project **Developer** or **Member**, can view providers but can't manage them.
-Team membership doesn't grant provider access. See
+Pool membership doesn't grant provider access. See
 [Role Permissions](../articles/accounts/roles-and-permissions.mdx).
 
 :::
@@ -58,9 +58,9 @@ To add a new AI provider to your Zuplo AI Gateway, follow these steps:
    Project ID** and takes a service account JSON key file instead of an API key,
    and [Azure AI](./azure-ai.mdx) asks for an **Azure Resource Name** and a host
    family, plus a mapping for any deployment named differently from the model it
-   serves. [OpenRouter](./openrouter.mdx) is the opposite case: it asks for
-   nothing beyond the key, being a single global host with no endpoint, region
-   or project to enter.
+   serves. [OpenRouter](./openrouter.mdx) and [Jev](./jev.mdx) are the opposite
+   case: they ask for nothing beyond the key, each being a single global host
+   with no endpoint, region or project to enter.
 
 1. Select the model or models you want to use with this provider. The available
    models will depend on the selected provider. This can be changed later.

package/docs/ai-gateway/overview.mdx

@@ -8,10 +8,10 @@ description:
 ---
 
 Zuplo's AI Gateway acts as an intelligent proxy layer that sits between your
-engineering team's apps and LLM providers like OpenAI, Anthropic, Google,
-Mistral, and xAI. Instead of your apps communicating directly with these
-providers, all requests flow through the Zuplo AI Gateway, which streams
-responses while applying policies, controls, and monitoring.
+apps, your people, and LLM providers like OpenAI, Anthropic, Google, Mistral,
+and xAI. Instead of your apps communicating directly with these providers, all
+requests flow through the Zuplo AI Gateway, which streams responses while
+applying policies, controls, and monitoring.
 
 Each piece of software that calls the gateway registers as an **app**—your
 support chatbot is one app; an internal coding agent is another. A single AI
@@ -23,6 +23,11 @@ you can write your own in TypeScript, and apps add them to their chains like any
 other policy. Chain changes apply within about a minute, with no redeploy. See
 [Apps](./apps.mdx).
 
+People call the gateway too. Instead of creating an app for each person, every
+AI Gateway project has a **User App**: people create their own personal API key
+and use it from tools such as Claude Code or Codex. Each person draws from their
+own budget, and admins see who spent what. See [User Apps](./user-apps.mdx).
+
 ## Key Benefits
 
 **Provider Independence**: Switch between LLM providers (OpenAI, Anthropic,
@@ -30,7 +35,7 @@ Google, Mistral, xAI, and more) dynamically without modifying app code.
 Configure model access through the gateway rather than hard coding it into your
 apps.
 
-**Cost Control**: Set independent spending limits at the gateway, team, and app
+**Cost Control**: Set independent spending limits at the gateway, pool, and app
 levels. Configure hourly, daily, weekly, or monthly rules that warn or block
 when usage reaches a limit.
 
@@ -38,9 +43,10 @@ when usage reaches a limit.
 attempts and prevent PII leakage in both requests and responses through
 integrated AI firewall policies.
 
-**Self-Service Access**: Developers can create apps and access LLMs without
-needing direct access to provider API keys. Administrators configure providers
-once, and teams consume them securely.
+**Self-Service Access**: Developers can create apps, and anyone on the project
+can create a personal API key, without needing direct access to provider API
+keys. Administrators configure providers once, and apps and people use them
+securely.
 
 **Extensibility**: Write custom policies in TypeScript—content filters, dynamic
 model routing, plan-based limits—and let apps add them to their chains like any
@@ -57,7 +63,8 @@ time-to-first-byte metrics, and spending patterns across your gateway.
 
 Your code sends its LLM requests to your AI Gateway instead of directly to a
 provider. Each app has its own URL, API key, and policy chain, so one gateway
-serves teams with completely different configurations.
+serves apps with completely different configurations. People send requests to
+the User App's URL with their personal key instead.
 
 Each request arrives at the URL of the app it belongs to. The gateway identifies
 that app, runs its policy chain (model access, app-specific cost controls,
@@ -67,7 +74,7 @@ exposing underlying provider credentials.
 
 Every app-specific control is opt-in. An app whose policy chain is empty runs no
 app-selected controls: each request names its own model, and no app-specific
-model restrictions, budgets, guardrails, or caching apply. Gateway and team
+model restrictions, budgets, guardrails, or caching apply. Gateway and pool
 usage limits still apply.
 
 ## Core Features
@@ -78,16 +85,16 @@ Configure multiple LLM providers within a single AI Gateway project. Supported
 providers include OpenAI, Anthropic, Google, Mistral, xAI, Microsoft Azure
 (through [Azure AI](./azure-ai.mdx)), Amazon Bedrock (through
 [Bedrock Mantle](./bedrock-mantle.mdx)), Google Cloud
-([Vertex AI](./vertex-ai.mdx)), [OpenRouter](./openrouter.mdx), and
-OpenAI-compatible custom providers. See [AI Providers](./providers.mdx) for the
-full list of providers and supported capabilities. Apps reference models as
-`providerName/model`—for example `openai/gpt-5-mini`—so a single app can use
-models from several providers.
+([Vertex AI](./vertex-ai.mdx)), [OpenRouter](./openrouter.mdx), TypeSafe's
+System One model ([Jev](./jev.mdx)), and OpenAI-compatible custom providers. See
+[AI Providers](./providers.mdx) for the full list of providers and supported
+capabilities. Apps reference models as `providerName/model`—for example
+`openai/gpt-5-mini`—so a single app can use models from several providers.
 
 ### Source-Controlled Gateway
 
 A new AI Gateway project deploys without a Git repository, so you can configure
-providers, teams, and apps right away. Connect a
+providers, pools, and apps right away. Connect a
 [Git repository](./source-control.mdx) when you want to write custom policies or
 review gateway changes in Git. After you connect, the default branch is what
 production runs.
@@ -96,22 +103,24 @@ production runs.
 
 Each app runs its own ordered chain of policies—model filtering, fallback
 models, app-specific budgets, semantic caching, guardrails, tracing, and any
-custom policies declared in the repository. Team policy templates give new apps
+custom policies declared in the repository. Pool policy templates give new apps
 a consistent starting pipeline. See [Policy Chains](./policy-chains.mdx) and
 [Custom Policies](./custom-policies.mdx).
 
-### Team Hierarchy & Budgets
+### Pool Hierarchy & Budgets
 
-Organize users into teams with hierarchical structures. Set a budget at each
+Organize apps into pools with hierarchical structures. Set a budget at each
 node. Each node totals its own usage and all descendant usage, and any exceeded
 **Block** limit rejects the request:
 
 - **Gateway**: Limits across the Zuplo project (for example, $1,000/day).
-- **Teams**: Limits across the team, its sub-teams, and their apps (for example,
-  $500/day for the Credit Team).
+- **Pools**: Limits across the pool, its sub-pools, and their apps (for example,
+  $500/day for the Credit Pool).
 - **Apps**: Limits for one app's traffic.
 
-See [Usage Limits](./usage-limits.mdx).
+The [User App](./user-apps.mdx) has a per-person budget instead, such as $50 per
+day for each person. Gateway limits apply to it as well. See
+[Usage Limits](./usage-limits.mdx).
 
 ### App Configuration
 
@@ -126,18 +135,21 @@ Each app gets its own:
 
 A **Zuplo account** is the top-level container for your members and projects.
 Each **Zuplo project** belongs to one account, and an AI Gateway is a type of
-Zuplo project. The providers, teams, and apps you configure for a gateway all
+Zuplo project. The providers, pools, and apps you configure for a gateway all
 belong to that project.
 
 Account roles can grant access across the projects in a Zuplo account, while
-project roles grant access to one Zuplo project. AI Gateway team roles add
-access to a team and its apps within that project. See
+project roles grant access to one Zuplo project. AI Gateway pool roles add
+access to a pool and its apps within that project. The **AI User** project role
+grants only what someone needs to call the User App with their own key. See
 [Role Permissions](../articles/accounts/roles-and-permissions.mdx) for the exact
 permissions each role grants.
 
 ## Use Cases
 
-- **Multi-tenant AI Apps**: Enforce spending limits per customer or team
+- **Multi-tenant AI Apps**: Enforce spending limits per customer or pool
+- **Everyday AI for your people**: Give everyone a personal API key with their
+  own budget for coding assistants and chat tools
 - **Agent Development**: Build AI agents that can switch providers without code
   changes
 - **Cost Management**: Control and monitor LLM spending across your gateway

package/docs/ai-gateway/policy-chains.mdx

@@ -44,7 +44,7 @@ Request
 ## Editing a chain
 
 The app's **Policies** tab shows the chain in execution order. Drag entries to
-reorder them, and click **Add Policy** to add one from the gateway's menu.
+reorder them, and click **Add policy** to add one from the gateway's menu.
 
 Each declared policy has a single **Add** button. For a policy with settings,
 Add opens its settings screen, where you confirm or change the values before the
@@ -54,7 +54,7 @@ straight into the chain with the options declared in `policies.json`.
 A policy that's already in the chain shows **Already added** instead of a
 button—edit it in the chain instead.
 
-Entries seeded by a [team policy template](./policy-templates.mdx) may be
+Entries seeded by a [pool policy template](./policy-templates.mdx) may be
 locked: a lock icon means the template controls whether this app may edit or
 remove that entry.
 
@@ -149,7 +149,7 @@ fallback. Cache hits return `429` instead of using a fallback.
 See the [policies overview](./policies/overview.mdx) for every policy an app can
 run, what each one does, and the identifier it needs in `config/policies.json`.
 Any [custom policy](./custom-policies.mdx) declared in the repository appears in
-the Add Policy dialog alongside the built-in ones.
+the Add policy dialog alongside the built-in ones.
 
 ## Configuration Executor
 
@@ -178,8 +178,8 @@ also affect when a budget change takes effect.
 The `ai-gateway-auth-inbound` policy—**API Key Authentication** in the
 portal—requires callers to present the app's API key, and it applies per app:
 add it to an app's chain to require a key for that app alone. A new top-level
-team's [policy template](./policy-templates.mdx) includes it as a locked
-entry—and sub-teams inherit that template by default—so apps created in the team
+pool's [policy template](./policy-templates.mdx) includes it as a locked
+entry—and sub-pools inherit that template by default—so apps created in the pool
 require keys from the start.
 
 Where the policy applies, clients send the app's API key as a bearer token and
@@ -206,6 +206,6 @@ isolation, controls who can reach it.
 - [Custom Policies](./custom-policies.mdx): write your own policy and add it to
   a chain
 - [Policy Templates](./policy-templates.mdx): seed consistent chains across a
-  team's apps
-- [Usage Limits](./usage-limits.mdx): budgets at the gateway, team, and app
+  pool's apps
+- [Usage Limits](./usage-limits.mdx): budgets at the gateway, pool, and app
   levels

package/docs/ai-gateway/policy-templates.mdx

@@ -2,46 +2,46 @@
 title: AI Gateway Policy Templates
 sidebar_label: Policy Templates
 description:
-  Team policy templates give every new app in a team a consistent starting
+  Pool policy templates give every new app in a pool a consistent starting
   policy chain, with per-policy controls over what each app may change or
   remove.
 ---
 
-A team's **policy template** is the policy chain that apps created in that team
-start with. Use templates to give every app in a team the same app-specific
+A pool's **policy template** is the policy chain that apps created in that pool
+start with. Use templates to give every app in a pool the same app-specific
 controls—such as Model Filtering, Budgets and Costs with an app budget, a
 guardrail, or a custom compliance policy—while controlling what individual apps
-may change. Team and gateway limits don't depend on the template.
+may change. Pool and gateway limits don't depend on the template.
 
 ## How templates apply
 
-When an app is created in a team, the team's template is copied into the app as
+When an app is created in a pool, the pool's template is copied into the app as
 its starting [policy chain](./policy-chains.mdx). From that point on, the chain
 belongs to the app.
 
-A new team's template starts with the **API Key Authentication** policy as a
-locked entry, so every app created in the team requires its API key from the
-start. A new sub-team starts by
-[inheriting its parent's template](#inheriting-from-a-parent-team) instead of
+A new pool's template starts with the **API Key Authentication** policy as a
+locked entry, so every app created in the pool requires its API key from the
+start. A new sub-pool starts by
+[inheriting its parent's template](#inheriting-from-a-parent-pool) instead of
 defining its own.
 
 :::caution{title="Template edits don't change existing apps"}
 
-A template is a starting point, not a live link. Editing a team's template
-affects apps created afterwards—it never changes the chains of the team's
+A template is a starting point, not a live link. Editing a pool's template
+affects apps created afterwards—it never changes the chains of the pool's
 existing apps. To change a running app's behavior, edit that app's chain on its
 Policies tab.
 
 :::
 
-New apps inherit their initial budget settings from their team's policy
+New apps inherit their initial budget settings from their pool's policy
 template. Configure these settings with **Budgets and Costs** in the template.
-To set a budget shared by all apps in the team, use **Usage & Limits**. See
+To set a budget shared by all apps in the pool, use **Usage & Limits**. See
 [Usage Limits](./usage-limits.mdx).
 
 ## Editing a template
 
-Open a team and select its **Policy Template** tab. The template editor works
+Open a pool and select its **Policy Template** tab. The template editor works
 like the app chain editor: add policies from the gateway's declared menu, order
 them, and configure their options.
 
@@ -55,22 +55,22 @@ you add to a template stays locked until you uncheck the boxes:
 | **Cannot delete** | Apps can't remove the entry from their chain                        |
 
 Locked entries appear in the app's chain with a lock icon and the note "Locked
-by the team policy template".
+by the pool policy template".
 
-## Inheriting from a parent team
+## Inheriting from a parent pool
 
-A sub-team can use its parent team's template instead of defining its own,
-controlled by the **Inherit from parent** switch on the sub-team's **Policy
+A sub-pool can use its parent pool's template instead of defining its own,
+controlled by the **Inherit from parent** switch on the sub-pool's **Policy
 Template** tab. The switch drafts like the page's other edits and applies when
-you click **Save changes**. While inheriting, the sub-team's template is
+you click **Save changes**. While inheriting, the sub-pool's template is
 read-only—it shows the parent's effective template. Turn the switch off to give
-the sub-team its own template: the editor starts from a copy of the parent's
+the sub-pool its own template: the editor starts from a copy of the parent's
 effective template, which you then adjust. Turning inheritance back on and
-saving discards the sub-team's own template in favor of the parent's—before you
+saving discards the sub-pool's own template in favor of the parent's—before you
 save, flip the switch again to restore your draft.
 
 ## Next steps
 
 - [Policy Chains](./policy-chains.mdx): how an app's chain executes
-- [Managing Teams](./managing-teams.mdx): creating teams and sub-teams
+- [Managing Pools](./managing-pools.mdx): creating pools and sub-pools
 - [Custom Policies](./custom-policies.mdx): put your own policy in a template

package/docs/ai-gateway/pools.mdx

@@ -0,0 +1,53 @@
+---
+title: AI Gateway Pools
+sidebar_label: Overview
+description:
+  Pools group AI Gateway apps, carry shared usage limits and policy templates,
+  and control who can manage their apps, with nested, hierarchical sub-pools.
+---
+
+Pools group AI Gateway apps so they can share budgets, a starting policy chain,
+and access. Each pool can have multiple members and sub-pools. Use pools to
+group apps by department, product, customer, or any other logical grouping.
+
+Pools hold [apps](./apps.mdx), not people's personal usage. People who call the
+gateway with their own key use the [User App](./user-apps.mdx), which has a
+per-person budget and isn't part of any pool.
+
+## Pools & Apps
+
+Every [app](./apps.mdx)—each service or integration that calls the AI
+Gateway—belongs to exactly one pool. What a pool member may do to an app depends
+on that member's role.
+
+Pools also carry a [policy template](./policy-templates.mdx)—the policy chain
+that apps created in the pool start with—and [usage limits](./usage-limits.mdx)
+that apply to the pool's own usage and all descendant sub-pools and apps.
+
+## Members
+
+Members are the users who belong to a pool. Their permissions combine their role
+in the Zuplo account, the Zuplo project that contains the AI Gateway, and the
+pool.
+
+There are two roles at the pool level:
+
+- **Member**: Can access apps owned by the pool.
+- **Admin**: Can manage the pool's settings, members, and apps.
+
+Pool roles don't grant access to AI providers. Providers are configured for the
+Zuplo project, and access to view or manage them depends on the user's Zuplo
+account or Zuplo project role. A user also needs permission to view that project
+before their pool role grants access to the pool's apps.
+
+For more information on roles and permissions, see the
+[document on roles and permissions](../articles/accounts/roles-and-permissions.mdx).
+
+**Additional Resources**
+
+- [Role Permissions](../articles/accounts/roles-and-permissions.mdx) - Details
+  on Zuplo account, Zuplo project, and AI Gateway pool roles.
+- [Creating & Editing Pools](./managing-pools.mdx) - How to create and edit
+  pools.
+- [Creating & Editing Apps](./managing-apps.mdx) - How to create, configure, and
+  delete apps.

package/docs/ai-gateway/providers.mdx

@@ -29,6 +29,8 @@ Zuplo currently supports the following AI providers:
   Gemini and Model Garden models on your own Google Cloud project
 - [OpenRouter](./openrouter.mdx)—hundreds of models from every major vendor
   behind a single API key
+- [Jev](./jev.mdx)—TypeSafe's System One model, which answers typed questions
+  about text instead of generating it
 - [Zuplo Demo](#zuplo-demo)—a free, keyless provider for trying the gateway
 - OpenAI-compatible [Custom Providers](./custom-providers.mdx) (such as Qwen,
   Kimi, etc)
@@ -47,6 +49,7 @@ The following capabilities are supported across providers:
 | Bedrock Runtime            | ❌               | ❌         | ❌        | ❌       |
 | Vertex AI                  | ✅               | ✅         | ❌        | ✅       |
 | OpenRouter                 | ✅               | ✅         | ✅        | ✅       |
+| Jev                        | ❌               | ❌         | ❌        | ❌       |
 | Zuplo Demo                 | ✅               | ❌         | ❌        | ❌       |
 | OpenAI-compatible (Custom) | ✅               | ✅         | ❌        | ❌       |
 
@@ -60,13 +63,17 @@ Messages (plus chat completions through translation), while its other models
 serve chat completions and—per model—Responses. See
 [Using Bedrock Mantle](./bedrock-mantle.mdx#supported-endpoints-by-model-family).
 
-Bedrock Runtime is the one provider with no Universal API capabilities, and the
-table above says so. It serves Amazon Bedrock's **native** API instead, at its
+Bedrock Runtime and Jev serve none of these capabilities, and the table above
+says so. Bedrock Runtime serves Amazon Bedrock's **native** API instead, at its
 own paths, so your existing AWS SDK code keeps working with the gateway in front
 of it. See [Using Bedrock Runtime](./bedrock-runtime.mdx#supported-operations)
 for the operations it serves, and add Bedrock Mantle alongside it if you also
 want Bedrock models on the Universal API.
 
+Jev serves TypeSafe's System One API instead, at `/v1/systemone`. You send it
+text and typed questions, and it returns typed answers rather than generated
+text. See [Using Jev](./jev.mdx#supported-endpoint).
+
 Azure AI's capabilities split by model family, and within the OpenAI-compatible
 family they split per deployed model: a chat model serves chat completions and—
 per model and version—Responses, while an embedding model serves embeddings and
@@ -208,6 +215,29 @@ Three things are specific to it:
 For prerequisites, provider steps, code examples, the routing shortcuts, and
 troubleshooting, see [Using OpenRouter](./openrouter.mdx).
 
+## Jev
+
+**Jev** is TypeSafe's System One model. It doesn't generate text: you send it a
+piece of text and a set of typed questions, and it returns a calibrated answer
+for each one—a probability, a choice from your options, or a score on your
+scale.
+
+Three things are specific to it:
+
+- **It has its own endpoint.** Requests go to `/v1/systemone`. Jev models are
+  refused on chat completions, Responses, Messages, and embeddings, and they
+  don't appear in the default `GET /v1/models` list.
+- **Model references are `jev/<model>`.** A provider named `jev` serves
+  `jev/jev-latest`, `jev/jev-1.13.0`, and `jev/jev-preview`. The alias names
+  move when TypeSafe ships a release, so pin a versioned name if you tune
+  thresholds against one.
+- **Only input tokens cost money.** TypeSafe charges for input tokens and not
+  for output, and the gateway prices requests from the model catalog.
+
+Guardrail policies such as DLP deny System One requests by default, because they
+can't inspect the body. For prerequisites, provider steps, code examples, and
+the policy table, see [Using Jev](./jev.mdx).
+
 ## Zuplo Demo
 
 **Zuplo Demo** is a free provider that Zuplo operates so you can try the AI

package/docs/ai-gateway/source-control.mdx

@@ -7,7 +7,7 @@ description:
 ---
 
 An AI Gateway is a Zuplo project configured for AI traffic. A new project
-deploys automatically, so you can configure providers, teams, and apps without
+deploys automatically, so you can configure providers, pools, and apps without
 connecting a Git repository. Connect one when you want to write
 [custom policies](./custom-policies.mdx), review gateway changes in Git, or
 deploy from your own CI/CD.
@@ -86,7 +86,7 @@ Three categories of changes take effect differently:
 | Change                                                            | Takes effect                                         |
 | ----------------------------------------------------------------- | ---------------------------------------------------- |
 | Repository changes (routes, `policies.json`, custom policy code)  | On the next deploy of the default branch             |
-| App policy chains, teams, budgets, and templates (portal changes) | Within about a minute, no deploy needed              |
+| App policy chains, pools, budgets, and templates (portal changes) | Within about a minute, no deploy needed              |
 | Provider settings and environment variables                       | Automatically, via a rebuild and deploy Zuplo starts |
 
 :::note

package/docs/ai-gateway/universal-api.mdx

@@ -70,6 +70,10 @@ clients that can't set a model still work.
 | `/v1/responses`        | OpenAI Responses API: OpenAI, and the OpenAI-compatible models that serve it on [Azure AI](./azure-ai.mdx), [Bedrock Mantle](./bedrock-mantle.mdx) and [OpenRouter](./openrouter.mdx)           |
 | `/v1/messages`         | Anthropic Messages API: Anthropic, and the Claude models of [Azure AI](./azure-ai.mdx), [Bedrock Mantle](./bedrock-mantle.mdx), [Vertex AI](./vertex-ai.mdx) and [OpenRouter](./openrouter.mdx) |
 
+Jev is the exception: it serves TypeSafe's System One API on `/v1/systemone`,
+which takes a state and typed questions rather than chat messages. That endpoint
+isn't part of the Universal API. See [Jev](./jev.mdx).
+
 ## Request headers
 
 The gateway forwards your request headers to the provider. A header your client