Substantive Legal Software Quality: Is Your AI Lawyer Actually a Liability?

1079_Substantive Legal Software Quality A Gathering Storm

Summary
Problem
Method
Results
Takeaways
Abstract

This paper examines the quality crisis in "substantive legal software"—interactive apps that provide legal guidance and document automation. It identifies a lack of rigorous verification in current LegalTech and proposes a framework for achieving "ascertainably correct" automated legal assistance.

TL;DR

As automated legal apps (ALATs) move from "experimental novelties" to "critical infrastructure" for self-represented litigants, a quality crisis is brewing. This paper by Lauritsen and Steenhuis warns of a "gathering storm" of mechanical malpractice caused by opaque logic and poor engineering standards. The solution lies in treating legal code with the same rigor as safety-critical software, using formal verification and decoupled architectures.

The Hidden Crisis in LegalTech

We are currently witnessing an explosion of interactive legal tools—from "DoNotPay" chatbots to sophisticated document assemblers like HotDocs. These systems prometheanly offer access to justice for those who can't afford $400/hour attorneys. However, the authors point out a dangerous paradox: Usability is not Correctness.

A legal app can have a beautiful, mobile-responsive UI but contain fundamental logic errors in how it calculates a statute of limitations or determines eligibility for bankruptcy. Because these apps are often built by committees of non-programmers using "low-code" tools, the "phase space" (the total number of possible logic paths) is rarely fully tested.

Why Current Methods Fail (The Motivation)

The paper identifies several "drivers of degradation" in legal software:

  • Logic Entanglement: Legal rules are often "hard-coded" into the UI (e.g., hidden inside a 'Next' button), making it impossible for a senior lawyer to review the law without reading computer code.
  • The "Amateur" Gap: Lawyers don't know Software Engineering (SE) best practices (like version control or unit testing), and SEs don't understand the nuance of legal "judgment."
  • Implicit Implications: Apps don't just provide what they say; they imply permissions. If an app lets a user skip a field, it implicitly says "This isn't required," which might be legally false.

Methodology: Engineering "Ascertainable Correctness"

To move from "prototypes" to "trusted agents," the authors propose a shift toward Visible Reasoning.

1. The MVC for Law

The core insight is to treat legal software through the lens of the Model-View-Controller (MVC) pattern.

  • Model: The "Pure Law" (Deontic propositions: obligations, permissions).
  • View: The "Interview" (The UI, plain language helps).
  • Controller: The "Reasoning Engine" (The logic that connects user facts to legal outcomes).

2. Tools of the Trade

The authors analyze several platforms, highlighting how they handle (or fail to handle) quality: The Logic Table

  • Docassemble: Praised for being API-driven and supporting Python, allowing for automated testing.
  • Neota Logic: Highlighted for its "Why Ask" and "Static Analysis" features that explain the logic path to the developer.
  • A2J Author: Noted for its visual maps, though it struggles with "hidden" logic in complex branching.

Experiments in Verification

The paper suggests that the AI & Law community should contribute "exercise programs"—software designed specifically to interrogate other legal software.

  • Formal Verification: Reducing a legal interview to a Finite State Automaton (FSA). If you can map the app as an FSA, you can mathematically prove that there are no "dead ends" or illegal states.
  • Regression Testing: Using tools like Selenium or Gherkin scripts to simulate thousands of users to ensure that a fix in "Child Support" logic doesn't accidentally break "Alimony" calculations.

Performance and Complexity Typical complexity growth in a legal app "Phase Space".

Critical Insight & Conclusion

The authors conclude with a sobering "Standard of Care." For every set of inputs, the system should behave in a way that a human expert would not find objectionable.

The Takeaway: We are entering an era of "Algorithmic Accountability." If a legal app gives bad advice that leads to an eviction or a lost custody battle, "As-Is" disclaimers may not protect providers forever. The "storm" is coming, and our best umbrella is a combination of Formal Logic and Open Engineering Standards.

Future Outlook

The next frontier isn't just "Document Assembly"—it's Agentic AI. As systems begin to file papers directly with courts (e-filing), the cost of a "bug" moves from a typo to a due process violation. The authors call for the AI & Law community to stop focusing solely on academic models and start helping secure the "machinery" of justice.

Find Similar Papers

Try Our Examples

  • Search for recent papers (post-2020) that apply Formal Methods or Model Checking to verify the correctness of legal expert systems and chatbots.
  • Who first proposed the "Model-View-Controller" (MVC) architecture in the context of legal knowledge engineering, and how has this evolved with modern platforms like Docassemble?
  • Find research exploring the application of Large Language Models (LLMs) to automatically extract decision trees or formal logic from statutory text for use in interactive legal apps.
Contents
Substantive Legal Software Quality: Is Your AI Lawyer Actually a Liability?
1. TL;DR
2. The Hidden Crisis in LegalTech
3. Why Current Methods Fail (The Motivation)
4. Methodology: Engineering "Ascertainable Correctness"
4.1. 1. The MVC for Law
4.2. 2. Tools of the Trade
5. Experiments in Verification
6. Critical Insight & Conclusion
6.1. Future Outlook