Request for Proposals

Yes, apologies for the typo. The source code is available at codeberg.org/LACI.

The DocumentChange entity will either be implemented as a Drupal Entity or a Drupal node bundle (“Content Type”), and as such, will be given a UUID by the underlying Drupal framework already.

The notification subsystem is already in place, please see the current codebase. The creation of the payload, which is compiled in \Drupal\laci_core\Service\LaciReporter, will need to be modified to conform to the requirements of Milestone 2.

Only a “Change-eligible” Authority check will need to create an AuthorityError record. There are Authority checks that can be triggered manually that are not Change-eligible; these are typically all Authority checks other than are done on a scheduled basis in \Drupal\laci_core\Service\LaciScheduler. The system currently does differentiate between transient and permanent errors, although admittedly imperfectly to date. Transient errors are typically connection errors such as timeouts, many SSL issues, and HTTP 5xx responses. Permanent errors would be connection errors such as “host not found”, any HTTP 3xx response, and any HTTP 4xx response.

For that part of the specification, as well as anywhere else that has a question mark or words like “probably” or “should”, we’re looking for a proposal that fits the general intent of the description. Collapsing such detail from the AuthoritiesReview section of the Document view page, or detail on the Authority view page, is intended to enhance the user experience on those pages. If you can figure out how to make filtering work in a usable fashion, as well as any other proposed enhancement, that would be great.

The parser should support as many sub-levels (not just three) as possible, as well as recognizing full chapter or part references.

Addressing each of those separately: (1) while the example in the RFP implied word-level granularity, we do need to know about character-level changes, especially punctuation. (2) ignoring whitespace is probably appropriate. (3) the code doesn’t need to try to analyze the legal implications of any changes.

Yes, this should be a LACI Drupal module, consistent with the existing LACI UI/UX scheme, and consistent with existing roles and permissions. The redline/diff functionality should not allow a user to perform functions in its Drupal application with any expanded permissions.

The tool should auto-generate a candidate XPath expression and present it to the viewer as an editable field before saving. It should be possible to edit the field without using the interactive XPath element selector.

That’s a good question and it addresses an under-specification of Milestone 5. The XPath selection tool can but does not have to use browser inspection tools. In fact, the representation of a web page that LACI retrieves when it checks the page is the page source. No javascript is executed to render any DOM elements. This does imply that some pages are not possible to monitor with LACI if their entire content is rendered with javascript; this is the case today.

Any XPath expression that LACI uses to extract part of a page for monitoring purposes will work on the page source, not on any asynchronous loaded content, or any shadow DOM structures.

This tool is being used by non-technical legal personnel (attorneys, paralegals, and other staff).Having an immediate visual indication of a selection (and an updated selection)  seems like the most usable way to accomplish this milestone. However, if you have an approach that will work for this purpose that does not require immediate visual indication of a selection (and an updated selection) then please describe the approach in detail so we can evaluate it appropriately.

We don’t anticipate a need to update the parser for HTML web pages and general PDF documents. For statutes and rules that may be published in PDF documents, we currently use a PHP parser to extract text from those documents; we don’t currently need a tool that will also use OCR to process a scanned document, nor do we currently see a need to handle embedded tables or images.

If you have ideas for improvements that you’d like to include in your bid, please consider breaking the cost of those out separately so that, if necessary, we can compare your cost of implementing the functionality required by the RFP to other bids that don’t include additional improvements.

Thank you for this question. The Request is for a fixed price proposal for the work described, so as such, that information is not relevant to a proposal.

Thank you for this question. The Request is for a fixed price proposal for the work described, not an annual budget.

At this time, I think we do not see any impediments with working with an organization that has personnel outside of the United States. You should be aware of the following:

• All payments will be in US Dollars to an entity based in the United States.
• Any disputes would be handled by courts in the state of Texas.
• The contract would be interpreted under Texas law.
• We would need to have a contact on your side who would be available, on request and/or on a regular basis, to resolve issues during our business hours.

All work will be performed remotely and coordinated through our existing GIT repositories.

The current deadline for submissions is March 15, 2025 as outlined in the RFP document.

In the interest of fairness to all parties, we will not provide an extension. Should we find a need to re-issue the RFP we will do so with a new deadline.

The submission mode for the RFP is outlined in the “Preferred Method of Contact” section of the RFP. Please send a proposal via email by the deadline.

[Phase] 3 is meant to only apply to statutes, regulations, and court rules. It is not meant to apply to general web pages. Such statutes, regulations, and rules MAY be retrieved from web pages but are not always. In the current version of LACI, these Authorities will be of [sub]types “Federal Code”, “Federal Regulation”, “Federal Rules of Civil Procedure”, “Federal Rules of Evidence”, “Texas Statute”, “Texas Administrative Code”, “Texas Rules of Civil Procedure”, and “Texas Rules of Evidence”.

[Phase] 5 only applies to generic web pages being monitored. These Authorities are of type “General Website” and do not overlap with the Authorities covered in [Phase] 3, so technically work can happen on both in parallel.

Drupal 11 is already available, see https://www.drupal.org/about/core/policies/core-release-cycles/release-process-overview. We would prefer any new code to be compatible with Drupal 11, but we don’t expect to test LACI in a Drupal 11 environment as part of this project. It would be acceptable for you to develop code in a Drupal 11 environment; however, deliverables must also be able to execute correctly in our production Drupal 10 environment to be accepted.

Vendor selection will be finalized once we’ve signed a contract with a vendor. We would like that to take place in time to start this development in June 2025.