Prosecutor Case Management Software: Why Discovery Is the Only Record That Will Be Questioned

Why a prosecutor's office runs on clocks and disclosure, not on cases

Ask a district attorney what keeps them up and you will not hear about case volume. You will hear about two things. The first is a discovery failure: something exculpatory that existed in the file and was not disclosed, or was disclosed so late that a judge sanctions the office or a conviction is vacated years later. The second is a clock: a speedy trial deadline that ran because excludable time was miscounted, and a case that should have gone to trial gets dismissed on a calendar error.

Both of those are records problems. Brady v. Maryland and Giglio v. United States define disclosure obligations that reach material in the possession of the prosecution team, which includes law enforcement agencies that never send you their whole file. Speedy trial is arithmetic over a timeline of continuances, motions and unavailability, where every entry has to be classified as chargeable or excludable at the time it happens, because reconstructing it eighteen months later from minute orders is how offices get it wrong.

Everything else the office does, screening, charging, plea negotiation, sentencing recommendations, appeals, sits on top of those two spines. A system that models them well is worth building. A system that treats a case as a folder with notes is a document store with a courthouse logo on it.

Problem 1: intake is a charging decision with a clock attached, not a data entry task

A referral arrives from a police agency. Sometimes it is a complete packet. More often it is a report, a supplement that will arrive later, a lab request that has not been submitted, three hours of body worn camera video sitting in the agency's evidence platform, and a defendant already in custody with an arraignment deadline running.

The screening attorney has to decide whether to file, what to file, and against whom, and the decision depends on material that has not arrived. In most offices the tracking for that is an email thread with the detective. When the packet is incomplete at the deadline, the office either files thin or declines, and neither outcome gets recorded in a way that supports a later question about charging patterns.

What a build should do is treat intake as a structured referral with expected components. The referral records what was promised, what arrived, what is outstanding and who owns it, with the custody status driving the deadline. Charging decisions record the statute, the degree, the enhancement and the reason, in codes rather than narrative, because the office will eventually be asked to describe its own charging practice and free text cannot answer that. The decline reason is as important as the filing reason, and almost nobody captures it usefully.

Problem 2: discovery is a certified log, not a shared folder

The volume changed and the tooling did not. A routine impaired driving case now carries multiple camera angles, in car video, booking video and possibly an interview recording. A homicide carries phone extractions measured in gigabytes, surveillance from a dozen private cameras, and lab reports with underlying bench notes. Defense counsel is entitled to a great deal of it, redaction obligations apply to some of it, and protective orders restrict distribution of parts of it.

The common practice is a link to a cloud folder plus a letter. That practice fails in a specific way. When a defense attorney asserts in a motion that item 14 was never provided, the office needs to answer with a record: this item, this hash, this date, this recipient, this delivery method, this acknowledgement. A folder listing does not prove delivery, and an email with a link does not prove what was in the folder on that date, because folders change.

Build discovery as a versioned package. Each production is an immutable set of items with fingerprints, a generated index, a recipient, a timestamp and an acknowledgement record. Supplemental productions reference the prior ones so the cumulative picture is reconstructable. Redaction decisions are recorded against items with the reason, and the unredacted original stays in the file. Protective order terms attach to items and control who can download them. When someone asks what was disclosed on a date, you produce the package as it existed, not a reconstruction.

The other half of the obligation reaches outside the office. Material in the possession of the investigating agency counts, and that includes officer credibility material. Offices maintain a disclosure list of officers with sustained findings, and the practical failure is that the list lives in a spreadsheet maintained by one supervisor and is not checked against witness lists automatically. Wiring that check into case preparation, so that adding an officer as a witness surfaces any disclosure obligation immediately, is one of the highest value features you can build and one of the least common.

Problem 3: speedy trial is computed, and excludable time is where it goes wrong

Every jurisdiction has its own construction: a period measured from arrest, from filing or from arraignment, with different limits for in custody and out of custody defendants, and a list of excludable periods covering defence continuances, competency proceedings, interlocutory appeals, unavailability of a material witness and periods attributable to codefendants.

Offices track this on a calendar reminder plus institutional memory. The failure mode is not usually a missed date on a simple case. It is a complex case with three continuances, a competency evaluation and a codefendant severance, where two attorneys disagree about the running total and neither can prove it.

Model it as an event timeline where every scheduling event carries a classification at the moment it is entered, along with the authority for that classification. The system computes the remaining days continuously, shows the derivation, and alerts on thresholds rather than deadlines, because a warning on the last day is not useful. When defence files a motion to dismiss on speedy trial grounds, the response writes itself from the timeline.

Problem 4: victim notification is a statutory duty performed at every hearing

State victim rights provisions, including the Marsy's Law amendments adopted in a number of states, create enforceable rights to notice of proceedings, to be heard, and to confer with the prosecutor. Practically that means someone in your office has to notify a victim before each setting, record whether contact succeeded, capture their position on a plea, and arrange their appearance and often their travel.

