vania-janet/multiturn-rag-retrieval-data huggingface dataset:
You might have a root node that conditions on #forecast which could answer the user. However, because the user's input includes the word tomorrow and the reservation node with slots is being processed, your assistant assumes the user is providing or updating the reservation date instead. The current node always gets priority. If you define a clear confirmation statement, such as, Ok, setting the reservation date to tomorrow, the user is more likely to realize there was a miscommunication and correct it.

Conversely, while filling slots, if the user provides a value that is not expected by any of the slots, there is a chance it will match against a completely unrelated root node that the user never intended to digress to.

Be sure to do lots of testing as you configure the digression behavior.
* When to use digressions instead of slot handlers: For general questions that users might ask at any time, use a root node that allows digressions into it, processes the input, and then goes back to the flow that was in progress. For nodes with slots, try to anticipate the types of related questions users might want to ask while filling in the slots, and address them by adding handlers to the node.

For example, if the node with slots collects the information required to fill out an insurance claim, then you might want to add handlers that address common questions about insurance. However, for questions about how to get help, or your stores locations, or the history of your company, use a root level node.









 Disambiguation 

When you enable disambiguation, you instruct your assistant to ask users for help when it finds that more than one dialog node can respond to their input. Instead of guessing which node to process, your assistant shares a list of the best node options with the user, and asks the user to pick the correct one.

