> 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, preview capabilities, and retired paths during deployment planning. Use this matrix to identify the implementation path and the readiness questions for a proposed deployment. It reflects the documented contract reviewed on September 7, 2026. 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. **Design direction** identifies a proposed contract or extension. The [object-memory](/agent/memory.md#design-direction-object-memory) and [Universal Reasoning Harness](/agent/reasoning-engine.md#design-direction-universal-reasoning-harness) sections use this label for work beyond the documented current paths. It does not imply private-preview enrollment or general 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 service configuration, phone provisioning, runtime/provider behavior, and operator phone access; browser operator joining is retired | | 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) | Provisioned lines and provider/device support; confirm media and delivery behavior for the intended deployment | | 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 | | Source ingestion and querying | [World Model](/data/world-model.md), [Connectors](/data/connectors-and-ehr.md), and [Intake](/data/customer-data-intake.md) | Confirm an active EHR, FHIR-store, or warehouse adapter, mapping, freshness, and queryable projection. Generic SMART FHIR, REST, file-drop, and webhook source types are retired; authenticated dataset intake is separate. | | 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 | | Connector write-back review | [Review Queue](/data/review-queue.md) | Separately enabled private preview; do not infer general availability from direct-integration approvals | | Standalone ringless voicemail / public upload links | [Voicemail retirement](/channels/voicemail.md) and [current intake](/data/customer-data-intake.md) | Retired paths; ordinary outbound-call voicemail handling and authenticated dataset intake are separate retained behaviors | | 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 Source classifications reviewed 2026-09-07. 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. | | Proactive Journeys | Demo presentation | Synthetic sample data in permitted demo workspaces | Use for evaluation of the presentation only; it does not establish live patient journeys or customer enablement. | | Agent Memory Console surface | Demo presentation; distinct from runtime memory behavior | Synthetic sample data in permitted demo workspaces | Do not use this display as evidence of a workspace's retained memory or queryable records. | | Outbound Write Approvals Console surface | Related connector write-back review is separately enabled preview functionality | Internal tooling | Arrange the supported review process with the implementation owner. This differs from conversation-scoped direct-integration approvals. | | Simulation Coverage Console surface | Interface access and Console visibility are separate | Internal tooling | Confirm the supported evaluation and reporting path for your workspace; a coverage API contract does not grant Console 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` 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 optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.