When this is manual, it is the first thing to fail on a heavy calendar, and the failure is visible: a victim learns from the news that a plea was entered. Some offices then face a hearing about the failure itself.

Build notification as an obligation generated by the calendar rather than a task someone remembers. Each setting creates notification obligations for entitled parties, tracked across channels with delivery evidence and a fallback path. Contact preferences and safety restrictions belong on the party record, since some victims cannot be contacted at a home address safely. The advocate's record of the conversation, including a victim's position on disposition, should be linked to the case but access controlled, because it is sensitive and some of it is discoverable and some is not.

Problem 5: the office is downstream of everyone and upstream of nothing

You receive referrals from multiple police agencies with different records systems. You receive video from evidence platforms you do not control. You receive lab results on the lab's schedule. You depend on the jail for custody status and on the court for settings and dispositions. Almost nothing originates in your office except your own work product, and yet you carry the obligations.

That shapes the architecture. Assume every inbound feed will break, arrive late, or change format without notice, and build accordingly: durable ingestion with a visible queue, reconciliation reports that show what you expected against what arrived, and alerts when an agency's feed goes quiet. A large share of the manual work in a prosecutor's office is people checking whether something arrived. Automating the checking, not the judgement, is where the time comes back.

Criminal justice information security requirements apply across all of it, which affects authentication, audit logging, where data may be hosted and who may administer the systems. Design for it early rather than at the security review, because retrofitting access controls into an application built without them is a rewrite.

What this costs and how long it takes

From the justice sector work Digital Heroes has delivered, a first release covering referral intake, charging, the case timeline with speedy trial computation, and the discovery package engine runs $120,000 to $280,000 and ships in 14 to 22 weeks. A full office platform adding victim notification, witness management, plea and disposition tracking, appeals, restitution, reporting and law enforcement integrations runs $300,000 to $700,000 over 9 to 18 months.

Cost drivers here are specific. The number of referring agencies and their records systems, since each is a distinct interface. Digital evidence handling, because storage volume, transfer performance and redaction workflow are engineering problems at gigabyte scale rather than at document scale. Court integration for settings and dispositions, which determines whether your calendar is trustworthy. Multi county or multi office deployment. And your charging code set, which usually needs cleaning before it can drive anything, because it has accumulated for years.

The way to keep it contained is to start with discovery and the timeline. Those two carry nearly all the risk in the office, and they can be delivered against your existing case system before any question of replacing it arises.

Build versus buy: when Karpel or eProsecutor is the right answer

Buy if you are a small to mid size office with a stable process and moderate volume. PROSECUTORbyKarpel is deeply embedded in this market and encodes a great deal of prosecutorial workflow. Journal Technologies eProsecutor is a serious option, particularly where the court in your jurisdiction runs on the same family of systems and the integration comes for free. Tyler Technologies is worth evaluating where an existing county estate makes integration the deciding factor. None of these are bad products and replacing a working one out of dissatisfaction with its interface is a poor use of public money.

Build when discovery volume has outrun the product. If your office is producing digital evidence at a scale the packaged tool handles by linking to an external platform, you are carrying the certification risk yourself with no record. Build when your speedy trial construction is unusual and the vendor computes it wrong, which is common because the rules differ substantially between states. Build when you need officer disclosure obligations checked automatically against witness lists, which almost no product does. And build the surround when the core is fine: a discovery package engine, a notification service, or an analytics layer for charging and disposition patterns can all sit alongside an existing system.

One more honest note. If your office is under a consent decree, a court order or legislative scrutiny about disclosure practice, build. The requirement in that situation is provable process, and provable process is exactly what a configurable product cannot promise you.

How to choose a developer for prosecutor systems

Ask them to design a discovery production before you talk price. Listen for immutable packages, content fingerprints, an index generated with the package, recipient acknowledgement and supplemental productions that reference their predecessors. If the answer is a folder with permissions, they do not understand what you are buying.

Ask how excludable time would be recorded. It must be classified when the event is entered, with the authority attached, not derived later from minute orders. A team that suggests computing it retrospectively has not spoken to a trial attorney.

Ask what they know about criminal justice information security requirements, and expect it in the first architecture conversation rather than at a security review. Authentication, audit logging, hosting and administrative access are all affected.

Ask which police records systems and evidence platforms they have actually integrated, by name, and what broke. Digital evidence transfer at scale has failure modes that only show up in production, and someone who has lived through them will tell you about throughput and retries rather than about an API.

Ask who owns the code, the repositories and the cloud accounts, and settle it before kickoff. Digital Heroes transfers all three to the client from the first commit. For a prosecutor's office this is directly a discovery question: the system holds the record that proves your compliance, and you cannot be in a position where producing it requires a vendor's cooperation.