![Shows a sample conversation between a user and the assistant, where the assistant asks for clarification from the user.](https://cloud.ibm.com/docs-content/v1/content/a2b18c153837bce00a5b4de496e4b4ca64bbf56e/assistant-data/images/disambig-demo.png)
A relationship that you identify in this way between the intent and the entity is not used by the intent classification model. However, when you add the mention to the entity, it is also added to that entity as new value. And when you add the mention to an existing entity value, it is also added to that entity value as new synonym. Intent classification does use these types of dictionary references in intent user examples to establish a weak reference between an intent and an entity.

For more information about contextual entities, see [Adding contextual entities](https://cloud.ibm.com/docs/assistant?topic=assistant-entitiesentities-create-annotation-based).





 Directly referencing an entity name in an intent example 

This approach is advanced. If used, it must be used consistently.

You can choose to directly reference entities in your intent examples. For instance, say that you have an entity that is called @PhoneModelName, which contains values Galaxy S8, Moto Z2, LG G6, and Google Pixel 2. When you create an intent, for example order_phone, you might then provide training data as follows:



* Can I get a @PhoneModelName?
* Help me order a @PhoneModelName.
* Is the @PhoneModelName in stock?
* Add a @PhoneModelName to my order.



![Screen capture showing intent definition](https://cloud.ibm.com/docs-content/v1/content/417db917d18067d9dcc4cf2612564a9a87c3ddc8/assistant/images/define-intent-entity.png)

Currently, you can only directly reference synonym entities that you define (pattern values are ignored). You cannot use [system entities](https://cloud.ibm.com/docs/assistant?topic=assistant-system-entities).

If you choose to reference an entity as an intent example (for example, @PhoneModelName)anywhere in your training data it cancels the value of using a direct reference (for example, Galaxy S8) in an intent example anywhere else.
It can also return no result if the input clearly does not match one of the two phrases.

For instance, if the user replies yes, the service likely returns a response that is very much like the following result. The score in the confidence field indicates a perfectly reliable match.

{
"result_index": 0,
"results": [
{
"alternatives":
{
"confidence": 1.0,
"transcript": "yes"
}
],
"final": true
}
]
}

But suppose, for example, the user replies nope. The service can return either a result with a very low confidence score or no result at all. An empty result is the clearest indication that the response does not match the grammar. An empty response is more likely to occur with complex grammars, where a valid response must match a specific multi-phrase sequence.





 Multi-phrase matches: The names grammar 

With a multi-phrase grammar, the user's response must be complete to be recognized. The user cannot omit a word or stop in the middle of the response. The absence of even a single word can cause the service to return an empty result.

Moreover, the service can return multiple transcripts if the user speaks phrases that are separated by sufficient silence to indicate that they are independent utterances. For example, consider the simple names grammar, which can match one of three multi-word names.

ABNF 1.0 ISO-8859-1;
language en-US;
mode voice;
root $names;

$names = Yi Wen Tan | Yon See | Youngjoon Lee ;

Suppose the user speaks one of the names from the grammar's rules, Yon See. The service returns a response that indicates a very high level of confidence in the match.

{
"result_index": 0,
"results": [
{
"alternatives":
{
"confidence": 0.92,
"transcript": "Yon See"
}
],
"final": true
}
]
}
FAQ 

This FAQ provides answers to common questions about the IBM Cloud® App ID service.



 Can I interact directly with the development team? 

Yes! Our development team would love to learn more about you and your use case. To get in touch, you can join us on Slack.



1. [Request an invitation](https://cloud.ibm.com/kubernetes/slack) to the workspace by entering your email.
2. Check your email for an invitation.
3. Click Join now to go to the sign-in page.
4. Create an account by entering your name and a password.
5. When you're in, search for the channel appid-at-ibm.
6. Join the channel.



Welcome! Now that you're up and running, feel free to ask questions, give feedback, and help others.

Using the Slack channel is not a replacement for opening a support ticket. If you encounter a more serious issue, issues with IBM Cloud that don't relate to App ID, or need to share more information than you are comfortable sharing in a public forum, open a support ticket.





 Why do I need to allowlist my redirect URI? 

A redirect URI is the callback endpoint of your application. When you allowlist your URI, you're giving App ID the OK to send your users to that location. At runtime, App ID validates the URI against your allowlist before it redirects the user. This process can help prevent phishing attacks and lessens the possibility that an attacker is able to gain access to your user's tokens. For more information about redirect URIs, see [Adding redirect URIs](https://cloud.ibm.com/docs/appid?topic=appid-managing-idpadd-redirect-uri).

Do not include any query parameters in your URL. They are ignored in the validation process. Example URL: http://host:[port]/path





 How does encryption work in App ID?
NAME|ID (required)
: Name or ID of the profile which contains the link to delete.

LINK_NAME|LINK_ID (required)
: Name or ID of the link to delete.

-f, --force
: Force deletion without confirmation.

-q, --quiet
: Suppress verbose output.





 Examples 

Delete the link my_link from trusted profile my-profile without confirmation:

ibmcloud iam trusted-profile-link-delete my-profile my_link -f







 ibmcloud iam trusted-profile-rule-create 

Create a rule for a trusted profile:

ibmcloud iam trusted-profile-rule-create (NAME|UUID) --name RULE_NAME --type RULE_TYPE [--realm-name REALM_NAME] --conditions <LIST_OF_CONDITIONS> [--expiration EXPIRATION_SEC] [--cr-type CR_TYPE] [--output FORMAT] [-q, --quiet] [-f, --force]

To view a full list of valid operator conditions for a claim rule, see [Trusted Profiles API](https://cloud.ibm.com/apidocs/iam-identity-token-apicreate-claim-rule)



 Command options 

NAME|ID (required)
: Name or ID of the profile to create a rule for.

--type (required)
: 'Profile-SAML' for a SAML rule or 'Profile-CR' for a compute resource rule

--conditions (required)
: List of conditions, provided as comma separated list of triple values "claim:CLAIM,operator:OPERATOR,value:VALUE". To specify mutiple conditions, specify the flag multiple times --conditions "claim:CLAIM1,operator:OPERATOR1,value:VALUE1" --conditions "claim:CLAIM2,operator:OPERATOR2,value:VALUE2".

--expiration
: Specify an expiration in seconds for SAML rules. Must not be provided for trusts established to Compute Resources (type = Profile-CR).

--name
: Name for the rule.

--cr-type
If the session or transaction is not found in a defined RBAC Policy, then that session is dropped by the Shield.



5. Select an option for User Determination from the drop-down list:



* SESSION signifies that the users connecting to the Shield are determined by the session user ID, as defined in the specified User Groups.
* SQL_COMMENT_RAW signifies that users connecting to the Shield are determined by user IDs specified in SQL comments. An SQL Comment Prefix field appears. This field defines the prefix string for SQL Comments containing the User ID. Here is an example SQL query with the appropriate comment:



select * from public.table1 + User:user_name 

You can specify an arbitrary string as the SQL Comment Prefix, but the user ID must be defined in User Groups.



* SQL_COMMENT_JWT signifies users connecting to the Shield are determined by a JWT specified in SQL comments. An SQL Comment Prefix field appears. This field defines the refix string for SQL comments containing the JWT.



The JWT serves as an authenticator for the User Group. Individual User IDs are ignored in this RBAC mode; instead, the Role argument in the JWT must match a User Group Name, in order to determine group membership. The following options are available:

a. SQL Comment Prefix -- for the prefix string for SQL Comments containing the JWT.

b. JWT TID (optional) for consuming the tenant identifier.

c. JWT AUD (optional) for consuming the audience identifier.

d. Key Value Pairs (optional) to consume key-value pairs in a line-by-line format. Each key must be specified on a single line, in key:value format.

e. JWT secret key is required field for an HS256 key.

f. JWKS Provider URL is required field for a URL, for an RS256 key. At least one of the previous two fields is required. If you submit either a JWT secret key or JWKS Provider URL, you can proceed without submitting the other field. The Data Security Broker Shield determines which algorithm to use.

g.
A relationship that you identify in this way between the intent and the entity is not used by the intent classification model. However, when you add the mention to the entity, it is also added to that entity as new value. And when you add the mention to an existing entity value, it is also added to that entity value as new synonym. Intent classification does use these types of dictionary references in intent user examples to establish a weak reference between an intent and an entity.

For more information about contextual entities, see [Adding contextual entities](https://cloud.ibm.com/docs/assistant-data?topic=assistant-data-entitiesentities-create-annotation-based).





 Directly referencing an entity name in an intent example 

This approach is advanced. If used, it must be used consistently.

You can choose to directly reference entities in your intent examples. For instance, say that you have an entity that is called @PhoneModelName, which contains values Galaxy S8, Moto Z2, LG G6, and Google Pixel 2. When you create an intent, for example order_phone, you might then provide training data as follows:



* Can I get a @PhoneModelName?
* Help me order a @PhoneModelName.
* Is the @PhoneModelName in stock?
* Add a @PhoneModelName to my order.



![Screen capture showing intent definition](https://cloud.ibm.com/docs-content/v1/content/a2b18c153837bce00a5b4de496e4b4ca64bbf56e/assistant-data/images/define-intent-entity.png)

Currently, you can only directly reference synonym entities that you define (pattern values are ignored). You cannot use [system entities](https://cloud.ibm.com/docs/assistant-data?topic=assistant-data-system-entities).

If you choose to reference an entity as an intent example (for example, @PhoneModelName)anywhere in your training data it cancels the value of using a direct reference (for example, Galaxy S8) in an intent example anywhere else.
id <br>Always included* <br>string The unique identifier for this Transit Gateway Connection <br>Example:1a15dca5-7e33-45e1-b7c5-bc690e569531 
 created_at <br>Always included* <br>date-time The date and time that this connection was created 
 network_id <br>string The ID of the network being connected via this connection. This field is required for some types, such as vpc and directlink For network types vpc and directlink it should be the CRN of the target vpc / gateway respectively. <br>Example:crn:v1:bluemix:public:is:us-south:a/123456::vpc:4727d842-f94f-4a2d-824a-9bc9b02c523b 
 base_connection_id <br>string network_type gre_tunnel connections use base_connection_id to specify the ID of a network_type classic connection the tunnel is configured over. The specified connection must reside in the same transit gateway and be in an active state. The classic connection cannot be deleted until any gre_tunnel connections using it are deleted. This field only applies to and is required for network type gre_tunnel connections. <br>Example:975f58c1-afe7-469a-9727-7f3d720f2d32 
 base_network_type <br>string Defines what type of network the GRE tunnel is targeting. This field is required for, and only applicable to, unbound_gre_tunnel type connections. <br>Allowable value: [classic] <br>Example:classic 
 local_bgp_asn <br>integer The local network BGP ASN. This field only applies to gre_tunnel and unbound_gre_tunnel type connections. <br>Example:64490 
 local_gateway_ip <br>string The local gateway IP address. This field only applies to gre_tunnel and unbound_gre_tunnel type connections. <br>Example:192.168.100.1
State data, including any context variables that are defined by your dialog or client application, are automatically stored by Watson Assistant, without any action required on the part of your application.

State data persists until you explicitly delete the session, or until the session times out because of inactivity.

If you prefer to manage state yourself, the v2 API also provides a stateless message method that functions more like the v1 API. If you use the stateless message method, you do not need to explicitly create or delete sessions, and your app is responsible for maintaining context. For more information about the stateless message method, see the [API Reference](https://cloud.ibm.com/apidocs/assistant/assistant-v2messagestateless).

If you have an existing application that uses the v1 API to send user input directly to a workspace, migrating your app to use the v2 API is a straightforward process.





 Set up an assistant 

The v2 runtime API sends messages to an assistant, which routes the messages to your dialog skill (formerly workspace). To set up an assistant, use the Watson Assistant user interface:



1. Click the Skills tab. Verify that your workspace is shown as an available skill. (All existing workspaces for your service instance are automatically converted to skills in the Watson Assistant user interface. This conversion does not make any change to the underlying workspace.)
2. Click the Assistants tab. Click Create assistant to create a new assistant. When prompted to add skills, click Add dialog skill and select the dialog skill that corresponds to your workspace.

For more information about creating assistants, see [Creating an assistant](https://cloud.ibm.com/docs/assistant?topic=assistant-assistant-add).
3. After your new assistant is created, click the ![Menu](https://cloud.ibm.com/docs-content/v1/content/417db917d18067d9dcc4cf2612564a9a87c3ddc8/assistant/images/kebab.png) menu and then select Settings.
4.
[Enterprise plan only](https://cloud.ibm.com/docs-content/v1/content/417db917d18067d9dcc4cf2612564a9a87c3ddc8/assistant/images/enterprise.png)



* [Activity tracker](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-admin-auditing)



The plan type of the service instance you are currently using is displayed in the page header. You can upgrade from one plan type to another. For more information, see [Upgrading](https://cloud.ibm.com/docs/assistant?topic=assistant-admin-managing-planadmin-managing-plan-upgrade).





 User-based plans explained 

Unlike API-based plans, which measure usage by the number of API calls made during a month, the Plus and Enterprise plans measure usage by the number of monthly active users.

A monthly active user (MAU) is any unique user who has at least one meaningful interaction with your assistant or custom application over the calendar billing month. A meaningful interaction is an exchange in which a user sends a request to your service and your service responds. Welcome messages that are displayed at the start of a conversation are not charged.

A unique user is recognized by the user ID that is associated with the person that interacts with your assistant. The web chat and other built-in integrations set this property for you automatically.





 Specifying the user ID with the REST API 

If you are using a custom client with the Watson Assistant API, you must set the user_id property in the message payload your client sends to the message method. The user_id property is specified at the root of the request body, as in this example:

{
"input": {
"message_type": "text",
"text": "I want to cancel my order"
},
"user_id": "my_user_id"
}

In some older SDK versions, the user_id property is not supported as a top-level method parameter.
The user interacts with areas of your app that do not require authentication.
2. Your application notifies App ID that the user wants to interact with your app as an anonymous user.
3. App ID creates an ad hoc user profile and calls the OAuth login that issues anonymous tokens for the anonymous user.
4. Using the anonymous tokens from App ID, you can create, read, update, and delete the attributes that are stored in the anonymous user profile.
5. The user might choose to sign in to access more features of your app.
6. Your application notifies App ID that the user wants to interact with your app as an identified user.
7. App ID returns the login widget to your app.
8. The user selects their preferred identity provider and provides their credentials.
9. Your application informs App ID that the user selected an identity provider.
10. App ID authenticates the call with the identity provider.
11. The identity provider confirms whether the login was successful.
12. App ID uses the anonymous token to find the anonymous profile and attaches the user's identity to it.
13. After App ID creates the new tokens, the service invalidates the user's anonymous token.
14. App ID returns the new access and identity tokens. The new tokens contain the public information that is shared by the identity provider and the attributes of the user's formerly anonymous profile.
15. The user is granted access to your app.
The request specifies the speaker ID for the speaker named speaker_one and the customization ID for the custom model that was created in the first step. The Content-Type header of the request must be multipart/form-data.

IBM Cloud

curl -X POST -u apikey:{apikey} --header "Content-Type:multipart/form-data" --form metadata="{"prompt_text": "Thank you and good-bye!", "speaker_id": "56367f89-546d-4b37-891e-4eb0c13cc833"}" --form file=@goodbye-prompt.wav "{url}/v1/customizations/82f4809a-bf63-89a6-52ca-22731fe467ba/prompts/goodbye"

IBM Cloud Pak for Data

curl -X POST --header "Authorization: Bearer {token}" --header "Content-Type:multipart/form-data" --form metadata="{"prompt_text": "Thank you and good-bye!", "speaker_id": "56367f89-546d-4b37-891e-4eb0c13cc833"}" --form file=@goodbye-prompt.wav "{url}/v1/customizations/82f4809a-bf63-89a6-52ca-22731fe467ba/prompts/goodbye"

The service returns the following response with information about the prompt, including its initial status:

{
"prompt": "Thank you and good-bye!",
"prompt_id": "goodbye",
"status": "processing",
"speaker_id": "823068b2-ed4e-11ea-b6e0-7b6456aa95cc"
}

Adding a prompt is an asynchronous operation.
You need to re-create a prompt to take advantage of a new or updated custom word.

When you re-create a prompt, the service replaces the existing prompt. The new prompt reflects any changes to the text or the audio of the prompt along with any custom word pronunciations defined since the prompt was first created. You can always pass the same text and audio that you used to create the original prompt if you are rerecording the prompt after adding a custom word.







 Custom prompts 

A custom prompt is defined by text and audio that speaks that text with the prosody that you want the service's voices to duplicate. The service extracts and analyzes the prosody from the prompt's audio. It then applies that prosodic information when it speaks the prompt's text with one of its own voices.

It is important to understand that when you use a prompt during speech synthesis, the service does not use the audio of the prompt itself. It instead uses the voice that you specify with the synthesis request. That voice adopts the prosody of the spoken audio from the prompt.

When you add a prompt to a custom model, you define the prompt by providing the text that is to be spoken, the recorded audio for that text, a unique user-specified identifier for the prompt, and an optional speaker model. The service generates and stores prosodic data for the prompt and uses the data to produce synthesized audio upon request. You must use credentials for the instance of the service that owns a custom model to add a prompt to it.

Always assign a meaningful name as the value of a prompt ID. For example, use a name like goodbye to indicate a prompt that speaks a standard farewell message. Prompt IDs must be unique within a given custom model, so you cannot define two prompts with the same ID for the same model. If you provide the ID of an existing prompt, the previously uploaded prompt is replaced by the new information. The service reprocesses the existing prompt by using the new text and audio, and it updates the prosodic data that is associated with the prompt.

When it processes a request to add a prompt, the service attempts to align the text and the audio that are provided for the prompt.