> For the complete documentation index, see [llms.txt](https://docs.concurrence.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.concurrence.com/platform-overview/capability-availability.md). # Capability and Availability Distinguish documented interfaces, managed provisioning, separately authorized services, and preview capabilities during deployment planning. Use this matrix to identify the implementation path and the readiness questions for a proposed deployment. A documented interface is not proof that your workspace, region, credentials, or channel resources are enabled. Record those deployment-specific confirmations in the [evaluation packet](/platform-overview/evaluation-packet.md). **Private preview** means a capability is available to specifically enabled deployments under an agreed scope. Confirm enrollment, supported channels or object types, configuration, and operating limits with the implementation owner. Architecture pages can describe those capabilities alongside broadly available behavior; the access requirements determine which parts your deployment can use. Console visibility is a separate question from runtime availability. | Capability | Interface and access boundary | Readiness and limitations | | ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Platform configuration and application text | [Platform API](https://docs.concurrence.com/developer-guide/platform-api/platform-api) and [Platform SDK](https://docs.concurrence.com/developer-guide/platform-api/platform-sdk), scoped to a workspace | Requires the correct regional base, credential, and configured service; browser access needs its supported scoped flow | | Classic integrations | [Classic API](https://docs.concurrence.com/developer-guide/classic-api/core-api) with organization credentials and Classic SDKs | A separate resource and credential model; Platform examples are not drop-in replacements | | Phone and human operation | [Phone](/channels/voice.md) and [Operators](/operations-and-safety/operators.md) | Confirm phone provisioning, runtime support, and operator access. The Console does not provide takeover pages, and operators join by phone; intervention controls need a separate integration with the operator APIs. | | Managed SMS | [SMS](https://docs.concurrence.com/developer-guide/platform-api/conversations/sms) and provisioned service bindings | Registration, consent evidence, setup suppression, content checks, and delivery evidence are distinct; managed provisioning is separately authorized | | Managed WhatsApp | [WhatsApp](/channels/whatsapp.md) and managed business setup | Confirm the business/recipient identity, phone readiness, use case, and reply-window behavior; template registration is not template sending | | Managed iMessage | [iMessage](/channels/imessage.md) | Provision assigned lines and verify consent, setup suppression, first-reply sending limits, media support, and delivery evidence; provider acceptance is not delivery | | Managed email | [Email](/channels/email.md) | Sender/domain and use-case readiness; transactional/marketing policy and unsubscribe evidence remain separate from send acceptance | | Browser forms | [Surfaces](/channels/surfaces.md) | Form creation, link delivery, submission, and projected data are separate milestones; a submission is not automatically a dataset-intake file | | Clinical documentation sessions | [Scribe](https://docs.concurrence.com/developer-guide/platform-api/scribe) | Separate deployment base, provider access, supported visit type/template, and session mode; artifact generation can remain asynchronous | | Service-scoped dimension memory | [Service-Scoped Memory](https://docs.concurrence.com/developer-guide/platform-api/data-world-model/service-memory) | One memory subject per conversation. Dimension creation is public; processing, identity mapping, and authorized readers require setup. Definition edits do not rebuild history or automatically load memory. | | Additional managed code tools | Separately agreed workflow; distinct from [Platform Functions](/agent/platform-functions.md) and Classic Tools | Confirm authoring, publication, invocation, credentials, and support with the implementation owner. Source and infrastructure changes alone do not establish a public self-service contract. | | Source ingestion and querying | [World Model](/data/world-model.md), [Customer Data Intake](/data/customer-data-intake.md), and [FHIR import](https://docs.concurrence.com/developer-guide/platform-api/data-world-model/fhir) | Send records through FHIR import or authenticated dataset intake, then confirm mapping, freshness, and a queryable projection. Data-source records are stored but not polled; generic SMART FHIR, REST, file-drop, and webhook source types are not supported. | | Approval-gated integration calls | [Integration approval](https://docs.concurrence.com/developer-guide/platform-api/integrations/approval-gated-integration-writes) | Enabled per integration on supported text/SMS paths; a decision is consumed on the next supported turn and is not external delivery proof | | HL7v2 inbound and outbound | [HL7v2 ADT/SIU and hospital messages](/data/healthcare-interoperability.md) | Integration design required; no native receiver or sender verified. Agree on message profiles, direction, acknowledgment, replay, and measured freshness. | ## Console Visibility and Separate Services These distinctions do not certify deployment or enrollment. Confirm access for the intended workspace before relying on a capability. | Capability | Interface | Console access | Readiness | | ----------------------------- | -------------------------------- | ------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | Scribe clinical documentation | Separate provider API and schema | Use the provisioned provider workflow | Confirm Scribe base, provider enrollment, capture mode, visit type/template, and processing region separately from Platform workspace access. | ## Record a Deployment Confirmation For every capability in the pilot, record the intended region, API or managed service, access owner, required configuration, evidence of enablement, remaining limitation, and review date. Use explicit states: **confirmed in this test deployment**, **awaiting provisioning**, **not included**, or **requires separate preview agreement**. A future proposal should have its own record and decision date. Do not place it in the confirmed column because it appeared in a demonstration or a source commit. Use the implementation links for current contracts and [upgrade guidance](https://docs.concurrence.com/api-reference/change-logs/upgrade-guide) when reconciling older integration assumptions. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.concurrence.com/platform-overview/capability-availability.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.