Specifications include, but are not limited to: The Washington State Department of Corrections (“Department” or “DOC”) is initiating this Request for Information (“RFI”) to obtain information about Rules Engine software (“Vendors”) and the services they provide customers to configure, test, implement, support and maintain the Rules Engine. The existing OMNI sentencing calculation module is outdated. The Sentence Structure and Time Accounting (SSTA) module, which is one of 53 functions within OMNI, is being used on a limited basis. As a result, all tolling calculations are presently done by hand and includes hundreds of independent quantifications that must be checked several times to decrease the risk of human error. The sentencing calculation part of the SSTA module must be updated with a COTS Rules Engine solution that is not only accurate, reliable, configurable, auditable, and scalable, but also adaptable to current and future state legislative and judicial sentencing requirements. The Department’s current plan is to review responses and then select Vendors to inquire more about their Rules Engine and provide them the opportunity to demonstrate their software. The Department will provide a scenario(s) which are representative of the complexity involved with sentence calculation in the State of Washington. When adequate information is available, the Department may proceed with contracting with the Vendor that bests meets DOC’s requirements. This project will procure a Rules Engine for sentence calculation and take the necessary steps to implement and integrate the Rules Engine into the Offender Management architecture as required. The DOC’s long-term strategy is to fully replace functionality within OMNI and modernize the electronic management processes for individuals under our jurisdiction. Purchasing and implementing this Rules Engine is an iterative step in this strategy. . Before DOC can execute a contract to procure the Rules Engine solution, DOC must initiate a Security Design Review (SDR) with the State Office of Cybersecurity (OCS). This will require the Rules Engine Vendor to provide the engineering expertise to work with DOC to fill out an exhaustive Checklist of information related to the security of the solution. It is not expected that final details will be available before Contract Execution but that details known at that time be documented in the SDR Checklist. Before the Rules Engine can be used in production, DOC must receive an Approved SDR from OCS. Requirement: Prior to and after contract execution, Rules Engine Vendor will provide a named Engineer who will attend meetings and provide timely written responses and/or diagrams for SDR Checklist items and action items until the Office of Cyber Security provides an Approval for the project’s SDR Checklist.. The Rules Engine language must be “friendly” for technical programmers as well as business staff . The Rules Engine should enable users to create a glossary of terms that can be used by the authors throughout the application . The Rules Engine must have succinct ways to input and maintain large groups of rules . The Rules Engine tables should not be limited to single-value numeric return values and have the flexibility to return multiple values . The Rules Engine must support lists for dependent rule chains . The Rules Engine must have a clear and succinct way to input and maintain relative weightings for many different factors contributing to a decision threshold . The Rules Engine should enable business users to enter a rule of any level of complexity through a web-based environment . The Rules Engine should enable rule authors to track and report the most significant factors in a decision . The Rules Engine should not require training business users in programming syntax to create/modify rules . The Rules Engine editing environment must be easily customized to match the look and feel of other editors that business users are familiar with . The Rules Engine should enable business users to be constrained in their choices to enforce safe editing of the rules and to avoid flooding them with too many choices . The Rules Engine should version changes made through the business user editor . Access to the Rules Engine editing environment should be controlled through authorization systems and different views of the rules given to users based on their role and security level
