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. 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.

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 and 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 and 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 with organization credentials and Classic SDKs	A separate resource and credential model; Platform examples are not drop-in replacements
Phone and human operation	Phone and Operators	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 and provisioned service bindings	Registration, consent evidence, setup suppression, content checks, and delivery evidence are distinct; managed provisioning is separately authorized
Managed WhatsApp	WhatsApp 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	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	Sender/domain and use-case readiness; transactional/marketing policy and unsubscribe evidence remain separate from send acceptance
Browser forms	Surfaces	Form creation, link delivery, submission, and projected data are separate milestones; a submission is not automatically a dataset-intake file
Clinical documentation sessions	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	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 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, Customer Data Intake, and FHIR import	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	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	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 and current intake	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	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 when reconciling older integration assumptions.