Prepare a customer launch¶
Verify a new Organization with a small synthetic workload before giving customer developers their connection details. This checklist joins the administrator and operator procedures; each linked guide contains the exact commands and recovery steps.
Prerequisites¶
An operator has installed compatible services and bootstrapped the Organization. An authorized administrator can manage people, Teams, resource allowances and the intended governance settings. Use the permission registry to divide those responsibilities when one person does not hold them all.
Use a dedicated test Team and fictional prompts. Real provider calls, tool calls, Preview and live tests can consume resources.
Procedure¶
- Verify the service boundary. Have the operator check private health/readiness, TLS and listener isolation using Health and logging. Keep the management listener and service credentials private.
- Establish administrative ownership. Verify the intended owners and sign-in path. Invite a test developer or exercise the configured enterprise identity flow. Confirm sign-in alone does not grant Team resource access.
- Prepare a minimal catalog. Configure one generation model with pricing and, if needed, one safe read-only tool. Run the configuration check, coordinate the restart, then check provider/Connector health. Validation alone does not test credentials upstream.
- Create the Team. Add members with suitable roles and explicitly set Allowed resources. Use an ordinary service account for a backend that must survive an employee leaving.
- Set limits and capture deliberately. Configure budgets, key policy, tool pricing and the intended capture policy. Give content and export permissions only to the people who need them. Test metadata-only behavior if it is part of the customer's policy.
- Complete the developer path. As the test developer, create a virtual key and make a bounded request. Verify an allowed operation and a safe denial outside the key's policy. Use a read-only tool for any tool smoke test.
- Inspect the result. Find the canonical Request, its Trace when telemetry is available, and settled Usage. Check that a viewer can see permitted metadata without protected content. Keep safe identifiers for the handoff, never the secret key.
- Check the optional managed-app path. If the customer will use Agents, test Preview, the publication review, one permitted consumer and one excluded consumer. Run Test live version separately with the intended live accounts. Add evaluation gates where required.
- Verify operational recovery. Ask the operator to complete a backup and restore verification, set up alerts, and record the deployed release and rollback procedure.
- Remove temporary access and hand off. Revoke disposable test keys and remove unneeded test audience grants after preserving the verification record. Give each customer developer the connection information below.
Developer handoff¶
| Value | Safe example | What to explain |
|---|---|---|
| Console URL | https://console.example.test |
Sign-in method and Organization |
| Inference origin | https://gateway.example.test |
SDK base URL appends /v1; MCP uses /mcp |
| Team | Support |
Where to create keys and inspect permitted evidence |
| Virtual model | support |
Confirm with GET /v1/models; names are deployment-specific |
| Credentials | Self-service key creation or approved secret delivery | One-time reveal; user versus service ownership |
| Tool access | Allowed tool names and connection mode | Company account versus the caller's personal account |
| Support route | Your designated administrator/operator | Share the error code, time, Team and correlation ID |
Do not include provider secrets or internal service credentials in this handoff. Provide a Collector endpoint only to clients that need application tracing and have telemetry.ingest.
Expected result¶
The customer can complete an authorized request, understand a denied request, inspect permitted evidence and contact the right operator. The verification record identifies the tested release, Team, safe request IDs and recovery outcome.
Verification¶
Repeat the first-request procedure under the customer's intended role, not only an administrator account. Record which optional paths were tested: tools, personal accounts, managed Agents, Chat and evaluation. No service restart is needed for subsequent live role, allowance or budget edits; file/environment changes use the documented coordinated restart.
Failure recovery¶
Do not widen an entire role or Team allowance to repair one denied operation. Identify the missing boundary with access diagnosis. For missing telemetry, investigate the Collector separately from the canonical Request and financial record. For an uncertain business call, reconcile its outcome before retrying.