Understand provider availability and model changes¶
This guide is for members, managers, executives, workspace administrators and support staff. The latest inspected 06 Final Screens governance page shows current policy, material-change status, oversight, literacy and incidents. It does not establish a verified provider-editing or model-selection journey. The frontend remains in progress, so the review steps below describe responsibilities and intended information rather than invented button paths.
Before you begin¶
Confirm which workspace and product you are using. The tenant assistant, platform staff assistant, speech services and document processing can have different readiness and access requirements. Record the task you were trying to complete and whether you already submitted it.
Do not include passwords, provider credentials, protected document text or raw prompts in a general support request. A safe reference, approximate time and short description usually allow the responsible team to find the original work.
Read the availability message¶
| Situation | What it means | What to do |
|---|---|---|
| Access or plan is unavailable | The current person or workspace does not meet an access requirement | Ask the workspace administrator to review the stated requirement |
| The capability is disabled | The feature is currently disabled for this scope | Ask the administrator to check intended availability |
| Provider approval is missing | The configured provider is not currently approved for this use | Ask the governance owner to review approval |
| The model is suspended | An operational control prevents use | Follow the incident or support process; repeated submissions do not remove the suspension |
| Configuration is incomplete or incompatible | The approved setup cannot satisfy the requested capability or policy | Let the responsible operator investigate |
| Configuration is present, connection not yet checked | Preliminary configuration and current approval checks passed | You may attempt an authorized task; connectivity, source access and credits are checked when it runs |
| A read is available without a provider check | The requested read does not require that preliminary model check | Open it if authorized; later operations still check their own requirements |
A positive configuration result is not a guarantee that the provider is reachable. A failure to start a new answer does not automatically mean that saved history, an existing approval or a previously submitted operation has disappeared.
If a conversation cannot start¶
- Confirm that you are in the intended workspace.
- Read the current availability explanation.
- Resolve any access or plan issue through the workspace administrator.
- If provider configuration, approval or suspension is mentioned, give support the safe reference and time.
- Reopen the original conversation once availability has been restored.
- Submit again only after establishing whether the earlier message created a run.
Do not try to force another provider by including its name, a web address or credentials in the prompt. Model selection is controlled by the approved server configuration.
If an answer stops after it starts¶
Keep the original conversation and run reference. A timeout or a partial answer does not establish that no provider work occurred. Closing the page does not establish cancellation or release of reserved credits.
Check the original result and its accounting status. If it remains uncertain, support must follow that operation's recovery path. Do not create another paid request just to discover whether the first one succeeded. See credits and uncertain outcomes and governed action recovery.
Different operations have different settlement rules. Missing usage is not evidence of a free request. A generic provider error also does not prove that every generated fragment is safe or complete.
What workspace administrators should check¶
Review the member's current account, workspace, role and feature access. Check the plan and available credits where the operation requires them. Keep a provider-approval problem distinct from a membership problem: changing a person's role cannot repair a missing or incompatible model deployment.
If several people report the same issue, collect a small set of safe references and a shared time range. Send them through the approved support route. Avoid repeated paid trials by every affected user.
For document knowledge, check whether the problem is upload, processing, publication or retrieval. A ready chat configuration does not establish that document extraction, search preparation or publication is healthy.
Prepare a provider or model change for review¶
The accountable change owner should describe the existing and proposed setup, the business reason, affected capabilities and intended users. Include:
- purpose, expected benefit and known limitations;
- the provider and model change, region and data-use terms;
- affected information categories, retention and oversight responsibilities;
- supplier evidence and its validity period;
- changes to answer quality, retrieval, tool behavior, latency and cost;
- the rollout scope, observation plan and rollback owner.
The same review can be necessary for a changed system instruction, tool schema, retrieval behavior or usage mapping even when the model's name is unchanged. Treat a new purpose as a decision requiring review.
Review governance and supplier evidence¶
Use the intended governance experience to inspect the current policy, effective date, material-change status and oversight information. The inspected screen also shows literacy and incident summaries. Read the relevant record and its scope; a summary count is not the underlying evidence.
The governance owner must classify the proposed change, obtain the required approval for a material change and ensure current supplier and role-specific literacy evidence. A blocked or unapproved material change must not be activated. The approval should state who is accountable for deployment, support, oversight and incident response.
An evidence label or an expiry date in a configuration file is not an independent certification of the supplier. Keep the actual evidence and approval record in the restricted governance process. See governance and incidents.
Coordinate rollout and confirm the result¶
Authorized operators and governance owners should agree on the approved configuration and policy version before rollout. Verify the actual environment, model compatibility, access behavior, retrieval, cost accounting and recovery using the approved validation process.
Communicate the affected capabilities and any temporary interruption to the appropriate audience. A successful configuration validation or a healthy process is only one part of that review. Confirm that the intended user can complete the intended action and see its authoritative result.
Keep the configuration revision, policy decision, validation evidence, rollout observations and accountable owners together. These are operational responsibilities; this documentation preview has not performed a rollout or a paid validation request.
Roll back without losing evidence¶
Rollback uses the prior approved configuration only while its approval and supplier evidence remain valid. It also needs a governed policy version representing the restored state; do not rewrite the earlier active policy or erase its history.
Confirm compatibility of retained work and knowledge. A rollback must preserve the original run, approval, reservation and processing identities for work that already started. The recovery owner must account for those operations using their saved evidence.
Reverting a setting is not proof that the service is restored, that a search generation is compatible or that every pending charge has settled. Verify the restored result and keep unresolved work visible.
Respond to suspension or a provider incident¶
Follow the incident process. The responsible operator can contain an unsafe configuration, while governance owners record and assess the incident. Members should retain original references and wait for the stated recovery path.
Reactivation requires the relevant review and current evidence. A closed incident, a new deployment or a refreshed page does not by itself remove every operational suspension. There is no automatic switch to another provider or region when approval is unavailable.
Understand the Private Cloud boundary¶
Private Cloud, private providers, private embeddings and private search storage remain disabled in the inspected configuration. Their presence in source code or a runbook does not create a self-service activation option or establish deployment readiness.
Changing from one deployment boundary to another requires its own reviewed architecture, authority, data handling and operational evidence. It is not an ordinary model retry. Do not offer it to a user as a workaround for a service outage.
What to include in a support handoff¶
Give the workspace or staff context, affected capability, safe conversation/run/document reference, approximate time and the availability message. Say whether work was submitted and whether a result or charge is still uncertain.
The support owner should identify the responsible runtime, current approval and configuration, any suspension, and the original operation's state before choosing recovery. Business owners should receive a plain-language account of impact, current limitations, decision owner and next update.