NAV Navbar

Creating Mix.nlu models

Use Mix.nlu to build a highly accurate, high quality custom natural language understanding (NLU) system quickly and easily, even if you have never worked with NLU before.

About Mix.nlu

Mix.nlu enables you to author Automatic Speech Recognition (ASR) and Natural Language Understanding (NLU) models for your application. Mix.nlu models are deployed from the Mix Project Dashboard. Your application accesses these models with the ASR as a Service gRPC API and the NLU as a Service gRPC API.

Develop a Mix.nlu model

To develop a Mix.nlu model, you use Mix.dashboard, Mix.nlu, and the Applications tab, as described in the Mix.nlu workflow below.

Mix.nlu workflow

The following procedure summarizes the workflow for creating an NLU model and optionally a recognition-only domain language model (DLM):

  1. Create a project: The first step is to create a project in Mix.dashboard. This project contains all the data necessary for building your models.
  2. Develop your model: You then develop your model in Mix.nlu by creating your ontology and adding samples.
  3. Train your model: Training is the process of building a model based on the data that you have provided.
  4. Test your model: After you train your model, use the Try panel to test it interactively and tune it.
  5. Build your model: When you make a build, you create a model version, which is a snapshot of your model as it exists now.
  6. Create your application configuration: To use your model in an application, you create your application configuration, which is the combination of the model versions that you want to use in your application (for example, Mix.asr model v2 with Mix.nlu model v3 for project CoffeeMaker).
  7. Deploy your application configuration to an environment that is accessible by your application.

Open the project in Mix.nlu

To open a project in Mix.nlu:

  1. From Mix.dashboard, select your project in the Projects list.
  2. Click the .nlu icon.

About the Mix.nlu Develop tab

You use the Mix.nlu Develop tab to create intents and entities, add samples, try your model, and then train it.

Note the following:

Multiple language support

Mix.nlu supports multiple languages (or locales) per project. As you can imagine, sample phrases of what your users may say will differ from one language to another. Your samples, therefore, will be different per language/locale.

To filter the list of samples, select the language code from the menu near the name of your project. (If your project includes a single language, no menu appears.)

For example, this project supports three locales, with en_US currently selected:

multi-lang-select

Mix.nlu also allows you to define different literals for list-type entity values per language/locale. This allows you to support the various languages in which your users might ask for an item, such as "coffee", "café", or "kaffee" for a "drip" coffee. More information on how to do this is provided in the sections that follow.

