Philosophy
The preceding Concepts sections explain how eXvisory dev works. This section is more about why it works the way it does. The aim is to identify the critical list of design goals (our 'philosophy') you need to bear in mind to succeed in creating a scalable, maintainable and intelligent chatbot.
This section is a work-in-progress.
​Constrained complexity - simple rules to build complex chatbots
​General vs specific - general troubleshooting logic in, product specifics out
​Patterns - got a problem, look for a reusable logic pattern
The logic rules you use to assemble an eXvisory deep logic network are deliberately constrained to a palette of as few different rule types as possible (5) with as simple internal logic as possible - optimised for the problem at hand (fault diagnosis by a process of elimination). To build a complex troubleshooter you combine these simple rules into repetitive structures (the fault containment hierarchy). There will always be a temptation to add more expressivity to the logic rule palette, but as rules become more expressive they become more complicated, and combine in more complicated ways - and combinatorial complexity is the bane of building scalable and maintainable logic AIs.
An eXvisory troubleshooting chatbot is not (and should not be) a standalone application. The chatbot ideally acts as a curated guide between the best specific troubleshooting pages on the Internet or an organisation's Intranet. This may mean you will also need to create accompanying web pages. For example, in our pilot mobile device troubleshooter chatbot the logic rules captures how to troubleshoot a device being unable to network because it has been inadvertently left in 'flight mode'. But the specific details of how to tell if the device is in flight mode, which vary between Apple (iOS) and Android devices, are best located in separate web articles - referred to from help resources, often using template logic to direct the user to the article relevant to their specific product. Try to keep eXvisory logic at the level of general concepts and put as much specifics as possible in linked web pages.
Why? Because adding detail into a logic AI makes the logic more brittle (breaks easily) and much harder to scale - which is the ultimate design goal of eXvisory - scalability with maintainability.
It turns out that most fault diagnostic applications share common logic problems, for example how to stop asking a series of questions depending on the answer to an earlier question. You can figure out how to do this yourself using eXvisory logic features (like variants) or you can browse our library of reusable logic patterns.
COMING SOON!
​
