Inference
​Logic rules are the building blocks of an eXvisory product support chatbot. As an eXvisory developer you configure these rules and fit them into the editor's fault containment hierarchy to model expert diagnostic procedures for your product. This creates a deep logic network. Inference is the route eXvisory then takes through the deep logic network, which you need to understand because it determines the order in which your chatbot asks questions and presents its explanations and conclusions.
Let's look at inference within our sample mobile device troubleshooter.
In the fault containment hierarchy click on the network node (it's below the device root node in the hierarchy) to select and zoom in on it.
Use the mouse wheel to zoom out until all the nodes are visible (but the network fault group is still selected).
On the right hand side of the editor select the Eliminators tab.
The editor should look like the screenshot below.
As we learned in Logic rules the fault containment hierarchy contains (green) fault groups and (blue) faults. For mobile device troubleshooting the hierarchy is saying that all faults are device faults, but that device faults can be further divided into network, connectivity, app, interface and power faults (ignoring the too small to read nodes), and network faults can be divided into Internet and cell network - and so on, leading from left-to-right to narrower and narrower groups of faults, until we reach specific faults. The top-to-bottom ordering is more about frequency or likelihood of faults. The most likely device sub-fault is the network fault group, then connectivity, then app, etc.
Inference proceeds through the hierarchy first from left-to-right (to eliminate or scope the greatest number of faults first) and then from top-to-bottom (to investigate more common faults first).
Because the fundamental thought process behind expert fault diagnosis is the process of elimination. Expert troubleshooters (and famous fictional detectives) at every stage of an investigation ask questions designed to eliminate the most remaining suspects. So when you look at the fault containment hierarchy you should ask yourself - what could I ask that would eliminate the network from suspicion? You can't eliminate the root device because it represents all faults.
​Eliminators do most of the routing in eXvisory deep logic networks.
If you look at the network eliminator in the JSON editor (see screenshot above) you'll see it evaluates the network symptom test, which we looked at as our example synthetic test. This test evaluates two other tests that use multiple choice questions to get problem symptoms and subsymptoms, and combines their results to decide whether the symptoms and subsymptoms could be network-related. If not, the network fault group is ELIMINATED (along with all its highlighted sub-faults) and inference proceeds to the next connectivity fault group (going top-to-bottom), otherwise the eliminator returns UNKNOWN and inference proceeds to the first sub-fault of network (going left-to-right), which is the internet fault group.
Click on the internet node to select and zoom in on it.
Use the mouse wheel to zoom out until all the nodes are visible (but the internet fault group is still selected).
On the right hand side of the editor select the Eliminators tab and use the pulldown menus to select the activity eliminator variant.
The editor should look like the screenshot below.
Eliminators evaluate to ELIMINATED, SCOPED or UNKNOWN.
The internet eliminator (see screenshot above) illustrates a SCOPED result. There are actually two internet eliminators and this is the activity variant. The conditions field evaluates two tests. The first condition is known as a variant condition because its result clause is a logic expression (not a variable). If the result clause evaluates as TRUE this eliminator variant is evaluated. Only one eliminator variant can be evaluated. So, looking at the first (variant) condition, the internet activity eliminator is evaluated if the network type test returns the value "internet". The second test evaluates an internet activity test that returns TRUE if there is evidence of Internet activity. Finally, the eliminator result is ELIMINATED if there is Internet activity, otherwise it is SCOPED.
SCOPED means that the tests in the conditions field show that the fault must be somewhere within the internet fault group or any of its sub-faults. Therefore it cannot be in any other fault groups. All the other fault groups (except for device and network, which include internet faults) are automatically ELIMINATED and inference will subsequently ignore them, avoiding lots of irrelevant questions.
SCOPING automatically eliminates fault groups outside the scoped fault group and its sub-faults but it does not eliminate faults. If inference can still reach faults (i.e. intervening fault groups on the inference 'route' have not been eliminated) they will still evaluated. This is useful for 'if all else fails try this' diagnostics.
Inference through fault groups is mainly controlled by eliminators (see above).
When inference reaches a fault group it evaluates its eliminator(s) to see if the fault group can be ELIMINATED or SCOPED. If the fault group is ELIMINATED inference proceeds to its next sibling in the hierarchy (from top-to-bottom) or returns to its parent fault group. If the fault group is SCOPED then all unrelated fault groups are ELIMINATED.
If not ELIMINATED by its eliminator(s) the fault group then evaluates its child faults (faults or fault groups) in order. If any child fault evaluates to FOUND or SCOPED the fault group evaluates to FOUND or SCOPED (respectively) and inference returns to its parent. This has the consequence that FOUND or SCOPED faults deep in the network cause fault group evaluation to ripple back up to the root fault group, which ends inference. The difference is that FOUND faults do not have children (so this rippling back up to the root happens immediately) while SCOPED fault groups continue to evaluate their children.
If no child faults are FOUND or SCOPED the fault group evaluates to UNKNOWN and inference returns to its parent. Fault groups evaluate to ELIMINATED, SCOPED, FOUND or UNKNOWN.
Faults evaluate to FOUND or ELIMINATED and are simple from an inference standpoint.
If inference reaches a fault via the fault group containment hierarchy (see above) it typically evaluates and combines tests to decide whether the fault is FOUND or ELIMINATED and returns the result to its parent fault group. As we saw in fault groups returning FOUND causes inference to quickly ripple back up the fault containment hierarchy to the root, which has the side effect of not evaluating any other (non-ancestor) fault groups, effectively eliminating them.
