Skip to content

Court Bot Design Spec 2

Jump to bottom
Ray Kiddy edited this page Sep 21, 2021 · 3 revisions

To be deleted soon, as all content (IMHO) has been moved into the 'Court Bot Design Spec' document itself.

Overview

This is for the Santa Clara County court system. This courtbot application exists to assist people who need to attend court. It will provide timely reminders that help people remember when they need to be at court. Missing a court date generally adds additional burden to a person who may already be in financial distress, so this tool is aiming to improve the likely chances that a person would show up in court.

Use case

Basic:

  • User provides a phone number and a case number to be alerted for via a web form (or text).
  • User is notified via text - alerting them that court date is imminent. The frequency of notification is constant (ie no user customization)

Nice to have:

  • User may have preferences on when to be notified / and frequency. There will be a limit to the length depending on the data retrieved.
  • User may want to stop notification for the specific case.
  • We may additional provide court location information as part of the text. Links to directions, via car or public transportation.

Proposed Solution

The application will consists of 3 main components as described below:

  • UI frontend
  • Data / REST services
  • Notification service

UI frontend

Minimal frontend is needed for this application. This will need to be hosted somewhere and that the connection is secure.

  • User adds notification by providing data to the frontend.
    • REST:
      • Data is passed to the next layer for add (REST / CREATE )
      • (optional) Data may be validated against Santa Clara county court case data (internal REST)
    • User receives feedback that the information is received and processed.
    • User can be notified whether this is a valid case number or not.

Optional enhancements:

  • User can retrieve notification information and adjust notification frequency
    • REST:
      • Data can be retrieved (REST / GET)
      • Data can be updated. NOTE: phone number + case number combo is the key to the record. (REST / POST)
  • User removes notification by providing data to the frontend. Or as part of the notification to "STOP"
    • REST:
      • Data is passed to the next layer for remove (REST / DELETE)
    • User receives feedback that the information is received and processed.

Technology: We will likely want to host this application as part of the REST services below (to avoid cross site exposure). So if we go with python REST services, we should do Django. If NodeJS services, we can use bootstrap.

Data / REST services

The REST services provided will have a few functions:

  • CREATE/DELETE/GET: function for case number + phone number data.
    • These information will need to be stored in a table.
    • Additional data may be associated with it - such as frequency of notification etc.

Optional:

  • POST: function to updated associated data that are retrievable with case and phone number.

Data

See detailed discussion on data in the original documentation:

  • A database storing case number with a phone number is needed. (REQUESTOR)
    • NOTE: it is possible that multiple phone numbers can be associated with a case, and that multiple case can be associated with one phone number.
  • Optionally, a table storing court calendar data can be made available. (COURT_CAL)
    • table will need to store: case number -> court date / time
    • If this table exists, a job will needs to be setup to ensure data integrity is preserved. In addition, potential uses during detection of change:
      • if case number moved to later dates/closer dates - information can be used to alert to users that date has changed. (Leverage Notification service)
      • if case number no longer exists (ie moved to later dates outside of scanning range? or settled out of court?)- what to alert?
      • if case status changed?
      • etc?

Notification services

The notification service includes all functions to notify the user when a court date is imminent.

  • A script / job / service needs to determine which case needs to be notified base on date criteria
    • This can be calculated via the live court calendar data or against the existing database (COURT_CAL)
    • This calculation might be done via database joins. (REQUESTOR join COURT_CAL on case number & date)
  • This sends a text to the number associated with case that needs to be notified.
  • On sending of a text.
    • (optional) Can be an opportunity to store additional data to indicate notified, or previous status.

Open questions

  • Deployment.
  • Court cases may have multiple hearings - Do we need a function to purge?
  • What do we do when court dates changes? (say if we notified that case is happening in 2 days, then case date change to 5 days later - outside of the range we did not evaluate). This would be confusing to the user.
Clone this wiki locally