poserver/README.md

Server for JD Bot

# tjd-poserver
Server for Protective Order Bot

This is a bot server using the Microsoft Bot Server Framework for NodeJs. It is a bot that will

1. See if it recognizes the user. If so, it will load a userProfile object from a MongoDB instance. If it does not recognize the user
as a returning user, it will prompt the user for some basic profile data and save the user's profile.

2. Ask the user what the user needs, e.g. Family Violence Protective Order, QDRO, Original Answer.

# Value-Add
The societal value proposition for this bot vs. a fill-in-the-blank PDF is that it asks the user for details about what's going on
and then, based on experience, guides the user to the proper legal action (or inaction as the facts and law may be). For example, rather
than ask "Do you want sole managing conservatorship or joint managing conservatorship?" it asks the user about parenting duties, experience
in co-parenting, availability of both parents, etc. and then makes a recommendation. If we're going to replace the lawyers with bots,
the bots have to be smarter than a fill-in-the-blank form.

Rather than ask the user to create a proposal for dividing marital assets, it produces a better proposal than most attorneys
are capable of and does it in about 300 milliseonds.

The commercial value proposition is that it will channel otherwise non-fee-generating, self-represented litigants to the attorneys
who want to subscribe to review more complex documents. The clients will pay a lot less than they would have with full service
representation. The attorneys will make a lot less per client, but will have a lot more clients.

This same model, implemented by others and operating within a more complicated regulatory context, will have a similar effect
on doctors for whom their practice mostly consists of office visits. E.G. my cariologist could be replaced by a bot and a vending machine
that scans insurance cards with only about a weekend's worth of work by a distracted programmer.

# Implementation
It implements a library of dialogs that the user traverses under the guidance of a state machine. It uses Google's geolocation rest service
to validate addresses. It uses recognition rules to determine the type of court and court number from a combination of county and
cause-number inputs. The recognition rules provide for the translation of the court number from a coded value (e.g. "Z" in Dallas County)
to an actual court number (Z = "256th" in Dallas County). If there are no recognition rules for the particular county+cause combination
or if the user insists on typing in an unrecognizable cause number where we do have recognition rules, then the user is prompted
for the type of court and the court designation or number.

# Contextualized Information Gathering
One of the principals behind the bot's design is that people may not want to disclose a ton of personal information right away. For that
reason, it gets started with the barest essential information then asks for more as it needs more. This gives the user an understanding
of why the user is being asked certain questions. As the bot knows more about the user, it asks fewer and fewer questions.

# Remember
This is not just a channel into the human sales force or an order page. It is designed to completely satisfy the legal needs of
about 20% of all litigants. With the implementation of the attorney review channel, this bot will serve the full legal needs
of 25% to 50% of all litigants and free up a huge number of attorneys to go do something useful besides fill out forms.

# External Services Used
1. Google.com to validate street addresses and lookup counties.
2. Stripe.com to handle credit card payments.
3. Authy.com for SMS-based 2FA.
4. Mongodb for document storage.
5. Microsoft Botbuilder API to handle the interaction between the client application and my server code.
6. Microsoft LUIS applications to handle conversational "menu" and navigation intents (e.g. "go back").