> 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/api-reference/change-logs/amigo-api/amigo-api-history-02.md).
# API History: Archive 2
Retained API history, archive 2, with original entry headings and links back to current integration guidance.
Historical entries retain their original release/source context. Use [Current Upgrade Guidance](/api-reference/change-logs/upgrade-guide.md) for current integration boundaries and [API](/api-reference/change-logs/amigo-api.md) for the recent history and archive index. An older entry does not establish current availability.
Platform: Data Warehouse Connector Source Type (July 2026)
#### Data Warehouse Connector Source Type
The connector framework now supports data warehouse sources as a first-class source type, enabling direct ingestion from analytics marts into the world model.
**What changed:**
* **New warehouse source type.** Data sources can now be configured with a warehouse source type that reads from analytics mart tables over HTTP-based SQL APIs. The connector authenticates using key-pair JWT with an RSA private key stored in the platform's secret manager - no password or interactive credential flow is required.
* **Full-snapshot polling with diff-based emission.** Each configured query returns the complete current contents of a mart table on every poll cycle. The platform diffs each snapshot against the prior poll and emits only created and updated records, keeping downstream processing efficient without requiring incremental query logic in the mart.
* **Per-query cadence and safety ceilings.** Each query within a warehouse data source has its own poll cadence and a configurable row ceiling. If a result exceeds the ceiling the poll fails rather than silently truncating, because a partial snapshot would cause the diff to misidentify present rows as removed.
* **Removal detection without false cancellations.** When a row leaves the snapshot between polls, the platform logs the removal but does not emit a cancellation event. Rows leave analytics marts for many reasons - the underlying record was completed, aged out of a rolling window, or was legitimately cancelled - and the platform cannot distinguish these cases. The last-known state of the record is preserved.
* **Confidence-aware entity emission.** Resources derived from a warehouse mart are emitted at a lower confidence tier than records read directly from an EHR API. This prevents a sparse warehouse projection from overwriting richer demographic data that arrived through a primary clinical connector.
* **Connection configuration is fully declarative.** Account, user, role, warehouse, database, schema, and per-query SQL are all specified in the data source connection configuration. Onboarding a new warehouse tenant requires a configuration entry, not a code change.
**What you need to do:**
* **No action required for existing data sources.** This is a new source type. Existing connectors and data sources are unaffected.
* **To connect a warehouse:** Work with your platform operator to register a warehouse data source with the appropriate connection details and RSA key-pair credential. Share the public key with your warehouse administrator for service-user registration.
Platform: Keyless Credential for Google Drive Intake Sources (July 2026)
#### Keyless Credential for Google Drive Intake Sources
Google Drive intake sources now authenticate using a unified platform-managed service account with no key material to provision, store, or rotate.
**What changed:**
* **No per-source credential provisioning.** Newly registered Drive intake sources authenticate as the platform's unified intake service account. There is no secret key to upload, no parameter path to manage, and no out-of-band provisioning step. Share the target folder with the service account email provided by your platform operator, or configure domain-wide delegation if your organization's policy requires it.
* **`credential_ssm_param_path` is now optional on intake source responses.** Sources registered before this change retain their existing credential path. Sources registered after this change return `null` for this field, indicating keyless authentication.
* **Existing sources continue to work.** Sources that were registered with a per-workspace credential path continue to use that credential. Migration to the keyless model is workspace-scoped and managed by the platform operator.
* **Registration no longer requires a follow-up provisioning step.** Previously, registering a Drive intake source returned a credential path that an operator had to populate before the first sync. New sources are ready to sync as soon as the Drive folder is shared with the platform service account.
**What you need to do:**
* **For new sources:** Share the Drive folder with the platform intake service account email (provided by your platform operator) and register the source. No additional credential setup is needed.
* **If you parse the `credential_ssm_param_path` field:** Update your integration to handle `null` values. A `null` value means the source uses keyless authentication and no secret exists to manage.
* **Existing sources require no changes.** Previously provisioned credentials continue to work.
Scribe: Second Diagnosis-Confirm Gate for Therapy Progress Documentation (July 2026)
#### Second Diagnosis-Confirm Gate for Therapy Progress Documentation
The therapy progress documentation template now includes a second diagnosis-confirm gate at the plan sign-off step, along with guidance text on the first gate.
**What changed:**
* **Second diagnosis-confirm gate.** Therapy progress notes now require a second confirmation of the diagnosis at the plan sign-off stage. This adds a verification checkpoint that ensures diagnostic consistency between the assessment and plan sections of the note.
* **Guidance on the first gate.** The existing first diagnosis-confirm gate now includes guidance text to help clinicians understand the confirmation step.
* **Therapy progress template version advanced.** The therapy progress template version pin has been updated to reflect the schema shape change. The other three template types (psychiatric intake, psychiatric progress, therapy intake) are unchanged. Integrations that match on the therapy progress template version should expect the new version identifier.
**What you need to do:**
* **No action required for most integrations.** The new gate is additive to the therapy progress workflow. If your integration validates template versions for therapy progress notes, update your expected version value to match the new pin.
Scribe: CPT Location Gates, Charge Coding, and Interventions Grid for Documentation Templates (July 2026)
#### CPT Location Gates, Charge Coding, and Interventions Grid for Documentation Templates
Automated medical documentation templates now support CPT-based location gating, charge coding fields, and a structured interventions grid across all template types.
**What changed:**
* **CPT location gates.** Documentation templates can now gate available sections and fields based on the CPT code associated with the encounter location. This ensures that clinicians see only the fields relevant to the service context.
* **Charge coding support.** Templates now include structured charge coding fields, allowing billing-relevant codes to be captured alongside clinical documentation within the same note workflow.
* **Interventions grid.** A structured interventions grid is now available in templates, supporting tabular capture of clinical interventions with associated details.
* **Template version pins advanced.** All four template types (psychiatric intake, psychiatric progress, therapy intake, therapy progress) have updated version pins to reflect the schema shape changes. Integrations that match on template version should expect the new version identifiers.
**What you need to do:**
* **No action required for most integrations.** The new fields and gates are additive. Existing note generation and finalization workflows continue to work. If your integration validates template versions, update your expected version values to match the new pins.
Scribe: End-to-End Session Traceability in Observability Logs (July 2026)
#### End-to-End Session Traceability in Observability Logs
Automated medical documentation sessions are now traceable across their full lifecycle in platform observability logs, from creation through generation to finalization.
**What changed:**
* **Session lifecycle events carry a consistent session identifier.** Core lifecycle log events - session created, session ended, session cancelled, generation succeeded, generation failed, note finalized, and finalize blocked - now include the session identifier as a structured facet. This lets operations teams filter and correlate a single session's journey end-to-end in log dashboards.
* **Generation log messages include artifact type.** Success and failure log messages for generation jobs now name the artifact type inline, improving at-a-glance readability when scanning log streams.
* **Blocked finalize events logged.** When note finalization is rejected by validation gates, a warning-level event is emitted with the session identifier, the number of blocking errors, and the affected field paths. No document content or field values are included.
**What you need to do:**
* **No action required.** These are server-side observability improvements. No API, request, or response changes are involved. If you build dashboards or alerts against platform log facets, you can now filter by session identifier across all lifecycle events for a documentation session.
Platform: Voice Turn Authentication Fix for Multi-Workspace Deployments (July 2026)
#### Voice Turn Authentication Fix for Multi-Workspace Deployments
Voice turn requests now authenticate correctly across all workspaces. Previously, voice turns returned 403 errors for every workspace other than the platform's own home workspace.
**What changed:**
* **Voice turns work for all workspaces.** The voice turn endpoint now correctly validates the caller's authorization against the target workspace. Previously, an internal credential mismatch caused every customer workspace to receive a 403 Forbidden response, effectively breaking voice turns for all external workspaces.
* **Two-layer authorization enforced.** Voice turn requests now carry both the internal service credential and the original caller's authorization. The service credential proves the internal hop, while the caller credential binds the turn to the correct workspace. This matches the authorization contract already used by text turns.
**What you need to do:**
* **No action required.** This is a server-side fix. Voice turn requests that were failing with 403 will now succeed without any client changes. If you implemented workarounds for voice turn failures, those workarounds can be removed.
Scribe: Runtime Toggle for Finalize Content Validation (July 2026)
#### Runtime Toggle for Finalize Content Validation
The finalize gate for automated medical documentation notes now supports a runtime feature flag that can selectively disable the content and completeness checks while preserving structural integrity validation.
**What changed:**
* **Content validation can be toggled off per workspace.** A runtime feature flag allows the platform to skip the content and completeness gates during finalize - specifically the required-field presence checks, the diagnosis-required gate, and the overall review confirmation requirement. When this flag is enabled for a workspace, notes can be finalized without meeting those requirements.
* **Structural integrity always enforced.** Regardless of the flag state, structural validation of the note document is always performed. A malformed document still fails finalization even when content checks are disabled.
* **Default behavior unchanged.** The flag is off by default. When the flag is not enabled, finalize validation behaves exactly as before - all required fields, diagnosis requirements, and review confirmation must be satisfied.
* **Workspace-level targeting.** The flag can be targeted to specific workspaces, allowing selective rollout without affecting other workspaces.
**What you need to do:**
* **No action required.** The default behavior is unchanged. If your workspace is enrolled in this toggle, notes may finalize without all required fields populated or review confirmed. Client-side validation remains recommended to ensure clinical completeness regardless of server-side gate behavior.
Scribe: Stronger Model for Note Generation (July 2026)
#### Stronger Model for Note Generation
Automated medical documentation note generation now uses a higher-capability model, reducing structured-output validation failures.
**What changed:**
* **Improved note generation reliability.** The note generation pipeline now routes to a stronger model tier that adheres more reliably to the structured-output schema required by documentation templates. Other generation types - summaries, codes, actions, checklists, and Ask - remain on the previous model tier to preserve cost and latency characteristics.
* **Better observability on generation outcomes.** Both successful and failed generation events now record which model produced the result, making root-cause analysis of any remaining failures easier to trace.
**What you need to do:**
* **No action required.** The model upgrade applies automatically to all note generation. You may observe a reduction in terminal generation failures - previously around 3% over a 24-hour window - where notes failed template validation after repair. No API, request format, or response format changes are involved.
Scribe: Per-Section Confirmation No Longer Required Before Finalize (July 2026)
#### Per-Section Confirmation No Longer Required Before Finalize
Finalizing an automated medical documentation note no longer requires each section to be individually confirmed. The overall review confirmation remains required.
**What changed:**
* **Section-level confirmation gate removed.** Previously, every section marked as needing confirmation had to be individually confirmed before a note could be finalized. This per-section gate has been removed. Finalization still requires that all required fields carry values and that the overall review is confirmed.
* **Simpler finalize workflow.** Clinicians and integrations no longer need to track and confirm each section independently. The finalize validation checks required field completeness and the overall review confirmation, reducing the number of steps before a note can be completed.
**What you need to do:**
* **No action required for most integrations.** If your integration was setting per-section confirmations solely to pass the finalize gate, that step is no longer necessary. The finalize endpoint accepts notes without per-section confirmations as long as required fields are populated and the overall review is confirmed.
* **Update client validation if applicable.** If your client enforces per-section confirmation before allowing the user to finalize, you can remove that requirement to match the new server behavior.
Scribe: Informed Consent Registered as a Standalone AMD Section (July 2026)
#### Informed Consent Registered as a Standalone AMD Section
The informed-consent section is now registered as its own entry in the automated medical documentation (AMD) template registry, rather than being embedded within another section.
**What changed:**
* **Standalone informed-consent section.** The informed-consent portion of automated medical documentation is now a first-class section in the AMD template registry. Previously it was bundled inside another section, which limited the ability to configure, reorder, or selectively include it.
* **Independent configuration.** Because informed consent is now its own section, workspaces can include or exclude it independently when assembling documentation templates.
**What you need to do:**
* **No action required.** Existing AMD templates continue to produce informed-consent content. Workspaces that want finer control over section ordering or inclusion can now reference informed consent as a standalone section.
Platform: AI Metric History Now Accumulates Across Runs (July 2026)
#### AI Metric History Now Accumulates Across Runs
AI-scored metric results now accumulate over time instead of being replaced wholesale on every scheduled run.
**What changed:**
* **Scoped metric writes.** Each scheduled metric computation run now replaces only the workspace-and-metric combinations it actually recomputed, within the time window it evaluated. Previously, every run overwrote the entire results table, so only the most recent run's scores were retained - effectively capping metric history to a single evaluation window.
* **Historical scores preserved.** Judge-based quality metrics and classifier metrics (such as AI-scored call quality and event classification results) now retain results from prior runs. Dashboards and trend views that query these tables can display score progression over days and weeks rather than showing only the latest window.
* **No empty-table resets.** When a run produces no results for a given metric pipeline - for example, because no new eligible interactions arrived - the existing data is left untouched. Previously, an empty run would overwrite the table with zero rows, erasing all prior history.
* **Input validation on metric configuration.** Workspace and metric identifiers used in scheduled metric runs are now validated before evaluation begins. Configurations with malformed identifiers are skipped with a log message rather than causing a run-level failure.
**What you need to do:**
* **No action required.** The change is automatic. If you have dashboards or alerts built on AI metric result tables, you may notice that historical data now persists across runs. Trend analysis and drift detection workflows will see richer history going forward. Data written before this change that was already overwritten cannot be recovered.
Scribe: Distinct Error When Zoom Meeting Has Not Started (July 2026)
#### Distinct Error When Zoom Meeting Has Not Started
Starting a Zoom session now returns a specific error code when the Zoom meeting has not started yet, instead of a generic dispatch failure.
**What changed:**
* **`zoom_meeting_not_started` error code.** When a clinician attempts to start a Zoom session before the host has started the Zoom meeting, the API now returns HTTP 409 with the error code `zoom_meeting_not_started` and a message instructing the clinician to start the meeting first. Previously this condition produced a generic 503 `bot_dispatch_failed` error.
* **Actionable retry flow.** Because the error is a 409 conflict rather than a 503, clients can distinguish "start your meeting first" from a transient infrastructure problem and present targeted guidance instead of a generic retry prompt.
* **Clean retry after resolution.** When the meeting-not-started condition is detected, any partially created session state is cleaned up automatically, so the clinician can retry cleanly once the Zoom meeting is live.
**What you need to do:**
* **Handle the new error code in client applications.** If your integration consumes the Zoom session creation endpoint, check for HTTP 409 with code `zoom_meeting_not_started` and prompt the user to start their Zoom meeting before retrying. Existing handling of 503 `bot_dispatch_failed` continues to work for genuine dispatch failures.
Platform: Design Agent Session Collector (July 2026)
#### Design Agent Session Collector
The platform now captures design agent session transcripts for internal observability. A new write-only endpoint accepts full session transcripts from the design agent tooling and durably persists them for downstream analysis.
**What changed:**
* **Session transcript collection.** A new endpoint accepts complete design agent session transcripts as newline-delimited JSON. Each upload is durably stored before the endpoint returns success, ensuring no session data is silently lost. Uploads that exceed 25 MB are rejected with a 413 status.
* **Write-only authentication.** The collector uses a dedicated shared token separate from platform API keys. This token grants write access to the session collector only and does not provide read access to any platform resources.
* **Region-scoped availability.** The collector endpoint is available in the us-east-1 region only. Requests to other regions return 404.
* **Rate limiting.** The endpoint uses a dedicated rate-limiting bucket with generous headroom for normal usage patterns, independent of the standard write rate limit.
* **Downstream parsing.** Stored transcripts are parsed asynchronously into structured event rows by a scheduled job. Parsing is best-effort and re-runnable - the raw transcript is the source of truth and can be reprocessed if the parsing logic is updated.
**What you need to do:**
* **No action required.** This is an internal observability feature. Design agent tooling submits transcripts automatically when configured. The collector does not affect existing API behavior or workspace resources.
Platform: Per-Source AI Call Attribution for Cost Caps (July 2026)
#### Per-Source AI Call Attribution for Cost Caps
The daily AI-call cost cap now tracks usage per pipeline source rather than pooling all AI calls into a single counter per workspace.
**What changed:**
* **Source-level attribution.** Each analytics pipeline - standard metric scoring and topic classification - now records its AI-model calls under its own source label. Daily caps are evaluated per workspace, per UTC day, and per source, so one pipeline reaching its limit does not block another.
* **Topic modeling calls metered independently.** Topic classification AI spend is attributed and metered as a distinct source. This appears as a separate line in the unified metering projection, giving billing and cost dashboards visibility into classifier spend without conflating it with other metric computations.
* **Backward-compatible migration.** Workspaces with existing usage history are migrated automatically. Historical rows that predate source attribution are labeled as unknown and do not count against any specific pipeline's cap.
**What you need to do:**
* **No action required.** The migration is automatic. Existing daily cap configurations continue to apply per workspace per source. If you monitor cost cap behavior through dashboards or alerts, note that totals are now broken out by source rather than aggregated.
Platform: Topic Modeling Gated by Permission (July 2026)
#### Topic Modeling Gated by Permission
Topic modeling settings are now controlled by a dedicated permission instead of requiring an Amigo administrator.
**What changed:**
* **New `TopicModeling:Manage` permission.** Reading and updating topic modeling settings now requires the `TopicModeling:Manage` permission on the workspace. This replaces the previous restriction that limited topic modeling changes to Amigo administrators.
* **Admin and owner roles granted by default.** The `TopicModeling:Manage` permission is included in the admin role. Members, operators, and viewers cannot enable or modify topic modeling settings.
* **Amigo-administrator email check removed.** The endpoints no longer verify that the caller's email belongs to the Amigo domain. Any workspace credential with the `TopicModeling:Manage` permission can read or update topic modeling settings.
**What you need to do:**
* **No action required for admin or owner credentials.** These roles already include the new permission.
* **Update integrations that relied on Amigo-administrator access.** If an external workflow previously depended on an Amigo administrator to change topic modeling settings, a workspace admin can now perform the change directly.
* **Grant the permission to custom roles if needed.** If your workspace uses custom roles that need topic modeling access, add `TopicModeling:Manage` to those roles.
Scribe: Provider-Authored ICD-10 Codes and Generation-Decoupled Code Reads (July 2026)
#### Provider-Authored ICD-10 Codes and Generation-Decoupled Code Reads
Clinicians can now add their own ICD-10 codes to a session and edit those codes inline, independent of AI-generated suggestions. The codes read endpoint returns all codes on a session - both AI-generated and provider-authored - without requiring a codes generation to have run.
**What changed:**
* **Add provider-authored codes.** A new endpoint lets clinicians add ICD-10 codes directly to a session. Provider-authored codes are automatically marked as approved on creation (adding a code is an affirmative act), so they count toward the finalize diagnosis gate immediately. Adding a code does not require an AI codes generation to exist on the session.
* **Edit provider-authored codes.** The existing code decision endpoint now accepts optional text edits (code, description, rationale) alongside the approve/reject decision. Text edits are accepted only for provider-authored codes. Attempting to edit the text of an AI-generated suggestion returns a validation error directing the clinician to reject the AI suggestion and add a new provider code instead.
* **Decision field is now optional on code updates.** The code decision endpoint no longer requires a decision in every request. At least one field (decision, code, description, or rationale) must be present. This allows pure text edits on provider-authored codes without changing the decision.
* **Codes read is session-scoped.** The codes read endpoint now returns every code owned by the caller on the session, including both AI suggestions and provider-authored codes. It no longer returns 404 when no AI codes generation has run. The generation status field is advisory metadata about the AI generation only - items are authoritative regardless of generation status.
* **Code responses include provenance.** Code suggestion and code decision responses now include a provenance indicator distinguishing AI-generated suggestions from provider-authored codes. Clients can use this to determine whether a code row supports text editing.
**What you need to do:**
* **Update code list rendering.** If your integration reads session codes, it now receives provider-authored codes alongside AI suggestions. Use the provenance indicator to determine whether to show text-edit controls (provider codes) or approve/reject-only controls (AI codes).
* **Handle the new provenance field.** Code responses include a new provenance field. If your client deserializes code responses into typed models, add the field to avoid parsing errors.
* **Remove 404 handling for missing codes generations.** The codes read endpoint no longer returns 404 when no AI generation has run. If your integration treated that 404 as "codes not ready," update it to handle an empty items list with a ready generation status instead.
Platform: Circuit Breaker on World Events Serving Reads (July 2026)
#### Circuit Breaker on World Events Serving Reads
The world events OLAP serving path now applies a per-pod circuit breaker and a tighter request-budget-aligned timeout to flag-gated serving reads. This prevents a slow or degraded warehouse from pinning request coroutines and cascading latency into unrelated requests.
**What changed:**
* **Tighter timeout for serving reads.** Flag-gated serving reads now use a shorter timeout aligned to the overall request budget. If the warehouse does not respond within that window, the read fails fast rather than holding the connection for the longer diagnostic default.
* **Circuit breaker on repeated failures.** Consecutive warehouse failures or timeouts on the serving path trip a per-pod circuit breaker. While the breaker is open, subsequent serving reads return an immediate 503 instead of attempting the warehouse call, reducing pressure on a degraded backend.
* **Automatic recovery.** After a brief recovery window, the breaker transitions to half-open and allows a probe request through. If the probe succeeds, normal traffic resumes. If it fails, the breaker reopens.
* **Diagnostic and long-running reads unaffected.** Heavier diagnostic queries - such as prompt log scans and trace projections - continue to use their own timeouts and are not routed through the circuit breaker. The raw-ledger read path is also unaffected.
**What you need to do:**
* **No action required.** This is a resilience improvement. If your integration consumes world events through the serving path, be aware that a degraded warehouse may now produce 503 responses more quickly than before. Retry with backoff as you would for any 503.
Platform: Operator Dashboard Timeline Reads Migrated to Optimized Serving Path (July 2026)
#### Operator Dashboard Timeline Reads Migrated to Optimized Serving Path
Operator dashboard timeline readers - escalation statistics, escalation event lists, audit event lists, and call transcript lookups - now serve data from the same optimized per-workspace serving path used by the earlier timeline and analytics migrations. The migration is controlled by a per-workspace feature flag and falls back to the previous path when the flag is off.
**What changed:**
* **Dashboard escalation and audit reads use the optimized path.** Daily escalation statistics, escalation event counts (grouped by status, trigger, or operator), escalation event lists, operator audit event lists, and call transcript reads now resolve through the optimized serving layer when the workspace is enrolled. Response shapes are unchanged.
* **Generic data query endpoint no longer exposes the event timeline table.** The generic column-filter-sort data query endpoint previously allowed arbitrary queries against the event timeline mirror. This table has been removed from the generic endpoint. Callers should use the dedicated timeline endpoints (entity timeline, MCP entity timeline) instead, which are already backed by the optimized path.
* **Per-workspace rollout.** The migration is gated by a per-workspace flag. Workspaces that have not been enrolled continue to read from the previous path with no behavior change.
**What you need to do:**
* **No action required for dashboard users.** The operator dashboard reads the same data with the same response shape. Performance may improve for workspaces enrolled in the optimized path.
* **Update integrations that queried the event timeline through the generic data endpoint.** If you used the generic data query endpoint to read event timeline rows with arbitrary column filters, switch to the dedicated entity timeline endpoints. The generic endpoint no longer serves that table.
Platform: Remaining Timeline Readers Migrated to Optimized Serving Path (July 2026)
#### Remaining Timeline Readers Migrated to Optimized Serving Path
Enrichment history, simulation evaluation, research entity timeline, and data source event statistics now support the same optimized per-workspace serving path used by the earlier timeline and analytics migrations.
**What changed:**
* **Per-workspace cutover for remaining timeline readers.** Workspaces enrolled in the migration now read enrichment history, simulation evaluation results, research entity timelines, and data source event counts and daily histories from the optimized materialized view. The cutover is controlled by the same per-workspace feature flag as the earlier timeline and analytics migrations, allowing incremental rollout and instant rollback.
* **Fail-safe default.** Workspaces without the flag enabled, or where flag evaluation encounters an error, continue reading from the existing source. No workspace experiences a change in behavior unless explicitly enrolled.
* **Response shape unchanged.** The optimized path returns the same fields and value shapes as the previous source. Enrichment history entries, simulation evaluation results, entity timeline rows, and data source statistics are identical for API consumers regardless of which path is active.
* **Workspace-scoped access unchanged.** The optimized path enforces the same workspace-scoped access boundaries as the previous source. Cross-workspace reads remain impossible regardless of which path is active.
**What you need to do:**
* **No action required.** The migration is transparent to API consumers. Query results, response shapes, and access controls are unchanged. Workspaces are enrolled by the platform team as the rollout progresses.
Platform: Analytics Summary Reads Migrated to Optimized Serving Path (July 2026)
#### Analytics Summary Reads Migrated to Optimized Serving Path
Connector health, event velocity, event type summaries, and sense-act loop latency reads now support an optimized per-workspace serving path, controlled by the same per-workspace feature flag used for the timeline migration.
**What changed:**
* **Per-workspace analytics cutover.** Workspaces enrolled in the migration now read connector health, event velocity, event type summaries, and loop latency data from an optimized materialized view. The cutover is controlled by the same per-workspace feature flag as the timeline migration, allowing incremental rollout and instant rollback.
* **Fail-safe default.** Workspaces without the flag enabled, or where flag evaluation encounters an error, continue reading from the existing source. No workspace experiences a change in behavior unless explicitly enrolled.
* **Response shape unchanged.** The optimized path returns the same fields and value shapes as the previous source. Connector health, event velocity, event type summary, and loop latency responses are identical for API consumers regardless of which path is active.
* **Workspace-scoped access unchanged.** The optimized path enforces the same workspace-scoped access boundaries as the previous source. Cross-workspace reads remain impossible regardless of which path is active.
**What you need to do:**
* **No action required.** The migration is transparent to API consumers. Query results, response shapes, and access controls are unchanged. Workspaces are enrolled by the platform team as the rollout progresses.
Platform: Per-Workspace Timeline Read Migration to Materialized View (July 2026)
#### Per-Workspace Timeline Read Migration to Materialized View
The research query service now supports reading timeline data from an optimized materialized view instead of the previous federated mirror, controlled by a per-workspace feature flag.
**What changed:**
* **Per-workspace materialized view cutover.** Workspaces enrolled in the migration read entity event timeline data from a new materialized view that serves the same columns as the previous source. The cutover is controlled by a per-workspace feature flag, allowing incremental rollout and instant rollback.
* **Fail-safe default.** Workspaces without the flag enabled, or where flag evaluation encounters an error, continue reading from the existing source. No workspace experiences a change in behavior unless explicitly enrolled.
* **Workspace-scoped access unchanged.** The materialized view enforces the same workspace-scoped access boundaries as the previous source. Cross-workspace reads remain impossible regardless of which path is active.
**What you need to do:**
* **No action required.** The migration is transparent to API consumers. Query results, column shapes, and access controls are unchanged. Workspaces are enrolled by the platform team as the rollout progresses.
Scribe: No-Diagnosis Attestation Waives Diagnosis Finalize Gate (July 2026)
#### No-Diagnosis Attestation Waives Diagnosis Finalize Gate
The structured-note finalize gate now accepts an explicit clinician attestation that no diagnosis is applicable, removing the requirement to have at least one approved diagnosis before a note can be finalized.
**What changed:**
* **Clinician attestation waives the diagnosis requirement.** When a clinician records a "no diagnosis applicable" attestation in the note review, the finalize gate no longer requires at least one approved diagnosis. All other required-field and ownership checks remain enforced.
* **Exact attestation key required.** Only the specific attestation value is accepted. Unrecognized or misspelled attestation entries do not bypass the diagnosis gate, preserving the clinical safety boundary.
* **All other finalize checks unchanged.** The attestation waives only the approved-diagnosis count requirement. Required fields, visibility rules, and other validation continue to apply as before.
**What you need to do:**
* **No action required for most integrations.** If your integration already submits at least one approved diagnosis before finalizing, behavior is unchanged.
* **Use the attestation for legitimate zero-diagnosis notes.** If your workflow produces notes where no diagnosis is applicable, include the attestation in the note review acknowledgments to allow finalization without adding an unnecessary diagnosis.
Scribe: Session Codes Status Reflects Generation Outcome (July 2026)
#### Session Codes Status Reflects Generation Outcome
The session detail and session list endpoints now derive the `codes_status` field from the outcome of the codes generation step rather than from the presence of individual code suggestion records.
**What changed:**
* **Codes status reflects generation outcome.** The `codes_status` field on session responses now reports `available` when codes generation succeeded, `failed` when it failed, and `pending` while it is still running or has not started. Previously, `codes_status` was based on whether any code suggestion records existed, which meant a successful generation that produced zero suggestions (a valid "no groundable diagnosis" result) would remain stuck on `pending` indefinitely.
* **Zero-suggestion results no longer block finalization.** Sessions where codes generation succeeded but found no applicable codes now correctly report `codes_status: available`, allowing downstream workflows - including session finalization - to proceed without manual intervention.
**What you need to do:**
* **No action required for most integrations.** The `codes_status` field continues to return the same three values (`pending`, `available`, `failed`). Integrations that poll or display this field will now see accurate status for sessions with zero code suggestions.
* **Review any logic that treats `pending` as "no codes yet."** If your integration distinguishes between "codes generation is still running" and "codes generation completed with no results," you can now rely on `codes_status: available` to mean generation finished, even when the codes list is empty.
Scribe: PUT Allowed for Structured-Note Autosave (July 2026)
#### PUT Allowed for Structured-Note Autosave
The Scribe API now accepts PUT requests from browser-based clients, enabling the SDK full-document autosave flow for structured notes.
**What changed:**
* **PUT method permitted in cross-origin requests.** Browser preflight checks for the structured-note autosave endpoint now succeed. Previously, the autosave PUT was rejected at the preflight stage, causing a cross-origin error when editing structured-note fields from the browser.
**What you need to do:**
* **No action required.** If your integration uses the SDK `putNote` call or the structured-note autosave, PUT requests now pass preflight validation automatically. No request format or endpoint changes are needed.
Scribe: MRN Prefix Removed from Seeded Appointment Charts (July 2026)
#### MRN Prefix Removed from Seeded Appointment Charts
Seeded appointment patient charts no longer include the "MRN-" prefix on medical record numbers. The identifiers are now bare numeric strings.
**What changed:**
* **MRN values are now bare numbers.** Previously, seeded patient chart medical record numbers were formatted as `MRN-100238`. They are now returned as `100238`. This applies to all seeded appointment charts.
**What you need to do:**
* **Update any hardcoded MRN expectations.** If your integration or test fixtures match seeded chart MRN values with the `MRN-` prefix, remove the prefix from those assertions.
* **No API shape changes.** The field type and response structure are unchanged; only the value format differs.
Scribe: Seed Appointments Use Eastern Time Wall-Clock Scheduling (July 2026)
#### Seed Appointments Use Eastern Time Wall-Clock Scheduling
Seed appointment slots now use Eastern Time wall-clock hours and span 7 AM to 11 PM ET, replacing the previous UTC-based slot range. Slot times are DST-correct - each slot keeps its ET wall-clock hour across daylight saving transitions.
**What changed:**
* **Slot range expanded and ET-anchored.** Seed appointment slots now span 7:00 AM to 11:00 PM Eastern Time (8 slots per day) instead of the previous 8:00 AM to 4:00 PM UTC range. Each slot is built at its ET wall-clock time and converted to UTC for the response, so the ET hour is stable across EDT and EST.
* **DST-correct start and end times.** Appointment `start` and `end` timestamps in API responses remain UTC-aware, but the underlying wall-clock hour no longer drifts by one hour when daylight saving time changes. A slot scheduled at 9:00 AM ET appears at 9:00 AM ET year-round; only the UTC offset shifts.
* **Stable appointment identifiers across DST.** Appointment IDs encode the ET wall-clock date and hour rather than the UTC instant, so a given slot keeps the same ID regardless of whether the date falls in EDT or EST. Sessions linked by appointment ID are unaffected by seasonal clock changes.
**What you need to do:**
* **No action required for most integrations.** API response timestamps remain UTC-aware and the response shape is unchanged. If your integration filters or displays seed appointments by time of day, note the wider slot range (7 AM - 11 PM ET vs. the previous 8 AM - 4 PM UTC).
* **Update any hardcoded slot-time expectations.** If you have test fixtures or assertions that depend on the specific UTC hours of seed appointment slots, update them to reflect the new ET-anchored schedule.
Scribe: Structured Finalization Gates (July 2026)
#### Structured Finalization Gates
The note finalization endpoint now validates the complete structured document against its pinned template before allowing finalize, replacing the previous minimal confirmation-only gate.
**What changed:**
* **Template-aware required-field validation at finalize.** Finalizing a structured note now checks that every currently required and visible field carries a value. Fields that are conditionally visible or conditionally required are evaluated against the current document state - a hidden field is never gated as missing, and a field that becomes required based on another answer is enforced only when its condition is met.
* **Diagnosis requirement enforced.** Templates that include a diagnosis field now require at least one provider-approved diagnosis before finalize. The approval count is resolved from the canonical diagnosis collection at finalize time, not from the structured document payload.
* **Section confirmation enforced.** Every template section marked as needing confirmation must be confirmed before finalize. The response identifies each unconfirmed section.
* **Overall confirmation enforced.** The provider must confirm the structured fields before finalize. This gate replaces the previous minimal check with a validation that runs after all field and section gates.
* **Structural document validation re-run.** Finalize re-runs the structural document validation (unknown fields, prohibited fields, type mismatches) so that a document that drifted after the last save cannot bypass the gate.
* **Exact field paths in error responses.** Every finalize validation error returns an exact structured field path so the client can focus the offending field without client-side path mapping.
* **Fail-closed on invalid documents.** A stored document that cannot be parsed or that references an unsupported template produces a finalize failure rather than an unhandled error. The distinction between schema drift and a not-yet-generated note is logged for operators but surfaces the same structured error to clients.
**What you need to do:**
* **No action required for compliant workflows.** If your integration already fills all required fields, confirms sections, approves at least one diagnosis, and confirms the structured fields before calling finalize, behavior is unchanged.
* **Handle new validation errors on finalize.** The finalize endpoint may now return additional validation errors with exact field paths. Update your error handling to display or act on these paths if you present finalize failures to users.
* **Diagnosis approval is now required.** Ensure at least one diagnosis is approved through the code decision endpoint before attempting to finalize a note that includes a diagnosis field.
Platform: Zoom Session Finalization for Silent Meetings (July 2026)
#### Zoom Session Finalization for Silent Meetings
Zoom sessions that end without any speech are now finalized correctly instead of remaining stuck in an in-progress state.
**What changed:**
* **Silent Zoom sessions finalize automatically.** Previously, a Zoom meeting that ended with no spoken content could remain in an in-progress state indefinitely because the transcript snapshot was never written. The platform now always writes a transcript snapshot at session end - even when the session contains zero speech segments - so the finalization pipeline can seal the session with an empty transcript.
* **Backward-compatible handling for in-flight sessions.** Sessions that were already drained before this change and are missing their snapshot are handled gracefully. When the session metadata confirms zero speech segments, the platform synthesizes the expected empty transcript and completes finalization rather than leaving the session stranded.
**What you need to do:**
* **No action required.** This is a reliability improvement. Silent Zoom sessions that previously required manual intervention now finalize automatically. The API response shape and session lifecycle are unchanged.
Scribe: Improved Transcript Retrieval Reliability (July 2026)
#### Improved Transcript Retrieval Reliability
Transcript retrieval now reads the stored object to completion and logs structured diagnostics when a read fails, replacing previously silent error paths that returned generic 503 responses without context.
**What changed:**
* **Full object reads.** Transcript retrieval now reads the entire stored object rather than requesting a fixed byte count. The previous behavior could silently truncate multi-segment responses, causing downstream parse failures that surfaced as unexplained temporary-unavailability errors.
* **Incomplete payload handling.** When a stored transcript object is genuinely truncated or the connection drops mid-transfer, the platform now catches the incomplete-read condition explicitly and returns a clean temporary-unavailability response instead of an unhandled server error.
* **Structured failure logging.** Each transcript read failure - oversized object, read timeout, incomplete payload, parse error, or partial-transcript parse error - now emits a structured log entry with the failure reason and non-sensitive request identifiers. Object contents are never logged. These diagnostics help operators identify recurring retrieval issues without exposing protected health information.
**What you need to do:**
* **No action required.** These are reliability and observability improvements. The API response shape and status codes are unchanged. Callers that retry on temporary-unavailability responses benefit automatically from the reduced incidence of silent truncation failures.
Scribe: Mid-Session Auto-Check No-Op Guard (July 2026)
#### Mid-Session Auto-Check No-Op Guard
The mid-session checklist auto-check endpoint now detects unchanged inputs and short-circuits without repeating the evaluation, keeping redundant re-checks cheap.
**What changed:**
* **Input-based no-op detection.** The auto-check handler computes a hash of its evaluation input - the current transcript snapshot and the generated checklist items. When the input has not changed since the last evaluation for that session, the endpoint returns the already-persisted auto-check state without running a new evaluation or writing new data.
* **First and changed inputs evaluated normally.** When no previous hash exists (first auto-check) or the input has changed (new transcript content or updated checklist), the full evaluation runs as before and the new hash is persisted atomically with the matched-item results.
* **Persisted state reconstruction on no-op.** A no-op response reconstructs per-item match verdicts from the stored checklist state, returning the same response shape as a full evaluation. Evidence fields are omitted in the no-op path because they are not persisted.
* **Session response includes hash field.** The session detail response now includes an additional internal field for the auto-check input hash. This field is informational and not intended for client use.
**What you need to do:**
* **No action required.** The no-op guard is transparent to callers. The response shape is unchanged. Clients that fire auto-checks on a timer or on reconnect benefit automatically from reduced evaluation latency on unchanged inputs.
Scribe: Server-Authoritative Checklist Item Category (July 2026)
#### Server-Authoritative Checklist Item Category
Checklist items now carry a server-authoritative `category` field that identifies the presentational section each item belongs to. Previously, section grouping was a client-side concern; it is now part of the platform's checklist data model.
**What changed:**
* **`category` field on checklist items.** Every checklist item returned by the GET checklist endpoint now includes a `category` string identifying its section (for example, "Safety & Setup", "Clinical Check-In", "Measurement-Informed Care"). The field is populated from the platform's checklist template.
* **Backfill on read for existing sessions.** Sessions created before this change do not have a stored category. When those checklists are read, the platform backfills the category from the current template. Items whose identifiers no longer appear in the template receive a fallback category of "Other" rather than causing an error.
* **`category` field on auto-check verdicts.** Each match object in the auto-check response now includes the same `category` field, so consumers can group verdicts by section without a separate template lookup.
* **Seeded checklists include category.** New sessions seed checklist items with the category already stored, so no backfill is needed on subsequent reads.
**What you need to do:**
* **No action required.** The category field is additive. Existing integrations that do not read the field continue to work unchanged.
* **Use the `category` field for section grouping.** If your integration renders checklist items grouped by section, you can now use the server-provided `category` instead of maintaining a client-side mapping.
Scribe: Faster Mid-Session Transcript Snapshots (July 2026)
#### Faster Mid-Session Transcript Snapshots
The rolling transcript snapshot that the scribe auto-check reads during an active visit is now refreshed more frequently, keeping the visible transcript closer to real-time speech.
**What changed:**
* **Snapshot refresh cadence reduced.** The default interval for writing the rolling transcript snapshot has been lowered from 30 seconds to 5 seconds. This keeps the latest transcript within one client polling cycle of newly finalized speech.
* **No-change writes skipped.** When no new finalized segments have arrived since the last snapshot, the write is skipped, so quiet periods do not produce redundant updates.
* **Environment override preserved.** Deployments that set a custom snapshot interval through the environment variable continue to use that value. The change only affects the default when no override is set.
**What you need to do:**
* **No action required.** The faster refresh applies automatically. If you previously set a custom snapshot interval, your override is still honored.
Scribe: Structured Grounding for Dependent Generations and Section Regeneration (July 2026)
#### Structured Grounding for Dependent Generations and Section Regeneration
Summary, codes, actions, and Ask grounding now derive from a deterministic serialization of the structured note document rather than the deprecated Markdown body. Section regeneration produces a validated structured patch merged into the base document. Generation identities for dependent artifacts hash the structured document content and serializer version, so unchanged documents collapse to the same cached result.
**What changed:**
* **Deterministic structured-to-text serialization.** A versioned serializer walks the note template's sections and fields in schema order and renders each stored value to grounded plain text. This serialization is the single grounding source for summary, codes, actions, and Ask - it replaces the Markdown body that the structured workflow no longer produces. The serializer version is folded into the generation identity so a serializer change invalidates cached artifacts.
* **Dependent generation identity uses structured document.** The generation identity hash for summary, codes, and actions now includes the structured document's clinical field values, pinned template identifier, template version, and serializer version. Attestation and review state - such as section confirmations - are excluded from the identity so that confirming a section does not trigger redundant re-generation. Both the automatic post-note enqueue and explicit generation requests use the same identity, so an unchanged document collapses to a single job.
* **Structured section regeneration.** Section regeneration now operates on the structured document: only the target section's generation-eligible fields are regenerated into a validated patch, which is merged over the base document. Non-target sections, non-generated fields, and attestation-owned fields are carried forward verbatim. The changed section's review confirmation is reset because the clinical content changed. One bounded repair attempt is made if the initial generation fails template validation. There is no fallback to Markdown output.
* **Route-level section validation.** The section regeneration endpoint now validates that the requested section identifier exists in the note's pinned template before enqueuing the job. An unknown section returns a validation error.
* **Finalize gate no longer requires non-empty body.** The finalize endpoint validates the structured document directly. The previous requirement for a non-empty Markdown body has been removed because structured notes store an empty body by design.
* **Prompt version bump.** Summary, codes, and actions prompt versions have been incremented. Any pre-existing cached generation from the previous Markdown-grounded versions is invalidated, ensuring a fresh generation uses the new structured grounding.
**What you need to do:**
* **No action required for most integrations.** The grounding change is transparent to API consumers. Generation responses retain the same shape.
* **Section regeneration callers should use valid template section identifiers.** Requests with a section identifier that does not exist in the note's template now receive a validation error instead of proceeding to generation.
* **Finalize callers that checked for a non-empty body can remove that check.** The platform no longer enforces the body requirement at finalize; the structured document is the authoritative clinical content.
Scribe: Schema-Constrained Structured Note Generation (July 2026)
#### Schema-Constrained Structured Note Generation
Note generation now produces a validated structured document constrained to the session's pinned note template, replacing the previous Markdown body output. Generation failures are typed and never fall back to unstructured output.
**What changed:**
* **Structured document output.** Note generation now emits a validated structured document instead of a Markdown body. Each generated field value includes provenance and an optional grounding rationale. The generated document is pinned to the exact template version registered for the session's visit type.
* **Template-constrained generation.** The generation model receives only the template's generation-eligible fields - document-owned, transcript-sourced fields that the model may populate. Diagnosis fields, computed values, session and patient metadata, and attestation fields are excluded from generation and cannot appear in the output.
* **Field-level validation with bounded repair.** The generated document is validated against the pinned template's field types, enum constraints, and length limits. If validation fails, one automatic repair attempt runs with the specific problems fed back to the model. If the repair also fails, generation fails closed with a typed error.
* **Unsupported templates fail closed.** A session pinned to a legacy or unrecognized note template fails generation with a typed `unsupported_note_template` error. Generation never falls back to unstructured output for an unsupported template.
* **Typed generation failure codes.** Two new typed failure codes are recorded when generation cannot produce a valid document:
* `unsupported_note_template` - the session's template is not a supported structured template.
* `structured_generation_invalid` - the generated document failed template validation even after the bounded repair attempt.
* **Provider JSON mode.** When the generation provider supports a JSON output mode, it is enabled to improve the reliability of structured output parsing.
* **Generation version updated.** The generation prompt version has been updated, so previously cached generation results are not reused across the structured cutover.
* **Body field no longer generated.** The legacy body field is written empty for newly generated notes. Downstream artifacts that previously grounded on the body degrade to transcript-only grounding until they are updated to read from the structured document.
**What you need to do:**
* **Read generated notes from the structured field.** The body field is empty for newly generated structured notes. Update any integration that reads generated note content to use the structured document instead.
* **Handle new failure codes.** If your integration monitors generation status, handle the `unsupported_note_template` and `structured_generation_invalid` failure codes.
* **Ensure sessions use a supported visit type.** Sessions must be pinned to a recognized visit type that resolves to a supported structured template. Sessions with legacy or unrecognized templates will fail generation.
Scribe: Typed Structured-Note Envelope and Body Deprecation (July 2026)
#### Typed Structured-Note Envelope and Body Deprecation
The note autosave endpoint now accepts and validates a typed structured-note envelope, replacing the previous untyped payload. The legacy `body` field is deprecated and rejected on write.
**What changed:**
* **Typed structured-note envelope.** The note update endpoint now accepts a structured envelope containing the schema version, template identifier, template version, per-field values with provenance and optional rationale, and a provider review state. The envelope is validated as a complete document against the pinned template before the write is applied. Unknown envelope keys are rejected at parse.
* **Complete-document replacement.** Each write is a full-document replacement, not a partial patch. The client resends every field value on each save, changing only what it means to change.
* **Template-pinned writes.** The write is pinned to the envelope's template identifier. A structured document cannot overwrite a note pinned to a different template. Attempting to do so returns a 422 error.
* **Per-field validation.** Every field in the envelope is checked against the pinned template: the field must exist as a top-level template field, must be document-owned or attestation-owned (read-only projections are rejected), and its value must satisfy the field's type, enum, and length rules. Confirmed sections in the review state must name real template sections. Validation problems are returned as per-field details in the 422 response.
* **`body` field deprecated on write.** Sending a `body` value in the update request now returns a 422 `deprecated_field` error. The field is no longer writable through the note autosave endpoint.
* **`body` field deprecated on read.** For structured notes, the `body` field in note responses is now null. Legacy body-only notes continue to return their body during the deprecation window. The field remains present in the response schema but is marked deprecated.
* **New 422 error codes.** Three typed 422 error codes are introduced for note writes: `deprecated_field` (body write attempted), `unsupported_note_template` (unknown or mismatched template), and `validation_error` (structured document failed template validation, with per-field details).
**What you need to do:**
* **Send the structured envelope instead of body.** Update note-writing integrations to send the `structured` envelope with `schema_version`, `template_id`, `template_version`, `values`, and `review`. Do not send `body`.
* **Send complete documents on each write.** Include every field value in each update, not just changed fields.
* **Handle new 422 error codes.** Clients should handle `deprecated_field`, `unsupported_note_template`, and `validation_error` responses, including per-field error details.
* **Stop reading `body` for structured notes.** For structured notes, `body` is null. Read note content from the `structured` field instead.
Scribe: All-Session AMD Template Pinning on Create and Update (July 2026)
#### All-Session AMD Template Pinning on Create and Update
Every new session - in-person and Zoom - is now pinned to a supported AMD note template at creation time. The legacy fallback to a generic "medical" note type has been removed.
**What changed:**
* **Template required at session creation.** Both in-person (`POST /sessions`) and Zoom (`POST /zoom/sessions`) session creation now require a canonical `visit_type` that resolves to a supported AMD note template. Sessions can no longer be created without a recognized visit type. An optional `note_template` field, if provided, must match the template the visit type resolves to.
* **Template enforced on session update.** When a `PATCH` to a session changes `visit_type` or `note_template`, the resulting pair is re-validated against the same rules as creation. A session cannot be updated to remove its template or set an unsupported one.
* **No medical/legacy fallback.** The automatic fallback that previously substituted a generic "medical" note type when no template was present has been removed. A note generation job that lacks a note type now fails with an explicit error rather than silently generating a generic note.
* **Zoom session parity.** Zoom sessions now follow the same template-pinning path as in-person sessions, closing a gap where a Zoom session created without a template could later default to a generic note type during generation.
* **New 422 error codes.** Two new error codes may be returned on session create or update:
* `note_template_required` - no `visit_type` was supplied to resolve a template.
* `unsupported_note_template` - the `visit_type` does not map to a supported template, or the provided `note_template` does not match the one the `visit_type` resolves to.
**What you need to do:**
* **Always send a recognized `visit_type` when creating sessions.** Both in-person and Zoom session creation now require it. If your integration previously omitted `visit_type` or `note_template`, update it to send one of the four canonical visit types.
* **Handle `note_template_required` and `unsupported_note_template` 422 responses.** These are returned when the visit type is missing, unrecognized, or mismatched with a provided template.
* **Remove any client-side fallback to a generic note type.** The platform no longer accepts sessions without a supported template, so client-side defaults are unnecessary.
Scribe: Authoritative AMD Note Template Registry (July 2026)
#### Authoritative AMD Note Template Registry
The Scribe service now includes an authoritative server-side registry for the four behavioral-health AMD note templates used in the structured post-visit note workflow.
**What changed:**
* **Four AMD templates registered.** The platform now owns the canonical definitions for psych intake, psych progress, therapy intake, and therapy progress note templates. Each template is pinned to a specific version, ensuring that a finalized document is always reproducible against the exact schema that produced it.
* **Visit-type to template mapping.** The four canonical visit types - psych-intake, psych-follow-up, therapy-intake, and therapy-follow-up - each resolve to exactly one AMD template. An unrecognized or absent visit type fails closed with a typed error rather than falling back to a legacy template.
* **Field ownership classification.** Every field in each template is classified by ownership: document-owned fields (editable, generation-eligible), attestation fields (clinician-owned confirmations), diagnosis fields (edited through diagnosis mutations), session and patient metadata (read-only projections), and computed fields (derived from app-known facts). Only document-owned and attestation fields are written through note autosave.
* **Generation eligibility.** Each field carries a generation-eligibility flag identifying the subset of document-owned, transcript-sourced, value-bearing fields that the note-generation model may populate. Diagnosis fields, computed facts, and display-only fields are excluded.
* **Version pinning and fail-closed resolution.** Template lookups require an exact version match. A request for an unknown template, an unknown version, or an unknown field returns a typed error - the registry never silently upgrades or downgrades a client to a different schema.
* **Max-length validation bounds.** Free-text fields carry server-enforced maximum length limits that the reference schema does not define, providing an additional validation layer for narrative, text, and score fields.
**What you need to do:**
* **No action required.** This is a foundational registry used by upcoming structured validation, note generation, finalization, and web rendering phases. No existing endpoints or workflows are changed by this addition.
Scribe: Cancelled Sessions Hidden from Session and Appointment Lists (July 2026)
#### Cancelled Sessions Hidden from Session and Appointment Lists
The Scribe service now excludes cancelled sessions from list endpoints, so cancelled sessions no longer appear in session lists or as the linked session on an appointment.
**What changed:**
* **Session list excludes cancelled sessions.** The endpoint that returns sessions for a provider no longer includes sessions with a cancelled status. Previously, cancelled sessions appeared alongside active and completed sessions in the list.
* **Appointment session linkage excludes cancelled sessions.** When the appointments endpoint resolves the current session for each appointment, cancelled sessions are no longer considered. If an appointment's only session(s) are cancelled, the appointment renders with no linked session - the same state as an appointment where a session has never been started. Previously, a cancelled session could appear as the linked session on an appointment.
* **Appointments with only cancelled sessions are startable.** Because cancelled sessions are excluded from linkage, an appointment whose sessions have all been cancelled now appears ready to start a new session, matching the behavior of an appointment that has never had a session.
**What you need to do:**
* **No action required.** This is a data-quality improvement. Integrations that consume session lists or appointment responses will no longer encounter cancelled sessions in those views. If your workflow depends on retrieving cancelled sessions, note that they are no longer returned by these list endpoints.
Scribe: Patient Chart Fields on Appointments (July 2026)
#### Patient Chart Fields on Appointments
The Scribe appointments endpoint now returns patient chart context alongside each appointment, giving the pre-visit UI access to clinical reference data without a separate lookup.
**What changed:**
* **Date of birth.** Each appointment now includes a `date_of_birth` field (date or null) representing the patient's date of birth from their chart record.
* **Medical record number.** Each appointment now includes an `mrn` field (string or null) with the patient's medical record number.
* **Active conditions.** Each appointment now includes an `active_conditions` field (array of strings) listing the patient's current active conditions.
* **Medications to review.** Each appointment now includes a `medications_to_review` field (array of strings) listing medications associated with the patient.
* **Graceful absence.** All four fields are optional. When chart data is not available for an appointment, `date_of_birth` and `mrn` are null and the list fields are empty. The UI degrades gracefully rather than rendering blank cells.
**What you need to do:**
* **No action required.** The new fields are additive. Existing integrations that consume appointment responses will continue to work without changes. To use the new chart fields, read them from the appointment objects in the list response.
Channel Manager: Automatic Retry for Telephony Provisioning Status Callbacks (July 2026)
#### Automatic Retry for Telephony Provisioning Status Callbacks
Telephony provisioning status callbacks now retry automatically when the callback arrives before the platform has finished persisting the associated provisioning record.
**What changed:**
* **Automatic redelivery on race conditions.** When a telephony provider sends a provisioning status callback before the platform has committed the matching record, the webhook now returns an error status that triggers the provider to redeliver the callback. Previously, the callback was silently accepted and the status update was lost, requiring manual resolution.
* **Up to five retries.** The provider retries delivery up to five times on any error response, giving the platform time to finish committing the record. Once the record is available, the callback is processed normally.
* **Applies to all provisioning bundles.** The retry behavior covers trust profile, regulatory bundle, messaging profile, caller-ID display, and call authentication provisioning callbacks.
**What you need to do:**
* **No action required.** This is a reliability improvement to telephony provisioning. Provisioning status updates that previously could be lost due to timing are now delivered reliably.
Scribe: Server-Side Checklist Seeding at Session Creation (July 2026)
#### Server-Side Checklist Seeding at Session Creation
The Scribe service now instantiates a session's checklist from a server-side template registry when the session is created, rather than requiring a transcript and a separate generation request.
**What changed:**
* **Checklist seeded at session creation.** When a Scribe session is created, the platform expands the session's visit type into an initial checklist with all items in the open state. The checklist is available immediately - including before any transcript exists - so manual toggle and live auto-check workflows work from the first moment of the session.
* **Visit type controls the item set.** Intake visit types receive the full checklist template. Follow-up visit types receive a smaller subset that excludes intake-specific items. This mirrors the filtering logic previously handled by the web client, now applied server-side as the authoritative source of checklist item identity.
* **Visit type changes re-seed the checklist.** When a session's visit type is updated before the session reaches a terminal state, the checklist is re-seeded to match the new visit type's item set. Items that appear in both the old and new sets retain any manual or auto-check state. Attempting to re-seed a terminal session returns a 409 conflict.
* **Checklist generation endpoint removed.** The `POST /sessions/{session_id}/checklist` generation endpoint has been removed. Checklists are now created automatically at session creation and no longer require a transcript-driven generation request. The `GET` endpoint for reading checklist state and the `PATCH` endpoint for toggling items continue to work as before.
* **No changes to checklist read or toggle contracts.** The checklist read endpoint returns the same response shape. The item toggle endpoint accepts the same request shape. Integrations that read or toggle checklist items require no changes.
**What you need to do:**
* **Remove calls to the checklist generation endpoint.** If your integration previously called `POST /sessions/{session_id}/checklist` to generate a checklist, remove that call. Checklists are now created automatically when the session is created.
* **No other changes required.** Reading and toggling checklist items works the same way. The checklist is available earlier in the session lifecycle than before.
Scribe: Resilient Transcript Retrieval Under Degraded Storage Conditions (July 2026)
#### Resilient Transcript Retrieval Under Degraded Storage Conditions
The Scribe service now automatically recovers transcript reads that fail due to a degraded internal storage client, reducing transient 503 errors for transcript retrieval.
**What changed:**
* **Automatic single-attempt recovery for transcript reads.** When a transcript artifact is confirmed available but the initial storage read returns a transient not-found error, the platform now retries the read once using a fresh internal connection before returning an error. This targets a diagnosed condition where long-lived connection pools can produce spurious not-found responses for objects that exist.
* **Recovery is scoped and bounded.** The retry applies only to canonical transcript reads where the artifact record confirms the object should be available. It is a single additional attempt, not a general-purpose retry loop.
* **Structured logging for recovery events.** When a transcript is successfully recovered through the fresh read, the platform emits a structured log entry with workspace, session, and correlation identifiers. This makes the rate of degraded-client events observable in monitoring alongside the existing warning logged when both reads fail.
* **No changes to the Scribe API contract.** The transcript endpoint continues to return the same response shapes. Successful recoveries return the transcript normally. When both the initial and recovery reads fail, the endpoint returns HTTP 503 as before.
**What you need to do:**
* **No action required.** Integrations that consume transcript endpoints are unaffected. Teams that monitor Scribe logs may see new recovery log entries for reads that previously would have returned 503.
Scribe: Improved Observability for Transcript Retrieval Failures (July 2026)
#### Improved Observability for Transcript Retrieval Failures
The Scribe service now logs structured warnings when a transcript retrieval returns a transient 503, improving visibility into two failure scenarios that were previously silent.
**What changed:**
* **Object-missing failures now logged.** When a transcript artifact's storage reference exists but the underlying object is not yet available, the platform now emits a structured warning with the workspace, session, and correlation identifiers before returning 503. Previously this path returned 503 with no log entry, making transient retrieval failures invisible in monitoring.
* **Malformed payload failures now logged.** When a transcript payload is present but cannot be parsed into the expected response shape, the platform now emits a structured warning with the workspace, session, error type, and a safe error summary. For validation errors, the logged detail includes only field location and error type - no patient or transcript content is included.
* **No changes to the Scribe API contract.** Both failure scenarios continue to return HTTP 503 with the same response body. This is an observability improvement only.
**What you need to do:**
* **No action required.** Integrations that consume transcript endpoints are unaffected. Teams that monitor Scribe error rates may now see structured log entries for transient 503 responses that were previously unlogged.
Scribe: Empty Extraction Results Treated as Valid (July 2026)
#### Empty Extraction Results Treated as Valid
The Scribe service now treats an empty extraction for diagnosis codes and action items as a valid, succeeded result rather than a generation failure.
**What changed:**
* **Empty codes and actions are valid.** When a visit transcript yields no groundable diagnosis codes or action items, the platform now persists the result as a succeeded generation with an empty list. Previously, an empty extraction was treated as a failure, which could cause the session to surface an error even though the model correctly determined there was nothing to extract.
* **Artifact status reflects success.** The codes and actions artifact endpoints return a ready status with an empty items list for these generations, rather than returning an unavailable or error state.
* **No changes to the Scribe API contract.** Request and response shapes for all Scribe endpoints are unchanged. Callers that already handle an empty items list require no changes.
**What you need to do:**
* **No action required.** Integrations that consume codes or actions artifacts should already handle an empty list. Sessions that previously failed during extraction for visits with no groundable items will now succeed automatically.
Scribe: Improved Diagnostic Detail for Structured Generation Failures (July 2026)
#### Improved Diagnostic Detail for Structured Generation Failures
When a structured generation stage (codes, actions, or checklist) fails because the model returns unparseable output, the platform now surfaces a more specific failure description in operational logs. The diagnostic identifies which artifact kind failed and includes the response length and first character, without logging any clinical content.
**What changed:**
* **Failure variant detail.** Generation failures for codes, actions, and checklist stages now carry a diagnostic string that distinguishes common failure shapes - such as a truncated response, an unexpected array wrapper, a malformed object, or a prose refusal - without exposing any patient or transcript data.
* **Operational log visibility.** The failure detail is included in the structured log entry for the failed generation job, making it easier to triage model output issues in monitoring dashboards.
* **No changes to the Scribe API contract.** Request and response shapes for all Scribe endpoints are unchanged. Error responses returned to callers are unaffected. This is an internal observability improvement.
**What you need to do:**
* **No action required.** This change improves internal failure triage. There are no changes to the API contract, integration behavior, or error responses.
Scribe: Robust JSON Parsing for Structured Generation Stages (July 2026)
#### Robust JSON Parsing for Structured Generation Stages
The Scribe service now handles structured JSON responses from clinical models more reliably when the model wraps its output in Markdown code fences.
**What changed:**
* **Code-fence stripping for structured stages.** The structured generation stages that produce codes, actions, and checklist results now strip Markdown code fences (e.g., ` ```json ... ``` `) from model output before parsing. Previously, a model response wrapped in a code fence was rejected as invalid JSON, even though the content inside the fence was correct.
* **Free-text stages unaffected.** Note and summary generation stages do not parse JSON and are not affected by this change.
* **No changes to the Scribe API contract.** Request and response shapes for all Scribe endpoints are unchanged. This is a resilience improvement to internal model output handling.
**What you need to do:**
* **No action required.** Sessions that previously failed during code, action, or checklist generation due to model-wrapped JSON responses will now succeed automatically. There are no changes to the API contract or integration behavior.
Scribe: Session-Owned Note Generation Fields (July 2026)
#### Session-Owned Note Generation Fields
Scribe sessions now carry optional patient identity, visit context, and note template fields directly on the session. When set, these fields drive the generated note content and format, removing the need to supply them on every note generation request.
**What changed:**
* **Patient name fields on sessions.** Sessions accept optional `first_name` and `last_name` fields at creation and update. When present, the generated note identifies the patient by name.
* **Visit type on sessions.** Sessions accept an optional `visit_type` field. When present, the generated note includes the visit type as encounter context.
* **Note template on sessions.** Sessions accept an optional `note_template` field that specifies the note format (e.g., `soap`, `medical`, `birp`, or any of the supported template identifiers). When set, the session's template takes priority over the per-request `note_type` on both explicit and auto-enqueued note generation.
* **Auto-enqueued notes use session fields.** When a session transitions to the review stage and note generation is auto-enqueued, the job now uses the session-owned fields (name, visit type, template) rather than bare defaults. An explicit note generation request for the same session with matching default parameters still collapses onto the auto-enqueued job.
* **Idempotency includes new fields.** The note generation idempotency check now incorporates patient name, visit type, and note template. Changing any of these fields and re-requesting generation produces a new note rather than returning the previous result.
* **Session response includes new fields.** The session object returned by create, update, get, and list endpoints now includes `first_name`, `last_name`, `visit_type`, and `note_template` (all nullable).
* **Update semantics.** On session update, including a field in the request body writes the value (a `null` clears it); omitting the field leaves the existing value unchanged.
* **Idempotent create fingerprint expanded.** When using `external_id` for idempotent session creation, the fingerprint check now includes the note generation fields. Reusing an `external_id` with different note generation field values returns a conflict error, matching the existing behavior for mode, appointment linkage, and metadata.
**What you need to do:**
* **No action required for existing integrations.** All new fields are optional with `null` defaults. Existing session creation and note generation calls continue to work without changes.
* **To use session-owned fields,** include `first_name`, `last_name`, `visit_type`, and/or `note_template` in the create or update session request body. The generated note will reflect these values automatically.
Scribe: Zoom Meeting Bot Shutdown Drain Reliability (July 2026)
#### Zoom Meeting Bot Shutdown Drain Reliability
The Zoom meeting bot now completes its final transcript flush more reliably when a session ends, reducing the likelihood that trailing speech segments or the completion manifest are lost during teardown.
**What changed:**
* **Extended teardown budget.** The session pod's shutdown window has been increased to give the transcription relay enough time to finish draining in-flight audio, write the final transcript snapshot, and write the completion manifest before the process is terminated. The previous window was too narrow and could lose the race under real-world latency.
* **Bounded finalize wait.** On shutdown, the relay now waits a bounded amount of time for active audio connections to close cleanly. If a peer never closes its connection within that window, the relay force-cancels the handler and proceeds to the drain, ensuring the final snapshot and manifest are still written. Previously, a stuck peer could starve the drain indefinitely.
* **Drain timeout derived from shutdown budget.** The relay's finalize timeout is derived from the overall shutdown budget rather than set independently, so the flush margin cannot silently erode through configuration drift.
* **Bounded storage client timeouts.** The storage client used for transcript writes now enforces bounded connect, read, and retry limits. A slow or unavailable storage backend exhausts its budget quickly and falls through to the existing recovery backstop, rather than hanging for the duration of the shutdown window.
* **Forced-cancellation observability.** When a connection handler is force-cancelled during shutdown, the relay emits a structured log event (with operational identifiers only - never transcript content) so the pathological path is observable in monitoring.
**What you need to do:**
* **No action required.** This is an automatic reliability improvement to session teardown for Zoom sessions. There are no changes to the Scribe API contract, session creation, or transcript retrieval endpoints. Sessions that previously lost trailing speech segments due to a narrow teardown window will now retain them. The existing background recovery mechanism remains the backstop for the rare case where the drain still cannot complete.
Scribe: Zoom End-of-Session Transcript Completeness and Graceful Degradation (July 2026)
#### Zoom End-of-Session Transcript Completeness and Graceful Degradation
The Zoom session finalize path now waits for the bot's drain to fully complete before sealing the canonical transcript, preventing loss of speech captured in the final moments of a meeting. When the bot exits before completing its drain, the platform now degrades gracefully by sealing the best-available transcript immediately rather than leaving the session stranded for the background recovery mechanism.
**What changed:**
* **Drain-completion gating.** When a Zoom session ends, the platform now waits for a completion signal from the transcription bot before promoting the transcript to its canonical form. Previously, the first available rolling transcript snapshot was promoted immediately, which could be missing segments spoken just before the meeting ended - the bot had not yet finished flushing its final output.
* **Segment-count verification.** The promoted transcript is verified to contain at least as many segments as the bot reports having finalized. If the snapshot has not yet caught up, the platform retries within a bounded window rather than sealing an incomplete transcript.
* **Graceful degradation when the bot exits early.** If the bounded wait for the bot's completion signal is exhausted - for example, the bot was terminated before it could flush its final output - the platform now promotes the best-available transcript snapshot immediately and transitions the session to the review stage. Previously, these sessions remained in progress until the background recovery mechanism processed them (up to two hours later). A possibly-truncated trailing turn sealed promptly is preferred over no canonical transcript for an extended period.
* **Degraded seal is observable.** When a transcript is sealed through the degraded path, the platform records a durable audit event identifying the session and quantifying the gap between the expected and actual segment counts. Downstream consumers can use this marker to identify transcripts that may have a truncated trailing turn.
* **Transient infrastructure errors absorbed.** Temporary read failures during the drain window are retried within the same bounded loop instead of immediately abandoning the session. A persistent failure during the degraded seal attempt leaves the session for the existing background recovery mechanism.
* **Recovery path preserved.** Sessions where not even a rolling snapshot exists - for example, the bot never produced any output - continue to be left for the existing background recovery mechanism.
* **Note generation auto-enqueued on degraded seal.** When a degraded seal successfully transitions the session to the review stage, note generation is auto-enqueued using the same best-effort path as a full seal. The background recovery mechanism backstops a failed enqueue.
**What you need to do:**
* **No action required.** This is an automatic improvement to transcript completeness and session finalization timeliness for Zoom sessions. There are no changes to the Scribe API contract, session creation, or transcript retrieval endpoints. Transcripts from Zoom sessions that previously lost the final seconds of speech will now include those segments when the bot completes its drain. When the bot exits early, the session now finalizes promptly with the best-available transcript rather than waiting for background recovery.
Scribe: Zoom OAuth Scopes Updated for RTMS Event Delivery (July 2026)
#### Zoom OAuth Scopes Updated for RTMS Event Delivery
The Scribe API's Zoom OAuth connection flow now requests additional scopes required for real-time media streaming (RTMS) event delivery. Without these scopes, Zoom accepted the RTMS start request but never delivered the webhook events needed to launch the media stream, causing the bot to time out and be reaped without joining.
**What changed:**
* **Additional OAuth scopes requested.** The Zoom OAuth authorization flow now requests scopes that entitle the provider's grant to receive RTMS session lifecycle webhook events. Previously, the grant included scopes to start an RTMS session but not the scopes Zoom requires to deliver the corresponding event notifications.
* **Resolves RTMS join failures.** Zoom sessions started through the Scribe API Zoom path now receive the webhook events needed to dispatch the media worker. Previously, the RTMS start request succeeded (the session appeared to launch) but no audio stream was established, and the bot was removed by the join watchdog after approximately two minutes.
* **No changes to the Scribe API contract.** The Zoom session creation and OAuth connection endpoints are unchanged. The additional scopes are requested automatically during the OAuth consent flow.
**What you need to do:**
* **Reconnect Zoom if using the Scribe API Zoom path.** Providers who connected Zoom through the Scribe API should disconnect and reconnect their Zoom account so the new OAuth consent includes the additional scopes. Existing connections retain their original scope set until re-authorized.
* **No action for web-connected providers.** Providers who connected Zoom through the web application already have the required scopes.
---
# 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/api-reference/change-logs/amigo-api/amigo-api-history-02.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.