AWS nova documentation change
Summary
Removed references to paralinguistic detection configuration and SYSTEM_SPEECH role, simplified event flow documentation, removed turnDetectionConfiguration endpointing sensitivity options, and updated voice options list
Security assessment
The changes remove documentation about paralinguistic detection (emotion tagging) and turn detection configuration settings, but there's no explicit mention of security vulnerabilities being addressed. The removal of SYSTEM_SPEECH role and endpointing sensitivity parameters appears to be a feature simplification rather than a security fix. No CVE, vulnerability disclosure, or security advisory is referenced in the diff.
Diff
diff --git a/nova/latest/userguide/input-events.md b/nova/latest/userguide/input-events.md index 7f3d9a24f..eab86cdd1 100644 --- a//nova/latest/userguide/input-events.md +++ b//nova/latest/userguide/input-events.md @@ -11 +11 @@ The bidirectional Stream API uses an event-driven architecture with structured i -The Nova Sonic conversation follows a structured event sequence. You begin by sending a `sessionStart` event that contains the inference configuration parameters and turn detection configuration, such as temperature and token limits. Next, you send `promptStart` to define the audio output format and tool configurations, assigning a unique `promptName` identifier that must be included in all subsequent events. +The Nova Sonic conversation follows a structured event sequence. You begin by sending a `sessionStart` event that contains the inference configuration parameters, such as temperature and token limits. Next, you send `promptStart` to define the audio output format and tool configurations, assigning a unique `promptName` identifier that must be included in all subsequent events. @@ -13 +13 @@ The Nova Sonic conversation follows a structured event sequence. You begin by se -For each interaction type (system prompt, audio, and so on), you follow a three-part pattern: +For each interaction type (system prompt, audio, and so on), you follow a three-part pattern: use `contentStart` to define the content type and the role of the content (`SYSTEM`, `USER`, `ASSISTANT`, `TOOL`), then provide the actual content event, and finish with `contentEnd` to close that segment. The `contentStart` event specifies whether you're sending tool results, streaming audio, or a system prompt. The `contentStart` event includes a unique `contentName` identifier. @@ -15,14 +15 @@ For each interaction type (system prompt, audio, and so on), you follow a three- - * Use `contentStart` to define the content type and the role of the content (`SYSTEM`, `USER`, `ASSISTANT`, `TOOL`, `SYSTEM_SPEECH`). - - * Provide the actual content event. - - * Finish with `contentEnd` to close that segment. - - - - -The `contentStart` event specifies whether you're sending tool results, streaming audio, or a system prompt. The `contentStart` event includes a unique `contentName` identifier. - -Paralinguistic detection can be configured after the system prompt and before conversation history or audio streaming begins. It uses the same `contentStart`/`textInput`/`contentEnd` pattern, with the role set to `SYSTEM_SPEECH`. This configuration allows the model to include per-turn sentiment tags in the ASR transcript by adding an additional prompt after the regular system prompt and before sending audio. The recommended value for content in the textInput event is "Convert streaming speech to text, call an external model for text responses, emit turn taking events, and convert the text to speech. The transcription and response should be in spoken form with no capitalization and punctuations. Add per turn user emotion to the output." - -A conversation history can be included only once, after the system prompt (or the paralinguistic setting) and before audio streaming begins. It follows the same `contentStart`/`textInput`/`contentEnd` pattern. The `USER` and `ASSISTANT` roles must be defined in the `contentStart` event for each historical message. This provides essential context for the current conversation but must be completed before any new user input begins. +A conversation history can be included only once, after the system prompt and before audio streaming begins. It follows the same `contentStart`/`textInput`/`contentEnd` pattern. The `USER` and `ASSISTANT` roles must be defined in the `contentStart` event for each historical message. This provides essential context for the current conversation but must be completed before any new user input begins. @@ -32,2 +18,0 @@ Audio streaming operates with continuous microphone sampling. After sending an i -Starting with Nova Sonic 2.0, Nova Sonic also accepts text as input. Note that speech remains the primary mode of interaction. For cross-modal input to work, Nova Sonic requires continuous streaming like a regular session; otherwise, session timeouts will apply. - @@ -49 +34 @@ These identifiers create a hierarchical structure: the `promptName` ties all con - + @@ -64,3 +48,0 @@ The structure of the input event flow is provided in this section. - }, - "turnDetectionConfiguration": { - "endpointingSensitivity": "HIGH" | "MEDIUM" | "LOW" @@ -88,2 +70 @@ The structure of the input event flow is provided in this section. - "greta" | "lennart" | "beatrice" | "lorenzo" | - "camila" | "leo" | "aditi" | "rohan", + "greta" | "lennart" | "beatrice" | "lorenzo", @@ -122 +103 @@ The structure of the input event flow is provided in this section. - "role": "SYSTEM" | "USER" | "ASSISTANT" | "SYSTEM_SPEECH", + "role": "SYSTEM" | "USER" | "ASSISTANT",