CT-AI Operations & Support Handoff
This page is the operator checklist for CT-AI. It describes the supported surfaces and the evidence required before treating a deployment as ready for general availability. It does not replace your organization's access policy, retention policy, or release approval.
Choose a deployment path
Connected deployment
Use a connected deployment when the selected model provider is reachable from the Call Telemetry appliance or server.
- Confirm that CDR/CMR data is arriving in Reporting.
- In Settings > AI Settings, select the provider and model, then use Test Connection.
- Confirm that the test uses the organization's approved data and residency policy. A provider being selectable is not evidence that a model is approved for production.
- Run a read-only question with a narrow time range and inspect its citations and deep links.
See Getting Started for the administrator setup and Security & PII for data handling controls.
Air-gapped or offline deployment
Use an on-premises Ollama endpoint when the environment cannot send inference requests outside its network perimeter. The endpoint, model artifact, and upgrade bundle must be approved by the platform owner before use.
The offline path still needs the same application checks: organization access, evidence availability, refusal behavior, and read-only guarantees. “Offline” describes network placement; it is not a substitute for a model qualification receipt. See the air-gapped upgrade procedure for appliance operations.
Preflight before a support handoff
Record these values with the handoff ticket or release record:
| Check | Required evidence |
|---|---|
| Build identity | Exact server/appliance version and commit or bundle identity |
| Model identity | Provider, model ID, endpoint mode, and qualification date |
| Compatibility | The dated preflight result for the selected provider/model |
| Evidence | A bounded test question with citations and links that resolve |
| Access | A permitted user can read the result; a revoked or cross-organization user cannot |
| Safety | Refusal and unavailable-source behavior are visible and fail closed |
| Handoff | Export or support link contains the investigation context without secrets |
Keep the qualification receipt with the release record. A dated “tested by Call Telemetry” badge describes the tested reference configuration; it does not approve a customer's model choice or imply that every provider is equivalent.
Evidence and confidence semantics
CT-AI answers are grounded in the records returned by the selected capability. Operators should be able to distinguish:
- Available evidence — a citation resolves to a record or report in the current organization and time range.
- Unavailable evidence — the source could not be read, has been revoked, or is outside the permitted scope. The answer must say so rather than fill the gap with an assertion.
- Refusal or denial — the request is outside the user's access, asks for a mutation, or cannot be completed safely. A refusal is an expected safety result, not a partial success.
- Model confidence — explanatory language from the model. It is not a replacement for a citation, a test receipt, or an operator decision.
When a result matters, follow its deep link and verify the underlying record. Do not promote a response to a root-cause finding solely because it sounds confident.
Files, exports, and handoff
Use the application's configured file and payload limits. If a file or result is too large, split the investigation into bounded ranges or use the relevant report rather than disabling the limit. Limits protect both the tenant and the model context window.
Exports and handoff links should contain the investigation identifier, selected time range, citations, and the user's permitted summary. They must not contain API keys, raw provider prompts, hidden system instructions, or data from another organization. Treat an export as tenant data and apply the same retention and sharing policy as the source record.
The REST surface is documented in the generated API reference:
Trust and routing disclosure
CT-AI is advisory and read-only. The model selects from structured capabilities; it does not receive direct SQL, shell, database, or arbitrary network access. Provider routing can change which eligible endpoint handles a request. The organization's routing, residency, privacy, and provider allowlists remain the source of truth. Do not describe an aggregator's fallback behavior as a guarantee of a particular provider.
For the design record and threat-model decisions, link the release handoff to the applicable ADR and the exact build receipt. If the ADR, build, model, or receipt does not match, keep the handoff blocked and escalate instead of silently substituting a different model.
What CT-AI will never do
The CT-AI contract is read-only and fail-closed:
- it does not place calls, change CUCM configuration, or mutate policies;
- it does not bypass organization membership, role, license, or source grants;
- it does not disclose records that are unavailable, revoked, or outside the organization;
- it does not turn an uncited model explanation into verified evidence; and
- it does not treat a missing provider/model capability as a successful result.
If an operator needs to change configuration, use the normal authenticated administration workflow and record that change separately from the AI investigation.
Troubleshooting checklist
- No data returned: verify CDR/CMR ingestion and the question's time range.
- Access denied: re-check organization membership, role, license, and source grants; do not broaden access just to make a prompt succeed.
- Unavailable citation: open the linked report and confirm the source is still retained and permitted.
- Provider/model preflight failure: keep the release blocked until the approved endpoint and model pass the same receipt contract.
- Support escalation: attach the exact build/model/receipt identities and a redacted prompt/result summary. Never attach API keys or raw provider payloads.