If your project includes multiple languages, you can filter the samples listed by selecting the locale from the menu near the name of your project... Mix.nlu allows you to include/exclude intents for the current language, and to define (edit) different literal values for a list entity. More details are provided in the sections that follow. To enable or archive/unarchive languages, go to the Dashboard, select your project, and click the Targets tab. For more information, see [Build resources](../builds/#build-resources). For the complete list of supported languages, see [Languages](../languages/#languages).

Develop your model

To develop your model, you:

  1. Add intents to your model. An intent defines and identifies an intended action. An utterance or query spoken by a user will express an intent, for example, to order a drink. As you develop an NLU model, you define intents based on what you expect your users to do in your application.
  2. Add entities to your model. Entities identify details or categories of information relevant to your application. While the intent is the overall meaning of a sentence, entities and values capture the meaning of individual words and phrases in that sentence.
  3. Link your entities to your intents. Intents are almost always associated with entities that serve to further specify particulars about the intended action.
  4. Add samples. Samples are typical sentences that your users might say. They teach Mix how your users will interact with your application.
  5. Annotate your samples. Once you define entities in an ontology, you need to annotate the tokens within the samples so that the machine learns.

Next, you train, test, and finally build when you're ready to use your models in your client application.

Add intents to your model

An intent is something a user might want to do in your application. You might think of intents as actions (verbs); for example, to order. For more information about intents, see Intents.

To add intents to your model:

  1. In Mix.nlu, click the Develop tab.
  2. On the Intents bar, click the plus (+) icon to add an intent.
    add_project_icon
  3. Type the name of your intent (for example, OrderCoffee) and press Enter.

The intent name is added to the list of intents.

Add entities to your model

Entities collect additional important information related to your intent. You might think of entities as analogous to slots or parameters. For example, if the user's intent is to order an espresso drink, entities might include [CoffeeType], [CoffeeSize], [Flavor], and so on.

This procedure describes how to create custom entities, which are the entities that are specific to your Intent. You can also use one of the existing predefined entities, which are entities that have already been defined to save you the trouble of creating them from scratch. Examples of predefined entities include monetary amounts, Boolean values, calendar items (dates, times, or both), cardinal and ordinal numbers, and so on. For more information, see Predefined entities.

To simplify your model, avoid adding a unique entity for each instance of a similar item. Instead, add a single entity that describes a general type of item. For example, instead of defining entities for Cappuccino, Espresso, and Americano, define a single entity named CoffeeType.

When you add an entity, you specify the following information:

Field Description
Type Specifies the type of entity. Valid values are:
  • List: A list entity has possible values that can be enumerated in a list. For example, if you have defined an intent called OrderCoffee, the entity [CoffeeType] would have a list of the types of drinks that can be ordered. See List entities.
  • Relationship: A relationship entity has a specific relationship to an existing entity, either the "isA" or "hasA" relationship. See Relationship entities.
  • Freeform: A freeform entity is used to capture user input that you cannot enumerate in a list. For example, a text message body could be any sequence of words of any length. In the query "send a message to Adam hey I'm going to be ten minutes late", the phrase "hey I'm going to be ten minutes late" becomes associated with the freeform entity [MessageBody]. See Freeform entities.
  • Regex-based: A regex-based entity defines a set of values using a regular expression. For example, to match account numbers, postal (zip) codes, order numbers, and other pattern-based formats. See Regex-based.
Referenced as Defines how the entity can be referred to; for example, whether it is referring to a person (Contact, "him") or a place (City, "there"). These are used for handling anaphoras in dialogs.
Dynamic (Applies to list entities only) Indicates if the entity is dynamic or not. Dynamic list entities allow you to upload data dynamically at runtime. See Dynamic list entities.
Literals (Applies to list entities only) Lets you enter literals and values. A set of literals is the range of tokens in a user's query that corresponds to a certain entity. With literals, you can specify misspellings and synonyms for an entity's value. For example, in the queries "I'd like a large t-shirt" and "I'd like t-shirt, size L", the literals corresponding to the entity [ShirtSize] are "large" and "L", respectively. In both cases, the value is the same. Literals can be paired with values, which are then returned in the NLU interpretation result. For example, "small", "medium", and "large" can be paired with the values "S", "M", and "L". For projects that include multiple languages, you can specify variations per language/locale for an entity value.
See List entities for details.
Note: There is a limit to the number of literals that you can enter. See Limits for more information.

To add entities to your model:

  1. On the Entities bar, click the plus (+) icon.
    add_entity_icon
  2. Type the name of the entity (for example, CoffeeSize) and press Enter.
  3. Click the entity to see its details.
  4. Define the entity (see the table above for a description of the fields).

The next step is to link your entities to your intents so that they can be interpreted.

For example, if you have an intent called OrderCoffee that uses the CoffeeSize and CoffeeType entities, you need to link these entities with the OrderCoffee intent. You also need to link any predefined entities that you want to use.

To link entities to your intents:

  1. On the Intents bar, select the intent.
  2. Click the link entity plus (+) icon and select the entity to link.
    link_entity_to_intent
  3. Repeat for each entity that you want to link to the intent.

Add samples

Samples are typical phrases or sentences that your users might say. They teach Mix how your users think (their mental models) when interacting with your application.

If your project includes multiple languages, be sure to select the appropriate locale before you start to enter samples.

multi-lang-select

You can enter a maximum of 500 characters per sample.

To add samples:

  1. (As required) Select the locale from the menu near the name of the project.
  2. In the Intents area, click the name of the intent.
  3. In the "The user says" field, type a sample utterance and press Enter. For example, "I want a double espresso."
  4. Repeat this procedure a few times.

The more samples you include, the better your model will become at interpreting.

For optimal machine learning, samples should be based on data of real-world usage. For information on importing samples, see Importing entity literals. Also see Creating and Annotating Datasets for Optimal Accuracy.

Annotate your samples

The final step is to annotate the literals in your samples with entities and tag modifiers.

For example, consider the following sentences:

Annotate these sample sentences to indicate which entities correspond to the literals. For example:

To annotate a sample, span the relevant tokens and select the appropriate entity from the menu.

To add AND, OR, or NOT tag modifiers to your annotation, first annotate the entities you want to modify. Then select the entities to modify by clicking the first annotation and then clicking the last annotation. Select Tag Modifier and the appropriate modifier from the menu.

For example, consider the sentence: "I want a cappuccino and a latte."

To annotate with the AND modifier, first annotate the sentence to indicate the entities for your literals:

I want a [CoffeeType]cappuccino[/] and a [CoffeeType]latte[/]

Next, click the annotation for cappuccino and then the annotation for latte. With both annotations selected, choose the AND modifier in the menu. The AND modifier is added:

I want a [AND][CoffeeType]cappuccino[/] and a [CoffeeType]latte[/][/]

Fix incorrect samples

If you make typos while adding samples, or if some samples were not transcribed correctly, you should fix them to make sure that they correspond to what users actually said. This builds a better model.

To fix an incorrect sample:

  1. Click the ellipsis icon ellipsis icon beside the sample that you want to edit and click Edit sample.
  2. Correct the text as appropriate.
  3. Click the checkmark to save your changes.

Edit or remove annotation

To change an entity that annotates a sample:

  1. Click the entity in the sample then click Remove.
  2. To choose a new entity, click the literal and choose a new entity.

Include or exclude samples

You can include or exclude a sample from your model without having to delete and then add it again. By default, new samples are included in the next model that you build. By excluding a sample, you specify that you do not want it to be used for training a new model.

To include or exclude a sample, click the ellipsis icon ellipsis icon beside the sample and then choose Include in model or Exclude in model. An excluded sample appears with gray diagonal bars. You can still modify the sample.

Use the check boxes (or the select-all check box above the list of samples) to include/exclude multiple samples.

Change intent

To assign a sample to a different intent, use the Move selected Samples dialog. When moving sample sentences, you can choose to also move or delete any annotations that you've made.

To assign a sample sentence to a different intent:

  1. Click the ellipsis icon ellipsis icon beside the sample and click Change Intent.
  2. In the Move selected Samples dialog, select an option for moving your selected sample: to use an existing intent, or to create a new one.
  3. Click Next.
  4. Either:
    • Choose an existing Intent: Choose another intent, NO_INTENT, or Unassigned Samples.
    • Create a new Intent: Enter a name for the new intent.
  5. Click Next.
  6. Choose to import or remove annotated entities. (This step is not available when moving intents to Unassigned Samples.)
  7. Click Next.
  8. To confirm, click Finish.

Use the check boxes (or the select-all check box above the list of samples) to move multiple samples.

Assign NO_INTENT

Sometimes an entity applies to more than one intent or, to look at it another way, an entity can mean different things depending on the dialog state. Rather than add this entity to multiple intents, it's best to use NO_INTENT.

Consider these two example interactions. The first one is in the context of booking a meeting.

User: Create a meeting
System: For when?
User: Tomorrow at 2

This second example is in the context of booking a flight.

User: Book flight to Paris
System: For when?
User: Tomorrow at 2

In this case, it's best to tag "Tomorrow at 2" as [nuance_CALENDARX]Tomorrow at 2[/] to cover both scenarios (and not as [MeetingTime]Tomorrow at 2[/] or [FlightDepartureTime]Tomorrow at 2[/]).

As shown in the examples, often these words or phrases are fragments and are used in a dialog as follow-up statements or queries.

Train your model

Training is the process of building a model based on the data that you have provided. If your project (or locale) contains no samples, you cannot train a model.

Developing a model is an iterative process that includes multiple training passes. For example, to retrain your model when you add or remove sample sentences, annotate samples, include or exclude certain samples, and so on. When you change the training data, your model no longer reflects the most up-to-date data. As this happens, the model must be retrained to enable testing the changes, exposing errors and inconsistencies, and so on.

To train your model:

  1. In Mix.nlu, click the Develop tab.
  2. (As required) Select the locale from the menu near the name of the project.
  3. Click Train Model.

Mix.nlu trains your model. This may take some time if you have a large training set. A status message is displayed when your model is trained.

To view all status messages (notifications), open the Console panel Console panel icon.

Training a model that includes prebuilt domains

If you have imported one or more prebuilt domains, click the Train Model button to choose to include your own data and/or the prebuilt domains. Since some prebuilt domains are quite large and complex, you may not want to include them when training your model.

To train your model to include one or more domains:

  1. Click the arrow beside Train Model.
    The list of prebuilt domains is displayed in addition to your own data.
    In the example below, the Nuance TV and Nuance Weather prebuilt domains have been imported into the project:
  2. Check the domains you want to include.
  3. Check My data to include your data.
  4. Click Train Model.

Test it

After you train your model, test it interactively in the Try panel. Use testing to tune your model so your client application can better understand its users.

If you are unsatisfied with the result, you can manually assign an intent or annotate your sentence by adding it to your project as a new sample.

The Results area shows the interpretation with the highest confidence. Information from the NLU engine, including all interpretations, appears on the right formatted as a JSON object. For more information on the fields in an interpretation, see the reference section: Interpretation.

To test your model:

  1. In Mix.nlu, click the Develop tab.
  2. (As required) Select the locale from the menu near the name of the project.
  3. Click Try. The Try panel appears.
  4. Enter a sentence your users might say and press Enter.
  5. If the intent is incorrect, click Add Sample and then change the intent.
  6. If the annotated entities are incorrect, click Add Sample and then edit the annotation.

The Try panel presents the response from the NLU engine. The Results area displays the orderCoffee intent with a confidence score of 1.00.

The Results area reflects only the changes you have made to intents and entities since the last time you trained a model. No annotation appears in the Results area if the NLU engine cannot use your model to interpret the entities in your sample. Also, there is no annotation for dynamic list entities. Only your client application provides this information at runtime.

Build your model

You build your model on the Console panel, which lets you build Mix.asr, Mix.nlu, and Mix.dialog models and generate a version.

  1. In Mix.nlu, open the Console panel Console panel icon.
  2. Click the Build tab.
  3. Specify the builds to create.
    Nuance recommends that you always build both your ASR and NLU models at the same time.
  4. (As required) In the Locale(s) area, remove any locales you wish to exclude from ASR and NLU models. You can always add the locale back later. At least one locale is required. Each locale must contain at least one sample sentence.
    add_locale_build_tab
    Note: Locale buttons can have the following colors:
    • Blue: Locale is valid.
    • Orange: There is an issue with this locale that requires your attention. You must fix the issue before you can build resources. See the message for details.
    • Red: There is a serious issue with this locale. Remove the locale or try again later. If the issue persists, contact Nuance.
    • Gray: Locales are not applicable. This occurs when you build a Mix.dialog resource, since dialog builds include all languages in the project.
  5. (As required) In NLU Source, choose the domains to include in the model. See the next section for details.
  6. (Optional) Enter an optional note about this version.
  7. Click Build.
  8. To close the Console panel, click the Console panel icon again.

The build version is created and listed in the Builds tab.

Now that you have created your version, you can use it in an application.

Building a model that includes prebuilt domains

If you have imported one or more prebuilt domains, they are listed in the Build tab under NLU Source. To build your model, check the domains you want to include and click Build. Note that not all domains may be supported in the languages configured for your project.

Including a prebuilt domain adds to the time it takes to build a model. Some prebuilt domains are quite large and complex so you may not want to include them if they are not necessary.

Note that the nuance_custom_data source specifies the intents and entities that you have created in the Mix.nlu window.

Discover what your users say

Now that your model is ready, you can look at the sentences that people speak or type while using your application. These sentences appear in the Discover tab. You’ll review them there, then add the ones you want directly into your intents on the Develop tab to improve and grow your model.

You’ll go back to the Develop tab to work on (annotate) these new samples, then to the Build tab to redeploy your updated model, and finally view the data from your newest model on the Discover tab. Rinse and repeat!

Mix.nlu Console panel

In addition to allowing you to build your models, the Console panel displays notifications and lets you create builds for ASR/NLU.

Display the Console panel

To display the Console panel, click the Console panel icon Console panel icon.

To hide it, click the icon again.

View notifications

The Notifications tab displays notifications for your projects. From this tab you can:

Ontology

In natural language understanding, an ontology is a formal definition of entities, ideas, events, and the relationships between them, for some knowledge area or domain. The existence of an ontology enables mapping natural language utterances to precise intended meanings within that domain.

In the context of Mix.nlu, an ontology refers to the schema of intents, entities, and their relationships that you specify and that are used when annotating your samples, and interpreting user queries.

Intents

An intent identifies an intended action. For example, an utterance or query spoken by a user expresses an intent to order a drink. As you develop an NLU model, you define intents based on what you want your users to be able to do in your application. You then link intents to functions or methods in your client application logic.

Here are some examples of intents you might define:

Intents are often associated with entities to further specify particulars about the intended action.

Entities

An entity is a language construct for a property, or particular detail, related to the user's intent. For example, if the user's intent is to order an espresso drink, entities might include [CoffeeType], [Flavor], [Temperature], and so on. You can link entities and their values to the parameters of the functions and methods in your client application logic.

If an entity applies to a particular intent, it is referred to as a relevant entity for that intent. The idea of relevant entities is important:

Mix.nlu supports the following entity types:

List entities

A list entity has possible values that can be enumerated in a list. For example, if you have defined an intent called orderCoffee, the entity [CoffeeType] would have a list of drink types that can be ordered. Other list types entities might include song titles, states of a light bulb (on or off), names of people, names of cities, and so on.

A literal is the range of tokens in a user's utterance or query that corresponds to a certain entity. The literal is the exact spoken text. For example, in the query "I'd like a large t-shirt", the literal corresponding to the entity [ShirtSize] is "large". Other literals might be "small", "medium", "large", "big", and "extra large". When you annotate samples, you select a range of text to tag with an entity. For list-type entities, you can then add the text to the list for the entity. Lists of literals can also be uploaded in .list or .nmlist files. For more information, see Importing entity literals.

Literals can be paired with values, which are then returned in the JSON object. For example, "small", "medium", and "large" can be paired with the values "S", "M", and "L", respectively. Multiple literals can have the same value, which makes it easy to map different ways a user might say an entity into a single common form. For example, "large", "big", "very big" could all be given the same value "L".

Defining literal-value pairs per language

Similarly, if your project includes multiple languages, you will want to support the various ways that users might ask for an item in their language of choice. Literals will, therefore, be different per language for list-based entities, whereas the values will be shared across all languages.

For example, let's say that you're creating a [BeverageSize] list entity, and for the fr_FR locale you start by adding the literal-value pair: petit-small

This first literal-value pair will be added to all languages/locales in your project because it introduces the value "small". For other languages that your projects supports, you will want to change the "petit" literal to something else, such as "small" or "mini" for en_US.

In this case, you would switch to the en_US locale using the menu near the name of your project, and in the BeverageSize entity panel, hover over the petit-small entry and click Edit. You delete literals in the same way.

In this case, you would switch to the en_US locale using the menu near the name of your project, and in the BeverageSize entity panel, add literals that an English speaker might say.

entity-edit

When you enter the new literal it is applied only to the BeverageSize entity for the currently selected locale, en_US in this case.

entity-edit-literal

To remove a literal, click the delete icon close-icon next to the literal. You are asked to confirm the deletion.

entity-edit-literal

Dynamic list entities

It is not always feasible to know all possible literals when you create a model, and you may need the ability to interpret values at runtime. For example, each user will have a different set of contacts on his or her phone. It is not practical (or doable) to add every possible set of contact names to your entity when you are building your model in Mix.nlu.

Dynamic list entities allow you to upload data dynamically at runtime and use this data to provide personalization and to improve recognition and natural language understanding accuracy.

Defining dynamic entities

To define a list entity as dynamic, check the Dynamic box for this entity.

While dynamic data is uploaded at runtime, it is still important to define a representative subset of literal and value pairs for dynamic list entities. This ensures that the model is trained properly and improves the accuracy of the ASR. Using our contact example, this means that you should include a representative subset of what you expect contact names to look like, and ensure that you have samples with the proper annotation.

When naming your dynamic entities in each model, keep in mind that they are global per application ID (across languages and deployed model versions).

Freeform entities

A freeform entity is used to capture user input that you cannot enumerate in a list. For example, a text message body could be any sequence of words of any length. In the query "send a message to Adam hey I'm going to be ten minutes late", the phrase "hey I'm going to be ten minutes late" becomes associated with the freeform entity [MessageBody].

Having difficulty determining which type to use? See the examples below.

Example sports application – List type

Consider a sports application, where your samples would include many ways of referring to one sports team, for example, the Montreal Canadiens:

Since you could enumerate each option, you would make this a list type and annotate it accordingly. Additionally, the NLU engine would learn about the entity from these different ways of referring to the Canadiens. You would not have to enumerate every possible sports team or every possible way to refer to the Canadiens.

Example SMS app – Freeform type

When your sample includes text that does not have well-defined many-to-one relationships and that cannot be fully enumerated, use the freeform entity type. Consider an SMS app, where it is impossible to list every way that a user may say something to your app. The body of an SMS message could be literally anything. Here is an example of what those annotations might look like:

[MessageBody] would be a freeform entity because it is unpredictable and cannot be fully enumerated.

Be aware that any words inside the freeform tag do not improve your NLU model. The text marked as the freeform part of the sample (and only that part!) is like a black box that won’t be further analyzed. Additionally, the ASR engine won’t be able to improve the recognition of these words as it would be able to do for words in a list type. Use the freeform type with care.

Best practice

Be careful not to overuse the freeform entity, especially when an entity has many options but already has large base grammars, like SONGS or CITIES. It is not recommended to use the freeform entity for items like these because they already have a huge number of predefined values that the NLU engine has been trained on.

Relationship entities: isA and hasA

A relationship entity has a specific relationship to an existing entity, either the "isA" or "hasA" relationship.

An isA relationship states that [ENTITY_X] is a type of [ENTITY_Y]. The definition of Y is inherited by X. For example, the list of literals, grammars, or relationships. Note that while the definition of the child entity is the same as the parent entity, the child entity picks up differences because of its different role in your samples.

For example, say you have a train schedule app and you want to accept queries such as "When is the next train from Boston to New York." Both "Boston" and "New York" are instances of the [Station] entity. If you annotated the query using [Station] for both cases, then you would have no way of determining which is the origin and which is the destination. To resolve this, you could instead define two list-type entities, [FromStation] and [ToStation], and associate each with the same list of literals. This would, of course, be time consuming and difficult to manage. The better solution is to define one list-type entity [Station] with an associated list of cities/stations, and then define [FromStation] isA [Station], and [ToStation] isA [Station]. Now, you only have one list of stations to manage. The model interprets queries and returns [FromStation] or [ToStation] as appropriate for the roles they play in the query, and returns literals and values from the list associated with the [Station] entity.

You can also make isA relationships to predefined entities. For example, [Age] is a [nuance_CARDINAL_NUMBER].

A hasA relationship states that [Entity_Y] is a property or a part of [Entity_X]. That is, X has a Y. For example, the entity [FullName] might have the entities [GivenName] and [FamilyName] as part of it. The entity [Drink] might have [CoffeeType] and [Size] as part of it. Note that unlike an isA relationship, an entity can have multiple hasA relationships.

You would use hasA relationships if the entities in your queries have structure. However, Nuance recommends that you use hasA relationships only if you have a definite need, since they can be tricky to work with, and the complexity means the NLU models may be less accurate than desired. An example of a definite need is to be able to interpret a query like "put the red block into the green box". In this case you need a way to associate the color red with the block and the color green with the box. Without using hasA relationships the JSON object returned would be flat and you would not know which color went with which object. Using hasA, you would define an [Object] that has a [Color] and [Shape]. Then the following annotation becomes possible: "put the [Object][Color]red[/][Shape]block[/][/] into the [Object][Color]green[/][Shape]box[/][/]".

Anaphoras

An anaphora is defined as "the use of a word referring back to a word used earlier in a text or conversation, to avoid repetition" (from Lexico/Oxford dictionary).

An anaphora often occurs in dialogs and makes it difficult to understand what the user means. For example, consider the following phrases:

In this example, "there" is an anaphora for "Montreal".

In this example, "him" is an anaphora for "Bob".

An ellipsis (intent anaphora) occurs when a user references an intent that was identified in a previous request. The dialog recognizes when the wording of the new request refers to the intent of the previous request, including its entities. For example: * User: “What is the weather in Boston this weekend?” * System: “This weekend in Boston the weather will be …” * User: “What about Montreal?” * The system understands the intent is to find the weather and includes the entity weekend: “This weekend in Montreal, the weather will be …” Note: Ellipsis are supported in the context of the most recent intent; the system cannot recognize previous intents.

Tagging anaphoras

In Mix.nlu, you can:

This will help your dialog application determine to which entity the anaphora refers, based on the data it has, and internally replace the anaphora with the value to which it refers. For example, "Drive there" would be interpreted as "Drive to Montreal".

The four types of anaphora entities are:

To identify an entity as referable:

To use anaphoras in annotations: **Step 1: Identify an entity as referable**
  1. In the Entities area of the Develop tab, select the entity.
  2. In the Referenced as field, select the correct anaphora type for this entity.
    For example, for a contact, select REF_PERSON:
  3. Train your model.

Tag modifiers

A tag modifier is an entity that modifies other entities by adding a logical operator: AND, OR, or NOT. You specify tag modifiers by annotating samples.

Your Mix.nlu model can use the AND and OR modifiers to connect multiple entities. It can use the NOT modifier to negate the meaning of an entity.

For example, "a cappuccino and a latte" would be annotated as [AND][CoffeeType]cappuccino[/] and a [CoffeeType]latte[/][/]. The AND modifier applies to the two CoffeeType annotations.

The literal "no cinnamon" would be annotated as no[NOT][SprinkleType]cinnamon[/][/]. The NOT modifier applies to the SprinkleType annotation.

Note how the literals "and" and "no" are not annotated as an entity or tag modifier. Instead, tag modifiers are the parents of the annotations that they connect or negate.

Regex-based

A regex-based entity defines a set of values using regular expressions. For example, product or order values, which are typically alphanumeric sequences, such as gro-456 or ABC 967 defined in:
[A-Za-z]{3}\s?-?\s?[0-9]{3}

You might use regex-based entities to match account numbers, postal (zip) codes, confirmation codes, PINs, driver's license numbers, and other pattern-based formats.

Creating regex-based entities

To use a regular expression to validate the value of an entity (for example, an order number as shown below), enter the expression as valid JavaScript.

In this example the user is creating a regex-based entity called OrderNumber, which will match order numbers in the form gro-456, COF-123, sla 889, and so on (three characters + an optional hyphen and/or space + three digits).

To save the pattern, click Download project and save regex-based entity.

Before the entity is created (or modified), Mix.nlu exports your existing NLU model to a TRSX file so that you have a backup. If your project includes multiple languages, separate TRSX files are created, one for each language/locale. Creating (or modifying) a regex-based entity requires your NLU model to be retokenized, which may take some time and impact your existing annotations. You receive a message when the entity is saved successfully.

Mix.nlu validates the search pattern as you enter it and alerts you if it is invalid. Invalid expressions (including empty values) are not saved.

Note the following points when creating regular expressions in regex-based entities:

Note: Nuance does not recommend using a caret (^) to denote the beginning of a regular expression, or a dollar sign ($) to denote the end, as doing so will cause the NLU engine to expect the expression at the beginning, or end, of a sentence. Consider this phone number regex-based entity (any phone number of format 123-456-7890):

Annotating with regex-based entities

Annotating with regex-based entities means identifying the tokens to be captured by the regex-defined value. At runtime the model tries to match user words with the regular expression.

For example:

What's the status of order [OrderNumber]COF-123[/]

Predefined entities

Mix.nlu includes a set of predefined entities that can be useful as you develop your own NLU models. Predefined entities save you the trouble of defining entities that are generally useful in a number of different applications, such as monetary amounts, Boolean values, calendar items (dates, times, or both), cardinal and ordinal numbers, and so on.

A predefined entity is not limited to a flat list of values, but instead can contain a complete grammar that defines the various ways that values for that entity can be expressed. A grammar is a compact way of expressing a vast range of possible constructions.

For example, within the nuance_DURATION entity, there is a grammar that defines expressions such as "3.5 hours", "25 mins", "for 33 minutes and 19 seconds", and so on. It would simply not make sense to try to capture the possible expressions for this entity in a list.

Some notes:

For more information, including on specific predefined entities, see Predefined entities.

## Understanding the link between project and data pack versions To find out which data pack version your project is using, go to the Dashboard, select your project and click the Details tab. The data pack version is provided in the Information area. Projects are associated with a specific version of a data pack. When you create a new project, it is associated with the current data pack version. When you rebuild your model, it continues to use the same data pack version. For example, if the version of the data pack is 6.6.11 when you create a new project, this data pack version continues to be used when you rebuild your model, even if the current data pack version has increased. Data pack versions may not be fully backward-compatible. This means that, if you create a new project but you want to import the TRSX content of a project associated with an older data pack version, you may encounter issues. For example, a previous version of the nuance_DURATION entity generated a response of {"DURATION_ABS":{"HOUR":2}}, but the current version data pack returns a different format: {"DURATION_ABS": {"UNIT":"hour", "NUMBER":2}}. ## Numeric value ranges for predefined entities Most predefined entities use a mix of both regular expression (regex) and GRXML grammars. In general, GRXML grammars are used to parse expressions written as words (for example, "five degrees Celsius"), and regex are used to parse expressions that include Arabic numerals, punctuation, or symbols (for example, "5°C"). However, GRXML grammars can also be used to parse expressions with Arabic numbers (for example, "December 10 2018"), and a regex may parse expressions that include words (for example, "-5 degrees" or "5:15 tomorrow"). For **regex**, there is no limit to the number of digits in an Arabic number for any entity with regex values in the data pack. This applies to all languages. For **GRXML** grammars, the accepted ranges of numeric values are provided below, per predefined entity (when applicable). Note that the values are provided based on US English. The coverage may vary per language. As an example, for languages where large numbers are expressed as compound words (such as Finnish and Germanic languages), the value ranges may be more limited because a grammar cannot list all the possible compounds for large numbers. ## nuance_AMOUNT ```json { "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "properties": { "nuance_AMOUNT": { "type": "object", "properties": { "nuance_UNIT": { "anyOf": [ { "type": "number" }, { "type": "string" } ] }, "nuance_NUMBER": { "type": "string" } }, "required": [ "nuance_UNIT", "nuance_NUMBER" ] } }, "additionalProperties": false } ``` A sum of money intended for use in banking actions and for payments. The currency is dependent on the grammar. For example, if the en-US grammar is used, the only currency accepted is the US Dollar. Sample language: * four dollars and seventy five cents * $4.75 For example, "five dollars" gives this response (formatted in JSON):
{
  "nuance_NUMBER":5,
  "nuance_UNIT":"USD"
}
### Numeric value range <= 99,999,999,999 ## nuance_BOOLEAN ```json { "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "properties": { "BOOLEAN": { "type": "nuance_boolean" } }, "additionalProperties": false } ``` Declaration of true or false. Sample language: * yes * that's absolutely right * it is not * not really ## nuance_CALENDARX ```json { "$schema": "http://json-schema.org/draft-04/schema#", "definitions": { "__main__.TimeAbs": { "type": "object", "properties": { "nuance_TIME_ABS": { "type": "object", "properties": { "nuance_AMPM": { "type": "string", "pattern": "[am|pm]" }, "nuance_MINUTE": { "type": "number" }, "nuance_HOUR": { "type": "number" }, "nuance_MODIFIER": { "type": "string", "pattern": "[fuzzy]" } } } }, "additionalProperties": false }, "__main__.TimeRel": { "type": "object", "properties": { "nuance_TIME_REL": { "type": "object", "properties": { "nuance_INCREMENT": { "type": "number" }, "nuance_STEP": { "type": "string", "pattern": "[hour|minute]" }, "nuance_MODIFIER": { "type": "string", "pattern": "[fuzzy]" } } } }, "additionalProperties": false }, "__main__.DateAbs": { "type": "object", "properties": { "nuance_DATE_ABS": { "type": "object", "properties": { "nuance_DAY": { "type": "number" }, "nuance_MONTH": { "type": "number" }, "nuance_YEAR": { "type": "number" }, "nuance_MODIFIER": { "type": "string", "pattern": "[fuzzy]" } } } }, "additionalProperties": false }, "__main__.DateRel": { "type": "object", "properties": { "nuance_DATE_REL": { "type": "object", "properties": { "nuance_NAMED_DAY": { "type": "string" }, "nuance_DAY_OF_WEEK": { "type": "number", "pattern": "[1-7]" }, "nuance_INCREMENT": { "type": "number" }, "nuance_STEP": { "type": "string", "pattern": "[day|week|month|year]" }, "nuance_MODIFIER": { "type": "string", "pattern": "[fuzzy]" } } } }, "additionalProperties": false }, "__main__.Date": { "type": "object", "properties": { "nuance_DATE": { "anyOf": [ { "$ref": "#/definitions/__main__.DateAbs" }, { "$ref": "#/definitions/__main__.DateRel" } ] } }, "additionalProperties": false }, "__main__.Time": { "type": "object", "properties": { "nuance_TIME": { "anyOf": [ { "$ref": "#/definitions/__main__.TimeAbs" }, { "$ref": "#/definitions/__main__.TimeRel" } ] } }, "additionalProperties": false }, "__main__.CalendarRange": { "type": "object", "properties": { "nuance_CALENDAR_RANGE_START": { "nuance_CALENDAR": { "anyOf": [ { "$ref": "#/definitions/__main__.Date" }, { "$ref": "#/definitions/__main__.Time" } ] } }, "nuance_CALENDAR_RANGE_END": { "nuance_CALENDAR": { "anyOf": [ { "$ref": "#/definitions/__main__.Date" }, { "$ref": "#/definitions/__main__.Time" } ] } } }, "additionalProperties": false } }, "type": "object", "properties": { "CALENDARX": { "type": "object", "properties": { "oneOf": [ { "nuance_CALENDAR": { "anyOf": [ { "$ref": "#/definitions/__main__.Date" }, { "$ref": "#/definitions/__main__.Time" } ] }, "nuance_CALENDAR_RANGE": { "$ref": "#/definitions/__main__.CalendarRange" } } ] } } }, "additionalProperties": false } ``` Defines a discrete calendar event in terms of date, time, or both. Additionally, the calendar event may be in absolute or relative terms. Named holidays are also represented. Sample language: * july * 5:00 * around 5:30 * in 9 hours * within the next 2 hours * in the first week of april * between 1pm and 4pm For example, "from monday to friday" gives this response (formatted in JSON):
{
  "nuance_CALENDAR_RANGE": {
    "nuance_CALENDAR_RANGE_START": {
      "nuance_CALENDAR": {
        "nuance_DATE": {
          "nuance_DATE_REL": {
            "nuance_INCREMENT": 0,
            "nuance_DAY_OF_WEEK": 2
          }
        }
      }
    },
    "nuance_CALENDAR_RANGE_END": {
      "nuance_CALENDAR": {
        "nuance_DATE": {
          "nuance_DATE_REL": {
            "nuance_INCREMENT": 0,
            "nuance_DAY_OF_WEEK": 6
          }
        }
      }
    }
  }
}
### Numeric value range * For nuance_CALENDARX, nuance_DATE_REL, nuance_TIME_REL: <= 120. Note that this grammar also covers Arabic numbers. For example, "in 120 hours".) * For nuance_YEAR: 1900-2050 (as Arabic numbers in GRXML for English and as compounds for de-de.) ## nuance_CARDINAL_NUMBER ```json { "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "properties": { "nuance_CARDINAL_NUMBER": { "anyOf": [ { "type": "number" }, { "type": "string" } ] } }, "additionalProperties": false } ``` A non-fractional whole number denoting quantity (1, 2, 3) as opposed to an ordinal number (denoting order like first, second, third). Cardinal numbers can be described in natural speech up to and including a million, but any number larger than that must be dictated as a string of digits. Choose nuance_CARDINAL_NUMBER instead of nuance_NUMBER or nuance_DOUBLE for numerical entities that must have no fraction or decimal point. Sample language: * 27 * forty three * oh one two three ### Numeric value range <= 99,999,999 ## nuance_DISTANCE ```json { "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "properties": { "nuance_DISTANCE": { "type": "object", "properties": { "oneOf": [{ "nuance_DISTANCE_ABS": { "type": "object", "properties": { "nuance_UNIT": { "type": "string", "pattern": "[km|m|cm|mm|mi|yd|ft|in]" }, "nuance_MODIFIER": { "type": "string", "pattern": "fuzzy" }, "nuance_NUMBER": { "anyOf": [{ "type": "number" }, { "type": "string" } ] } } } }, { "nuance_DISTANCE_REL": { "type": "object", "properties": { "nuance_DISTANCE_ABS": { "type": "object", "properties": { "nuance_NUMBER": { "anyOf": [{ "type": "number" }, { "type": "string" } ] }, "nuance_UNIT": { "type": "string", "pattern": "[km|m|cm|mm|mi|yd|ft|in]" } }, "nuance_MODIFIER": { "type": "string", "pattern": "[GT|LT|GE|LE|EQ|INC]" } } }, "required": "nuance_MODIFIER" } } ] } } }, "additionalProperties": false } ``` Amount of space between two things or people. Sample language: * five meters * 42 km * seven inches Examples, formatted in JSON: The input "more than three km" gives this response:
{
  "nuance_DISTANCE_REL": {
    "nuance_DISTANCE_ABS": {
      "nuance_UNIT": "km",
      "nuance_NUMBER": 3
    },
    "nuance_MODIFIER": "GT"
  }
}
The input "two and a half meters" gives:
{
  "nuance_DISTANCE_ABS": {
    "nuance_UNIT": "m",
    "nuance_NUMBER": 2.5
  }
}
### Numeric value range <= 99,999,999 ## nuance_DOUBLE ```json { "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "properties": { "nuance_DOUBLE": { "anyOf": [ { "type": "number" }, { "type": "string" } ] } }, "additionalProperties": false } ``` Fractions and decimal-point numbers. Choose nuance_DOUBLE instead of nuance_NUMBER or nuance_CARDINAL_NUMBER for numerical entities that must only be fractions or contain a decimal point. Sample language: * 2.7 * one and two tenths ### Numeric value range * For the whole part and decimal part in decimal-point numbers: <= 99,999,999 * For fractions: Denominators up to tenth ## nuance_DURATION ```json { "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "properties": { "nuance_DURATION": { "type": "object", "properties": { "oneOf": [{ "nuance_DURATION_ABS": { "type": "object", "properties": { "nuance_NUMBER": { "type": "number" }, "nuance_UNIT": { "type": "string", "pattern": "[millisecond|second|minute|hour|day|week|month|year]" }, "nuance_MODIFIER": { "type": "string", "pattern": "[fuzzy]" } } } }, { "nuance_DURATION_REL": { "type": "object", "properties": { "nuance_DURATION_ABS": { "type": "object", "properties": { "nuance_NUMBER": { "type": "number" }, "nuance_UNIT": { "type": "string", "pattern": "[millisecond|second|minute|hour|day|week|month|year]" } } }, "nuance_MODIFIER": { "type": "string", "pattern": "[GT|LT|GE|LE|EQ|INC]" } }, "required": "nuance_MODIFIER" } } ] } } }, "additionalProperties": false } ``` Period of time described in absolute (hours, minutes, seconds, and days) or relative terms (for example, "two hours more"). Sample language: * 7 hours * 2.3 hours * around two hours and fourteen minutes * half an hour * all day * less than thirty minutes Examples (formatted in JSON): The input "a year and a month" gives this response:
{
  "nuance_DURATION_ABS": {
    "nuance_NUMBER": 13,
    "nuance_UNIT": "month"
  }
}
The input "more than an hour" gives:
{
  "nuance_DURATION_REL": {
    "nuance_DURATION_ABS": {
      "nuance_NUMBER": 1,
      "nuance_UNIT": "hour"
    },
    "nuance_MODIFIER": "GT"
  }
}
### Numeric value range <= 99,999,999 ## nuance_DURATION_RANGE ```json { "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "properties": { "nuance_DURATION_RANGE": { "type": "object", "properties": { "nuance_DURATION_RANGE_START": { "type": "object", "properties": { "nuance_DURATION": { "type": "object", "properties": { "oneOf": [{ "nuance_DURATION_ABS": { "type": "object", "properties": { "nuance_NUMBER": { "type": "number" }, "nuance_UNIT": { "type": "string", "pattern": "[millisecond|second|minute|hour|day|week|month|year]" }, "nuance_MODIFIER": { "type": "string", "pattern": "[fuzzy]" } } }, "nuance_DURATION_REL": { "type": "object", "properties": { "nuance_DURATION_ABS": { "type": "object", "properties": { "nuance_NUMBER": { "type": "number" }, "nuance_UNIT": { "type": "string", "pattern": "[millisecond|second|minute|hour|day|week|month|year]" } } }, "nuance_MODIFIER": { "type": "string", "pattern": "[GT|LT|GE|LE|EQ|INC]" } } } } ] } } } }, "nuance_DURATION_RANGE_END": { "type": "object", "properties": { "nuance_DURATION": { "type": "object", "properties": { "oneOf": [{ "nuance_DURATION_ABS": { "type": "object", "properties": { "nuance_NUMBER": { "type": "number" }, "nuance_UNIT": { "type": "string", "pattern": "[millisecond|second|minute|hour|day|week|month|year]" }, "nuance_MODIFIER": { "type": "string", "pattern": "[fuzzy]" } } }, "nuance_DURATION_REL": { "type": "object", "properties": { "nuance_DURATION_ABS": { "type": "object", "properties": { "nuance_NUMBER": { "type": "number" }, "nuance_UNIT": { "type": "string", "pattern": "[millisecond|second|minute|hour|day|week|month|year]" } } }, "nuance_MODIFIER": { "type": "string", "pattern": "[GT|LT|GE|LE|EQ|INC]" } } } } ] } } } } } } }, "additionalProperties": false } ``` Represents a duration when it can span one of two time intervals. There must be at least a start or end duration value, and most often there are both. Sample language: between two and three hours For example "between two and three months" gives this response (formatted in JSON):
{
  "nuance_DURATION_RANGE_START": {
    "nuance_DURATION": {
      "nuance_DURATION_ABS": {
        "nuance_NUMBER": 2,
        "nuance_UNIT": "month"
      }
    }
  },
  "nuance_DURATION_RANGE_END": {
    "nuance_DURATION": {
      "nuance_DURATION_ABS": {
        "nuance_NUMBER": 3,
        "nuance_UNIT": "month"
      }
    }
  }
}
## nuance_EXPIRY_DATE ```json { "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "properties": { "nuance_EXPIRY_DATE": { "type": "object", "properties": { "nuance_DATE_ABS": { "type": "object", "properties": { "nuance_MONTH": { "type": "number" }, "nuance_YEAR": { "type": "number" } } } }, "required": [ "nuance_DATE_ABS" ] } }, "additionalProperties": false } ``` Used for credit card expiry dates. Sample language: * June twenty fourteen * one two slash two two * 05/21 ## nuance_GENERIC_ORDER ```json { "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "properties": { "nuance_GENERIC_ORDER": { "anyOf": [ { "type": "string", "pattern": "[min|max|succ|prec|penultimate]" }, { "type": "number" } ] } }, "required": [ "nuance_GENERIC_ORDER" ], "additionalProperties": false } ``` This entity extends ORDINAL_NUMBER (1st, 2nd, 3rd, ..., 31st) to represent special cases for expressing minimum, maximum, previous, successive, and so on. Sample language: * first * latest * second * thirty first ## nuance_GLOBAL ```json { "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "properties": { "nuance_GLOBAL": { "type": "string", "pattern": "[help|repeat]" } }, "required": [ "nuance_GLOBAL" ], "additionalProperties": false } ``` Generic commands for navigating a voice system. Sample language: * go back * sign in * reset * cancel * log off ## nuance_NUMBER ```json { "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "properties": { "nuance_NUMBER": { "type": "object", "properties": { "oneOf": [{ "nuance_CARDINAL_NUMBER": { "anyOf": [{ "type": "number" }, { "type": "string" } ] } }, { "nuance_DOUBLE": { "anyOf": [{ "type": "number" }, { "type": "string" } ] } } ] } } }, "additionalProperties": false } ``` Represents a number (integer, fraction, or decimal point). Numbers can be described in natural speech up to and including a million. Choose nuance_NUMBER instead of nuance_CARDINAL_NUMBER or nuance_DOUBLE for numerical entities that can be whole numbers, a fraction, or include a decimal point. Sample language: * twenty seven * four and a half * 49 ## nuance_ORDINAL_NUMBER ```json { "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "properties": { "nuance_ORDINAL_NUMBER": { "type": "number" } }, "required": [ "nuance_ORDINAL_NUMBER" ], "additionalProperties": false } ``` Number that defines a position in a series. Handles all values up until 31st. Sample language: * second * tenth * thirteenth * 5th ### Numeric value range <= 31st (since this has been used mostly for the day of the month. Some languages, such as Russian, have bigger coverage.) ## nuance_QUANTITY ```json { "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "properties": { "nuance_QUANTITY": { "type": "object", "properties": { "oneOf": [{ "nuance_QUANTITY_ABS": { "type": "object", "properties": { "nuance_NUMBER": { "type": "number" } } } }, { "nuance_QUANTITY_REL": { "type": "object", "properties": { "nuance_MODIFIER": { "type": "string", "pattern": "[GT|LT|GE|LE|EQ|INC|NONE|SOME|LOTS]" }, "nuance_QUANTITY_ABS": { "type": "object", "properties": { "nuance_NUMBER": { "type": "number" } } } }, "required": "nuance_MODIFIER" } } ] } } }, "additionalProperties": false } ``` Quantity of a particular item. Can be relative (for example, greater than nine, < 100, some, lots.) or absolute (for example, ten, 20). Note that QUANTITY_REL does not have built-in grammars. Sample language: * more than five * a lot * 10 * at least ten * > 25 * minimum 16 ### Numeric value range <= 99,999,999 (for nuance_QUANTITY_REL) ## nuance_QUANTITY_RANGE Expresses a range of quantity. Used to annotate samples. For example, "less than ten" gives this response (formatted as JSON):
{
  "nuance_MODIFIER": "LT",
  "nuance_QUANTITY_ABS": {
    "nuance_NUMBER": 10
  }
}
## nuance_TEMPERATURE ```json { "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "properties": { "nuance_TEMPERATURE": { "type": "object", "properties": { "nuance_UNIT": { "type": "string", "pattern": "[C|F|K]" }, "nuance_NUMBER": { "type": "number" } }, "required": [ "nuance_NUMBER" ] } }, "additionalProperties": false } ``` Temperature as expressed in degrees Celsius or Fahrenheit. Temperature can be expressed as a whole number or a floating point value. Sample language: * 23 degrees Celsius * eighteen point five degrees Fahrenheit * 28°C * 115°F ### Numeric value range * Up to 4 digits (<= 9,999) for whole numbers * For the whole part and decimal part in decimal-point numbers: <= 99,999,999 * For fractions: Denominators up to tenth

Dialog predefined entities

Mix.nlu adds a default set of entities to simplify your Mix.dialog applications. These dialog entities are isA entities that refer to predefined entities. Dialog entities have shorter, more descriptive names than predefined entities. This can make it easier to develop and maintain your Mix.dialog application while taking advantage of the convenience of predefined entities.

For example, DATE is a dialog predefined entity that is defined as an isA entity for nuance_CALENDARX. If your Mix.dialog application processes dates, use the DATE entity instead of nuance_CALENDARX.

Like the predefined entities prefaced with nuance_, you cannot rename dialog predefined entities, delete them, or edit them.

Dialog entities appear in the Predefined Entities section of the Entities area. Mix adds them when you create your project.

This table briefly describes the purpose of each dialog predefined entity.

Dialog entity isA predefined entity Description
DATE nuance_CALENDARX Calendar date
TIME nuance_CALENDARX Time of day
YES_NO nuance_BOOLEAN Yes or no

Note: The following dialog entities are deprecated and, therefore, may appear in the Custom Entities list. These dialog entities can be edited, renamed, and deleted.

Dialog entity isA predefined entity Description
CC_EXP_DATE nuance_EXPIRY_DATE Credit card expiry date
CREDIT_CARD nuance_CARDINAL_NUMBER Credit card number
CURRENCY nuance_AMOUNT Monetary amount
DIGITS nuance_CARDINAL_NUMBER String of digits
NATURAL_NUMBER nuance_CARDINAL_NUMBER Round number with no decimal point
PHONE nuance_CARDINAL_NUMBER Telephone number
SSN nuance_CARDINAL_NUMBER Social Security Number
ZIP_CODE nuance_CARDINAL_NUMBER Postal zip code

Language support

The Nuance Mix Platform offers a growing number of languages. To determine the languages (locales) available to your project, go to the Mix.Dashboard, select your project, and click the Targets tab. For more information, see Build resources.

For the complete list of supported languages, see Languages.

Change log

2020-06-11

2020-05-04

2020-03-31

2020-02-19

2020-01-22

2019-12-18

2019-12-02

2019-11-15

Below are changes made to the Mix.nlu documentation since the initial Beta release: