Terms of Use

The following terms govern use of the HunchLab system and responsibilities of the Client and Azavea, Inc. (Azavea).

General Terms

  • HunchLab will be hosted in Azavea’s secure Amazon Web Services cloud infrastructure with data stored only in the AWS region selected by the client.
  • The Client’s users will access the application from modern web browsers that support secure connections as specified in the application requirements provided in this document.
  • HunchLab pricing is determined by the population of the jurisdiction served. Azavea reserves the right to renegotiate pricing if population changes exceed typical growth rates, for example in the case of annexation of an area with a substantial population. Azavea will inspect the population of the jurisdiction once a year.
  • Azavea will not utilize the Client’s data for any purpose other than to provide the HunchLab service.
  • Azavea will purge the Client’s data from HunchLab upon request.
  • The annual subscription period will begin when HunchLab is made available to the Client’s staff and sufficient data has been loaded to generate missions.
  • Azavea suggests that the Client limit their configuration to 5-10 event models. Azavea reserves the right to limit model counts if model building becomes cost prohibitive due to increases in the number of models requested. The threshold at which the count will be limited is dependent on the size of jurisdiction and volume of covariate data included in the model. We have not run into this issue with clients so far.
  • Azavea reserves the right to prohibit the Client from using HunchLab to model any type of event deemed to be inappropriate for modeling. This includes, but is not limited to, event types or data sources that are subject to bias in the modeling, reinforce bias in or are not preventable by enforcement, or are non-performant in modeling. For example, it is inappropriate to model drug crimes for use in patrol allocations using crime reports due to enforcement biases.
  • The Client agrees to provide access to key event data fields in an open format for a five-year historical period – either in a specified CSV or in a similar, accessible format that Azavea can transform into such a CSV (such as an ODBC connection).
  • While Azavea can make guarantees about uptime of the HunchLab application and missions, the responsibility of uptime of the data integration is held by the party that manages the data integration.
  • If Azavea does not manage the data integration, the Client agrees to maintain a data connection that provides at least daily updates to the database.

System Requirements

Hardware Requirements

The HunchLab application is hosted as a multi-tenant Software-as-a-Service (SaaS) application within the AWS infrastructure. Azavea will manage the hosting infrastructure, security updates, and 2nd tier support. This cloud-based approach enables HunchLab to leverage significant amounts of computing power in an elastic manner, a critical requirement for providing the advanced statistical algorithms the system employs. Replicating a similar environment on-premise would entail a substantial outlay of capital to provide servers that are utilized only in bursts. To provide a secure application, we have consulted the FBI’s CJIS guidelines to apply as many guidelines as possible in designing our system architecture, including risk mitigation techniques such as encrypting data connections and optional 2-factor authentication.

The application requires network connectivity from the user to the HunchLab service. Bandwidth requirements are modest, as most application assets are cached locally in the browser.

HunchLab 2.0 is hosted within the Amazon Web Services (AWS) infrastructure. AWS provides best-of-breed security and flexibility for building robust and secure SaaS applications.

HunchLab’s yearly subscription includes application hosting, updates (fixes and new functionality within the place-based module of HunchLab 2.0), 2nd tier support, and ongoing training resources. This pricing model allows unlimited users and devices to access the application. All support services are coordinated and provided from Azavea’s Philadelphia office and will include incident-based and troubleshooting support services by experienced Azavea staff through e-mail or phone during business hours, Monday to Friday, 9am – 5pm, EST (exclusive of designated US federal holidays). Additional support options outside of business hours are available for discussion as needed.

Azavea develops HunchLab through an agile Scrum methodology whereby work is planned in 2-week increments. This structure enables us to quickly develop iterative improvements to the application. New functionality and any necessary operating system updates or patches are deployed on a schedule designed to minimize downtime. For instance, most software updates result in about 0 – 15 minutes of downtime. System updates require no work from the Client as Azavea staff manages the deployment process. The application is hosted as a multi-tenant application, so an update by Azavea for the US hosting environment will update all organizations hosted within that environment simultaneously.

The Client is expected to continue to maintain modern, up-to-date web browsers on the devices that will be accessing the system. More information about our browser support policy is provided below.

Database Requirements

HunchLab does not require the Client to have any particular database available. HunchLab does require event data (crimes or calls for service records) to already be geocoded with basic attribute data such as the date and time of the event (or time range), event classification, unique identifier, etc. More information about the data interface requirements is in section 4.

Data Integration Requirements

In a production environment, HunchLab will mirror authoritative data repositories, such as CAD and RMS systems. The manner in which this data is transferred to HunchLab varies from client to client. A typical process will consist of transferring records to HunchLab as an extension of existing crime mapping and analysis Extract, Transform, Load (ETL) processes. For example, this might be an extract process used to get data out of an RMS for crime mapping purposes.

Alternatively, Azavea can configure an upload process that draws data from an Open Database Connectivity (ODBC) connection to a read-only database view to fetch data that has changed since the last import was conducted. Most agencies schedule this import process on a daily or hourly basis, but HunchLab can also be configured to import changes on a more frequent basis such as every few minutes. Ideally data is provided for a 5-year historic period to allow robust predictive modeling.

Event data (crimes, calls for service, etc.) are transferred to HunchLab in a simple CSV format via a Representational State Transfer (or RESTful) HTTP Application Programming Interface (API) endpoint. A RESTful API is a framework that allows one to push and pull data to and from a system in a simple and secure manner. The Client can directly push data into this API endpoint or Azavea can support its use. CSV uploads contain column headers and basic attribute values such as the location and time of an event. Formatted CSV files can also be uploaded directly via the HunchLab administrative UI.

