We use Smooch to supply the web, Telegram, Messenger, and LINE channels. This is the preferred and most complete FIDIC chatbot.
For the Smooch version of FIDICbot we are using smooch.io as the multi-channel integration platform so that we can have a single bot app that is accessed through several of the most important messenger channels (Smooch offers a web app as well as messenging through Facebook Messenger, Twitter Telegram, WeChat, LINE, Viber, Slack in an interactive mode and SMS via Twilio). Dexter seems to have a more advanced, but more complicated, offering. We deployed the app to Heroku and have the files on GitHub (the set-up is well explained by EstherBot on Github).
Smooch uses standard formats for messages integrated into SMS, Messenger, Telegram, etc. which canot be adjusted (apart from some minor adjustments for things like the avatar that is displayed and colours). One is therefore reduced to having the bot work with the lowest common denominator, which is Messenger where Smooch limits the number of characters in the message and the number of buttons for links (i.e., Smooch uses Messenger's Structured Message Generic Template). So we have to break up long clauses into several parts and for a long list of link buttons, have separate messages (saying "....") each with three link buttons.
FIDIC1, the International Federation of Consulting Engineers, publishes standard forms of contracts for works projects and professional services. The most widely used are:
Remembering that a bot must work on every media ranging from small smartphones to full-screen computer monitors and TVs, we need a simple and short way to specify the type of search in a FIDIC Contract. Currently we use a one-letter code for the contract (e.g. "c1" for the Construction Contract, 1st Edition 1999). WolframAlpha does something similar, but as an app and not as a bot.
Why? Having a one-letter contract code allows us to have clauses from the various FIDIC contracts displayed together (rather then attempting to somehow integrate separate bots for each contract). Having the various contracts allows comparisons of clauses (this will be implemented at some stage).
Search codes also serve as shotcuts. If one submits a clause number or a keyword without a code, the bot offers two options: a) a default scope (a search in the Construction Contract 1st Ed 1999 index); b) select a contract code. But if one types in a contract code (e.g., "c1" for Construction Contract) before a keyword (e.g., "c payment") one searches the Construction Contract 1st Ed 1999 index immediately.
Contract codes are stored so once a contract is selected, subsequent searches use the code without the need to submit a code for each search. For instance, with "c1" set as the contract code for the Construction Contract 1st Ed 1999, one can then submit say 1.2 to display Clause 1.2. Submiting "payment" will search the Construction Contract's index for the word 'payment'.
We like the idea of not simply a search for a clause within all clauses using a keyword or keywords but a more intelligent search that takes a topic scope (e.g. adjudication or anti-corruption) and allows clauses to be selected that refer to the topic. Ultimately artificial intelligence could be used here, even with user feedback, to guide the selection of clauses that are relevant for a given topic. We have tested this approach using two- and three-character search codes combined with indexes for specific topics. The results are unconvincing. Simple indexes to identify contract clauses that relate to specific issues concerning, for example, corruption do not work.
The default keyword search is in a contract's index. For the indexes we use expanded indexes. For works contracts, they are based on the official FIDIC index that is published in the works contracts. For services agreements we use our own indexes.
We feel that having text entries is cumbersome. After all we are dealing with standard forms of contracts with 90-odd percent of text the same between some contracts. So we have many standard words apart for the defined terms. We use buttons as prompts as well as text.
One could envisage a mix of the two - a button prompt enters text in the text entry so that the text could be modified. We might have a look at this one day.
For searches, we feel that on a small screen it is impractical to have a running list of the clauses that contain a certain keyword. One can do it but we feel it is better to limit the number of clauses that are displayed using a clause type and reference with a keyword (and/or maybe modifiable keywords).
A multi-word free-text search using some sort of algorithm à la Google et al may be interesting possibility, along with artificial intelligence. The latter would probably be overkill for searches in an index but maybe interesting for topic-clause scopes, especially if user-feedback is incorporated. That is enough for the speculation. Now the codes.
The FIDICbot currently uses the codes given below. When we say "clause" we mean a clause or a sub-clause in the General Conditions of each contract. The annexed dispute adjudication agreement (DAA) and the procedural rules are included, and for services agreements, the appendices are included. Suggested clauses published by FIDIC for Particular Conditions may be added at a later stage.
Codes are chosen that can be easily typed and understood by word recognition by most mobile phone messenger clients. There are two types of codes, namely:
Here are some examples of searches using contract codes:
Most chatbot messenger platforms provide buttons. In some cases it is necessary however to say or type in a code or keyword. These can be in upper or lower case.
There are some standard prompt keywords (we do not want too many and they must be short):
The current limitations in order of ease of correcting at some stage (we wont say which we plan to sort out) are:
Coding the text of the contracts is obviously a simple task. As with our other visualisation strategy for complex, structured documents (namely charts, and in the case of FIDIC contracts, FIDIC Charts) we are using json files instead of a database (because for charts we want an offline app). We have considerable experience for the charts in manipulating and combining json files. We can build upon this expertise for the bots, and ideally use the same json base files, but with different manipulations.
The pilot phase will tell us if large json files lead to the bot being too slow.
While the FIDIC contracts could be construed as being in the public domain owing to their legal status and the way they are proposed to users, we firmly believe that the General Conditions are copyrighted, as indicated by FIDIC. Users are invited by FIDIC to modify other parts of the published contracts (except the Dispute Adjudication Agreement) so these parts are not subject copyright.
FIDIC's general principle in according the right to a other parties to publish text from General Conditions is that the length of excepts should be relatively short and there should be no realistically feasible way to combine excepts to produce the complete, authentic text. The bot approach clearly meets these conditions.
Bots seem to be taking off after a long gestation because smartphones are becoming the dominant media for Internet activity, especially for tracking, customer feedback, transactions, and payments. The messaging platforms feel that they can offer developers and indeed normal users ways to integrate advanced capabilities (voice, artificial intelligence, payments, etc.) across all media using bots instead of apps.
Currently we use Smooch with Heroku and plan to shortly replace Heroku with our own node.js cloud server (for more flexibility for our specific needs). We use Express for scripting. Some major publishers have said that they will take the same approach.
We plan to make the Smooch version of FIDICbot available publically on Github. The bot is deployed to Heroku with channel integration by Smooch.
If you are interested in exploring text-prompt bots for advanced user interfaces to complex, structured documentation, please contact Peter Boswell. Peter is the former FIDIC General Manager and is now working as a consultant with Bricad Associates, see peterboswell.com.
Bricad Associates Sàrl, is based in Coppet on the outskirts of Geneva, Switzerland (website).
Bricad groups all its management information and user support platforms under Bricad.online.