Sometimes your capsule should provide the user with default values for prompts or make assumptions about values when they're not provided. For example, say you're building a tip calculator. When the user asks "what's a tip on a $100 bill", your capsule has the total bill amount but still needs the tip percentage. Instead of requiring the user to say the tip percentage or to prompt them every time, you could provide an instantiation strategy that suggests a value when the user hasn't provided one, or provide a default initialization for an input that sets it to a specific default value.
The CheckStatus
action described below requires a receipt
input. If one isn't provided, it uses the last generated receipt as a default.
action (CheckStatus) {
type (RefreshActivity)
collect {
input (receipt) {
type (Receipt)
min (Required)
default-init {
intent {
goal: FindLastReceipt
}
}
}
}
output (Receipt)
}
The default-init
specifies a new intent
, telling Bixby's planner to use the FindLastReceipt
action to provide a Receipt
concept as the default.
If you specify default-init
blocks, Bixby first tries to pass the default-init
intent to find required missing values. If none of them apply to the current request or you haven't provided any, Bixby will move on to consider instantiation strategies. Note that a default-init
block can be functionally equivalent to an instantiation-strategy
, in that they both might return the same result.
Instantiation strategies are selected using match patterns. They have all the common components of any other strategy in Bixby. The main differentiator is the strategy
block, which determines either the values to use or where to get those values in intent
form.
Strategies are stored in the /resources/base
folder of your capsule. Bixby Developer Studio will create these files in the proper location for you if you select "Strategy" as the file type in the Create New File dialog.
You can see another example of instantiation strategies in the Selection Learning sample capsule.
For our tip calculator example, a strategy might look like this:
instantiation-strategy {
id (init-tip-percent-from-dflt-enum)
match {
gratuity.TipPercent (this)
}
strategy {
intent {
value: gratuity.TipPercent(10)
value: gratuity.TipPercent(15)
value: gratuity.TipPercent(18)
value: gratuity.TipPercent(20)
value: gratuity.TipPercent(25)
goal: gratuity.TipPercent
}
}
}
Since this strategy provides more than one possible value for the TipPercent
goal, it will invoke Bixby's Selection Learning to help pick one.
Consider the case when the user makes a query such as: "How is the weather?" The capsule can assume the user is requesting information about their current location. In this example, the instantiation strategy sets the user's current location as a default.
instantiation-strategy {
id (current-location-value)
match: geo.CurrentLocation
strategy {
intent {
value-set: geo.CurrentLocation { $expr($user.currentLocation) }
goal: geo.CurrentLocation
}
}
}
A similar example of location-dependent intelligence could be to choose a currency for a transaction based on the user's locale.
instantiation-strategy {
id (money.Currency_Instantiation)
match {
viv.money.Currency
}
strategy {
intent {
subplan {
value-set {
geo.ISOCountryCode2 {
$expr($user.locale.country)
}
}
goal { viv.money.CurrencyType }
}
goal { viv.money.Currency }
}
}
}
More than one strategy can apply to a given request if more than one pattern matches. In such a case, Bixby will execute all the strategies, and merge all the results they generate.
There is no learning for differentiating between instantiation strategies themselves. As with the tip calculator example above, though, if combining results of multiple strategies results in more options than needed, Selection Learning
will be called to help choose the best options for the user.