Activation rules

You can use different state activation rules in order to understand requests from clients: patterns and CAILA intents.

When several activation rule types are used together in one script, they are triggered in descending priority: patterns first, then intents.

Rule activation mechanism

The following table illustrates which activation rules are triggered in different combinations of their usage:

This means that if a request triggered a pattern, a transition to the state with this pattern will be made even in the presence of an intent with higher score.

Handling unrecognized requests

In projects which use several activation rule types, do not use the * pattern to match unrecognized requests:

state: CatchAll
    q!: *
    a: You said: {{$request.query}}

This state will trigger on all requests not handled by other patterns, and any existing intents will be ignored, because of the pattern’s higher priority.

Instead, use the noMatch event for requests not supported by the script:

state: CatchAll
    event!: noMatch
    a: You said: {{$request.query}}

Example script

In CAILA, we have defined the intents /pattern and /intent , trained on pattern and intent phrases respectively. Consider the following script:

theme: /

    state: Pattern
        q!: * pattern *
        a: The pattern was triggered.

    state: Intent
        intent!: /pattern
        a: This intent will not be triggered.

    state: Intent2
        intent!: /intent
        a: The intent was triggered.

    state: CatchAll
        event: noMatch
        a: You said: {{$request.query}}

Let’s start the test widget and check which states the following requests will trigger:

Advanced features

If the standard rule activation priority does not fit your needs, define your own logic of processing classification results:

• Use the selectNLUResult handler to change the rule activation mechanism.
• Use the $context.nBest feature when you need to have access to classification results from any part of your script.