> 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 October 12, 2026, after the connector runner was retired on October 10, 2026; see [Connectors and EHR](/data/connectors-and-ehr.md). 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 phone provisioning, runtime support, and operator access. Console takeover pages and browser operator joining are retired; retained APIs require a separate integration. | | 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 since the connector runner was retired on October 10, 2026; generic SMART FHIR, REST, file-drop, and webhook source types are retired. | | 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) | Retired with the connector runner on October 10, 2026. Existing proposals stay readable, but new proposals are not staged and an approved proposal is not delivered; direct-integration approvals are separate. | | 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-10-12. 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 | Review of proposals staged before the connector runner was retired; approval does not deliver a write | Internal tooling | No new proposals are staged and an approved proposal is not delivered. 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 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.