Alternatively, Azavea can fetch data from other RESTful APIs such as those provided by ArcGIS Server. If the endpoint is available via the Internet (with proper authentication), then no on premise utility needs to be configured as HunchLab can directly fetch updates. If the endpoint is behind a firewall, then the extraction process would be setup within the Client’s environment and push updates to the HunchLab server.

Access Requirements

Staff access HunchLab through a web-browser. As an advanced web-application, HunchLab supports the following major desktop web-browsers and contemporary operating systems:

  • Chrome (last two versions)
    • Windows XP or newer
    • Mac OS
    • Linux
  • Firefox (last two rapid release versions and supported extended release versions)
    • Windows XP or newer
    • Mac OS
    • Linux
  • Internet Explorer / Edge (last two versions; IE 11 and Edge 14 as of April 2017)
    • Windows 7 or newer

Note: Window Vista and older Windows operating systems do not support secure versions of the TLS protocol (1.2+) within Internet Explorer. To support these older versions of Windows, we recommend the use of Chrome or Firefox (both free for installation) on these machines since they do support these newer versions of TLS.

We also support the following major mobile browsers:

  • Safari
    • iOS 9 or newer
  • Chrome (current version)
    • Android

In all cases, the default HunchLab configuration requires operating systems and browsers that support Transport Layer Security version 1.2. This requirement is to prevent known attacks against SSL traffic that impact TLS v1.0 and older protocols. Our supported browsers provide the correct version of TLS either automatically or with minor configuration changes (such as checking a box within the settings panel). If an agency is unable to support TLS 1.2 connections, it may necessitate the creation of a separate access point to the HunchLab system, which can be discussed on a case-by-case basis.

For the Sidekick interface of HunchLab and the Dosage Tracker, we need access to the GPS location of the device. This information is accessed through the HTML5 geolocation API that is supported by all browsers listed above. Access to the GPS location on a specific device depends on the configuration of the device itself. For instance, nearly all tablets and smartphones with GPS chips provide access to location via this HTML5 API. Mobile data terminals may or may not have access to this feed depending on their specific configuration.

Support and Service Level Agreement

Service Level

During the Term of the HunchLab subscription, Azavea shall make commercially reasonable efforts to maintain the operation and availability of the application to the Customer at least 99.9% of the time as measured over the course of a calendar month. This SLA level corresponds with approximately 44 minutes of unplanned downtime per month. Scheduled downtime will not be included in these calculations but generally will amount to less than 1 hour per month. If the application does not meet the SLA, the Customer may request Service Credit as described below. This SLA states the Customer’s sole and exclusive remedy for any failure by Azavea to provide the service.

Definitions

The following definitions shall apply to the SLA:

  • “Downtime” means that the application and API are unavailable as measured by availability and a valid response being received from an external monitoring service maintained by Azavea.
  • “Downtime Period” means a period of two consecutive minutes of Downtime. Intermittent Downtime for a period of less than two minutes will not be counted towards any Downtime Periods.
  • “Scheduled Downtime” means those times where Azavea notifies Customer of periods of Downtime at least five calendar days prior to the commencement of such Downtime. There will be no more than eighteen hours of Scheduled Downtime per calendar year. Scheduled Downtime is not considered Downtime for purposes of this SLA, and will not be counted towards any Downtime Periods.
  • “Monthly Uptime Percentage” means total number of minutes in a calendar month minus the number of minutes of Downtime suffered from all Downtime Periods in a calendar month, divided by the total number of minutes in a calendar month. For purposes of the Server Uptime Level, a lapse in server availability is calculated from the time Azavea detects or otherwise becomes aware of an incidence of a service interruption and ending when the service is restored, regardless of where the outage originated.
  • “Service Credit” means the following:
Monthly Uptime PercentageService Credit added to the end of the Service Term,
at no charge to Customer
< 99.9% and ≥ 95.0%1 additional week added to the subscription
< 95.0%2 additional weeks added to the subscription

In order to receive any of the Service Credits described above, Customer must notify Azavea within thirty days from the time Customer becomes eligible to receive a Service Credit. Failure to comply with this requirement will forfeit Customer’s right to receive a Service Credit.

Service Credits

Service Credits may not be exchanged for, or converted to, monetary amounts.

Monitoring

Azavea shall maintain a monitoring service external to the data center housing the equipment supporting the application and shall monitor the service with reasonable frequency and duration.

Scheduled Downtime

Azavea shall provide at least 5 calendar days or more notice to the Project Contact and IT Contact if there is planned downtime. Tasks performed during planned downtime may include:

  • Application of security patches
  • Upgrades to software
  • Updates to the database
  • Other activities as necessary to maintain the integrity, stability and performance of the web services.

SLA Exclusions

The SLA does not apply to unavailability or any performance issues:

  • (i) caused by factors outside of Azavea’s reasonable control including without limitation, acts of God, acts of government, flood, fire, earthquakes, civil unrest, acts of terror, strikes or other labor problems.; or
  • (ii) caused by a malicious internet attack including a denial of service attack; or
  • (iii) that resulted from Customer’s equipment or activity or third party equipment or activity, or both (not within the primary control of Azavea)

Changes to Service

Azavea may make commercially reasonable modifications to the Service, or particular components of the Service, from time to time. Azavea will use commercially reasonable efforts to notify Customer of such changes.

Security Incident Management

In the event of a suspected or confirmed security breach, Azavea will proactively notify the Project Contact and Security Contact (these roles are defined in the Implementation Narrative on page 17) of the breach in a timely manner as specified in CJIS v5.3 section 5.3.2.

Customer Support

Azavea shall use commercially reasonable efforts to provide the following support services for customers:

  • Provide telephone, web and/or email support to customers during normal business hours (9am – 6pm, Eastern Time); and
  • Respond to customer support queries regarding within one to five business days, depending on the severity of the issue.