JT/DL: Court Innovation is Middleware
Plus new jobs!
The JT/DL is a twice-monthly newsletter about justice technology news, events, and opportunities. Subscribe for free to receive new posts and support my work.
After introducing the Court Innovation Fund and exploring how bad court function can hinder everything from affordable housing to national security, I’m now focusing on what a philanthropic fund can do to innovate courts and improve just outcomes. In this series, I previously wrote about the need for court AI benchmarking.
Court Innovation is Middleware
Access to justice is at the mercy of court case management systems (CMS).
A colleague’s recent experience in Oklahoma illustrates why. He and his team were working with a group that provides legal representation to people facing low-level charges in municipal court, the kind of charges that don’t guarantee you an attorney. Many waited up to two weeks in jail before lawyers even learned of the arrest—often accruing additional charges in the meantime.
Working together with the municipal court and the legal non-profit, my colleague’s team built software that connected the court’s data in its CMS to a dashboard for the non-profit. Now, the non-profit learns of arrests day of. Quicker representation led to prisoners spending less time in jail and accruing fewer add-on charges. All it took was a little bit of code to stitch it all together.
A court CMS manages how data is entered, structured, and ultimately used—making it the technical epicenter of the American justice system. The nearly 70 million cases processed each year should generate usable data to improve court function, expand access to justice, and even drive broader policy goals. Instead, foundational software failures leave that potential unrealized.
As part of the development of the Court Innovation Fund at Renaissance Philanthropy, we want to fix that failure.
Middleware is the most transformative force in court technology that no one is talking about. This critical, behind-the-scenes infrastructure enables a CMS to seamlessly integrate with external software, like Oklahoma’s data portal, unlocking entirely new capabilities. When built well, middleware doesn’t just patch over outdated systems—it dismantles them. It breaks the stranglehold of vendor lock-in, liberates courts from brittle legacy architecture, and creates a scalable, frictionless foundation for innovation. The result isn’t incremental improvement; it’s a fundamental restructuring that opens a new market for court technology, strengthening the judiciary’s ability to serve the public.
The Disconnect
Before we get to the solution, let’s look into the problem. When we think of software, we often think of the user interface—not the hidden layers that make it work. This includes application programming interfaces (APIs), which allow software to interact with other software.
In my research from 2021, I found that APIs were barely an afterthought in justice technology. The absence of functioning APIs and middleware technology has created a literal disconnect in court software that undercuts the potential of even the most basic solutions.
As it stands, court CMS APIs–if they even exist–are bad and rarely meet modern software standards. Among other problems: Court APIs often lack documentation, making it a guessing game for a developer on how to plug into the CMS; there’s no success metrics, meaning that a developer won’t know if she’s successfully connected to the CMS without it being manually confirmed by court staff; and the APIs regularly break, restarting the development guessing game about how to connect.
When they fail, and they fail often, court functionality goes down with them, creating real world ramifications.
Take court text message reminders, one of the rare justice tech interventions that every study says works. They increase court appearance rates and reduce bench warrants and defaults—outcomes that spare people arrests, fines, and cascading legal trouble across criminal and civil dockets. In a rational system, text message reminders would be ubiquitous.
Yet they are not. Even when courts want them and funding exists, adoption stalls because plugging a third-party messaging service into a court’s CMS is technically prohibitive. The barrier is not policy, it is plumbing. Similar integration failures have stymied data analysis, self-help tools, and administrative reforms across the country.
Three major factors brought us here: capacity deficits, constrained budgets, and corporate capture.
Most courts lack the technical capacity to govern modern software systems. Critical technology decisions are often made without dedicated IT leadership or outsourced entirely to vendors. This trend is both explained and compounded by paltry court budgets. We simply don't invest enough to have good court software.
But it’s not just a government problem: the vendors want it this way. If you are a vendor with a multi-year CMS contract with a court, you want the court to come to you for all of its technical needs. That dependency, also referred to as vendor lock-in, is the business model. Easy, plug-and-play interoperability would let courts build on their own data, drawing business away from vendors. That is the perverse incentive at the heart of the problem: bad APIs are good business.
Middleware is the escape hatch
Middleware is a neutral software layer that sits between a court’s case management system and the outside world. Instead of forcing every new tool to integrate directly with a brittle, proprietary CMS, middleware standardizes the court’s data once and exposes it through a modern, reliable API. Once that layer exists, new functionality can plug in easily—without negotiating with the CMS or its vendor every time.
This solution is not theoretical. CourtStack, developed by the Los Angeles Superior Court and now active in at least 30 California counties, demonstrates the model in practice. Similar efforts are underway at Suffolk Law’s LIT Lab and the Free Law Project.
A nationwide middleware strategy would fundamentally restructure the court technology market by shifting power from vendors back to courts—and from closed systems to open innovation.
For courts, middleware would jailbreak their data and break the vendor chokehold. Features built on top of the middleware—text reminders, payment systems, data portals—would become portable, not tethered to the CMS. The ability to carry functionality across different CMS collapses switching costs and ends vendor inertia.
It would also replace today’s duplicative development model with a shared one. Instead of vendors rebuilding the same feature court-by-court, functionality developed once could deploy anywhere. Costs would fall, timelines would shrink, and experimentation would accelerate.
For the public, the impact would be immediate: courts could deploy tools that help people show up, pay, access records, and navigate proceedings without waiting years for vendor updates. Universities, nonprofits, and startups could build without negotiating costly custom integrations in every jurisdiction. The technical barrier to entry would vanish.
In short, middleware is not just a technical fix. It is the infrastructure for a competitive, innovative, and interoperable court technology ecosystem—one no longer constrained by proprietary vendors and long contracts.
These benefits are real, as we are seeing in California. However, to expand this idea beyond California, we need to dig deeper. To plan our funding strategy in this promising space, the Court Innovation Fund wants to study the CourtStack experience; understand the challenges of bringing new courts online, the costs of implementation, and the economics of scaling; and consider whether a play like this makes sense as a nonprofit or for-profit venture. We also need to ensure that this technology is improving court cybersecurity, and not creating an unwitting vector for attack.
An innovative court is connected to its data, the public they serve, and the future. Just look to Oklahoma, where a small layer of software shortened jail stays and prevented new charges. That wasn’t a feature upgrade, it was structural reform. Meanwhile, most of America’s courts are locked into a bad contract or legacy software, unable to connect to new data sources or add new tools. In a word, they’re trapped.
Middleware is how they break free.
News
Platforms bend over backward to help DHS censor ICE critics, advocates say. (Ars Technica)
Milwaukee officer charged for misuse of license plate reader to track someone he was dating. (New York Times)
Axon revenue surges as AI tools drive explosive growth. (The Guardian)
ICE tripled its reliance on Microsoft in last six months. (The Guardian)
Defense counsel type, defendant interventions, and punishment in a virtual pretrial courtroom. (Criminal Justice & Behavior)
Hidden in plain sight: Surveillance at the Arizona border. (The Border Chronicle)
Record clearing insights: How data can impact policy. (A2J Lab)
AI in policing: Transparency is the safeguard. (Right on Crime)
Events
Stanford is offering an Ethics, Technology, and Public Policy for Practitioners course on March 15. (SSHS)
Suffolk Law is hosting LIT Con April 13. (SLS)
We Robot 2026 is April 23-25 in Berlin. (WR)
RightsCon is May 5-8 in Zambia. (RC)
Wikimania will be in Paris July 23-5. (WM)
The A2J Network Conference will be in Cincinnati in October. (A2JN)
Jobs & Opportunities
[New] Arnold Ventures is looking for a criminal justice innovation fellow. (AV)
[New] The Brennan Center for Justice needs a technology policy strategist for its Liberty & National Security Program. (BCJ)
The Center for Democracy and Technology has multiple openings. (CDT)
[New] The Clean Slate Initiative needs a grants administrator. (CSI)
Code for America has multiple openings. (CfA) (h/t Russ Finkelstein)
The Gates Foundation needs a deputy director for its AI and Data Enablement Hub. (GF)
[New] Google.org has a new challenge for AI in government. (G.o)
The Institute for Law and AI has multiple openings. (ILAI)
Lambda Legal needs a legal project manager. (LL)
The MacArthur Foundation needs a director of AI and opportunity. (MF)
[New] Pro Bono Net needs a software engineer. (PBN)
Recidiviz needs a product manager. (R)
Stanford’s Rhode Center on the Legal Profession needs an associate director of research. (SDRC) (h/t Natalie Knowlton)
TechTonic Justice is hiring for multiple roles. (TTJ)
The University of Texas School of Law needs an AI and legal practice fellow. (UT)
[New] The Z Smith Reynolds Foundation needs a program officer. (ZSRF) (h/t Keith Porcaro)
Ok. Let's unpack this a bit more from a court technology standpoint/viewpoint. These are my musings on this interesting article. Courts are case-based operations, with judges serving at the top of each case. As such, CMS systems support the processes involved from the opening of a case to its final adjudication.
Oddly, if you asked a judge on any given day about their CMS, they might answer back 'What is a CMS?' There are many technologies in courtrooms, virtual or otherwise, that judges are directly interested in, such as video and sound recording, transcription, language translation, electronic and other documents, party and attorney locating systems, etc. For many judges, the CMS is a summary record keeper that the court's staff manages.
The paragraph above suggests that a CMS is viewed as a necessary documentation system. Still, it is not integral to the court's case-based operations, which are mainly focused on the generation of documents - orders, motions, hearings, etc. To understand the difference in scale between the summary CMS information and the actual court-generated documents, I'll provide an example from a small state in the United States.
Here is the amount of information (minus the error and logging tables, which are the largest tables in the CMS): 3/4 of a gigabyte. Now, compare this to the documents stored for the same case load: 11 Terabytes. Obviously, the vast majority of the court's efforts and focus are on these documents, not the CMS information. As a judge or staff person, the job is to get the documents completed that enable the case to proceed to closure. The CMS exists to attach these documents to the case summary.
Existing CMSes are not integral to the court's daily battle. It is more like an accounting system, important, yes, but only for its summary of what happened, not in actual effort. The CMS is similar to hospitals' building control systems (BCS) of the 1980s that automated (somewhat) building services, such as heating, air conditioning, and air/infection control systems.
To make this analogy clear, I'll travel back to the hospital environments of the 1980s. Each new wing of a hospital received a new building control system that usually did not communicate with the other BCS in the hospital, nor with other hospitals in the corporation. Each BCS control involved a couple of men staring at computer screens, making decisions, and taking actions based on what the BCS displayed.
Obviously, this was expensive, error-prone, and blocked transmission and consolidation of information into a corporate or organizational view of hospital building performance. Fortunately, the creation of an industry-wide standard, BACnet (Building Automation and Control Network), has helped hospital facility management overcome much of this inertia.
Unfortunately, the direct financial pressure clearly identified in the BCS example is hidden in courts under the gowns and wigs of Perry Mason, Horace Rumpole ("Old Bailey Hack"), or Chief Justice John Roberts, weighing the issue adversarially for justice. In reality, most of the court cases do not end up in court.
Many case conclusions do not resemble anything close to the antics of 'My Cousin Vinny.' If we removed traffic, eviction, and credit card disputes from the courts' list of cases under judicial adjudication, the courts' caseload would greatly decrease.
Am I saying that these cases are unimportant? No. I am saying that addressing these cases is more advantageous than adversarial. Judges and lawyers are trained in the adversarial approach, not in arbitration. Courts gear up their case systems to prepare for the courtroom, not for arbitration. Each state court in the United States, and probably many courts elsewhere, is stuck in that BCS room, viewing each case from the bunkered silo of its own view.
Let me provide a concrete example of how this view plays out. I'll start by asking a question: "Of all the events courts deal with, which do you consider to be the most important from a public safety standpoint?"
Some might say death penalty cases. Others might say murder or sexual assault. Each of these statements would be correct from a case perspective. Still, I would argue from a pubic safety standpoint that the publishing of denial of gun purchase rights happening in mental health and family courts is the most critical operation for public safety.
Why do I say this is so? From the criminal side, the police and IJIS do a great job of ensuring that criminals' rights to purchase weapons are listed in the FBI's gun registry called NICS. Great, but ask yourself this: what is the nature of people who have loaded up assault rifles and unloaded on crowds of innocent people, not criminals? I would argue that it is exactly mental and family courts that are on the frontlines of hearing the first echoes of potential mass shooters. Amazingly, no modern CMS, including CourtStack, comes standard with a NICS interface.
I know this because I was responsible for constructing a modern, cloud-based NICS interface to automate and monitor the placement of these records in NICS. It took two years to complete the link to NICS fully. Not because the 125 lines of code were difficult or the technology was new or unavailable. It took time to get the authorization and approval to 'try something new.'
I am not being critical of court management. It is an admission that court leaders are lawyers and judges whose stock-in-trade is tradition and precedent. A time-tested, successful approach to trying the case in the court of law, but it is a real problem when systems thinking and planning are required.
To provide another example, a CMS vendor didn't have an acceptable way to electronically deliver (email) a notice that an event occurred in the case management system. For example, an event would be a hearing, motion, etc. Using some Microsoft standard technologies and another 150 lines of code, and the AWS Simple Email Service, 5 to 20 thousand emails are sent out weekly to attorneys involved in cases.
Much of the court's activities occur in an ecosystem beyond the traditional three-legged stool - Judge, Party, and Lawyer. Think of family services, the department of corrections, DMV, health services, State's Attorney, Public defender, etc., etc.
Modern CMS systems still act as if the case-courtroom bunker is the rule rather than the exception. CMS providers had to be only as good as the three or four other CMS vendors in the market, which includes courts that are building their own or using vCMS Oversystems like CourtStack.
The CMS is an oligarchy, not a dynamic, modern, cloud-based software app market. Recently, Salesforce and Microsoft have been circling, and CourtStack is investing in creating a value-add tool that provides meaningful, quickly produced add-ons to the standard CMS data entry portals. Maybe CourtStack will become the new BacNet of courts. It is time because right now, if you seen one CMS, you've seen ONE CMS - different, and incompatible with all other CMS. A terrible situation for courts and the citizens who believe that courts ensure justice, even if they don't understand or, worse, fear the courts' operations.