Jury Selection Software Acceptance Test: A Mock-Panel Script Before You Sign

A vendor demo tells you whether a sales team can run their own software under ideal conditions. It tells you nothing about whether that software will hold up when a judge excuses a juror for cause mid-morning, your co-counsel is updating strikes on a different tablet, and the courthouse Wi-Fi drops for ten minutes. The direct answer: before you sign, run a fixed, repeatable mock-panel acceptance test that forces the platform to handle import errors, mid-voir-dire seating changes, strike accounting, export, and a manual-fallback drill, and treat the result as a go/no-go scorecard, not a feature comparison.

This isn't a checklist of nice-to-have features. It's a simulation built to break the system the way a live panel will break it.

Why a Jury Selection Software Acceptance Test Beats a Vendor Demo

A demo is scripted by the people selling you the product. They control the data, the pace, and the scenario. An acceptance test flips that. Counsel writes the script, freezes it, and requires the vendor to configure the system live, without coaching, on a closed mock case.

Use a realistic panel of 24 to 40 jurors. Build in the mess you'll actually get from the clerk's office: incomplete questionnaire answers, duplicate names, handwritten-style responses that scan poorly, jurors with similar biographies who are easy to confuse, cause challenges, and alternates. If the platform only works on clean data, it doesn't work.

This matters beyond convenience. Lawyers remain responsible for competent use of technology and for protecting confidential client information even when a vendor processes that data remotely.[1][2] A platform that quietly mishandles juror data during a demo won't show you that problem. A platform tested against a messy, frozen script will.

What the Test Actually Measures

Six discrete stages, each with pass criteria. Fail any one of them without a documented fix, and the vendor doesn't get a signature yet.

Stage One: The Import Test

Import the court's venire list and questionnaire in the actual formats you receive them in, not a cleaned-up sample file the vendor prepared.

Pass criteria:

Every juror gets a stable, unique identifier that doesn't shift when data is edited. Names, seat numbers, questionnaire fields, and annotations map to the correct juror. Missing, conflicting, or duplicate entries trigger a visible alert rather than a silent overwrite. The system keeps an audit trail showing who changed imported data and when. And critically, exported records stay readable without the vendor's platform open, meaning you're not locked into their software to read your own work product.

If the import silently merges two jurors with the same last name, or overwrites a questionnaire field without flagging the conflict, that's not a minor bug. That's a juror misidentified in open court.

Stage Two: Questionnaire Handling Under Pressure for Jury Selection Software

Feed the platform questionnaires with blanks, narrative answers, contradictions, irrelevant information, and protected characteristics. Have counsel locate, filter, annotate, and correct entries live.

Then ask the vendor directly: which fields influence any ranking or recommendation the software produces? A tool should never covertly weight race, sex, religion, ethnicity, disability, age, sexual orientation, gender identity, socioeconomic status, or any proxy for those traits. ABA guidance places the responsibility squarely on the lawyer: counsel must not follow an AI tool's suggestion when they know, or reasonably should know, that a resulting strike would be discriminatory.[3]

Vendors who can't answer this question plainly, in specific terms about which inputs drive their outputs, haven't earned a contract. "Proprietary algorithm" is not an answer to "what is this scoring."

Stage Three: The Mid-Voir-Dire Seating-Change Test

This is where most jury selection software quietly falls apart, because most of it was never stress-tested against the pace of a live courtroom.

During live questioning, reorder three jurors, excuse one for cause, add an alternate, and change the seated panel, all while requiring the team to keep recording answers and updating strikes, with a second user viewing the panel in real time.

Pass criteria:

Seat changes don't alter a juror's identity or erase their historical notes. Cause challenges, peremptories, holds, and unused strikes stay in distinct categories rather than blending together. Multiple users see synchronized status, so co-counsel isn't working off a stale screen. The system blocks a strike against a juror who's already been excused or already seated. And every recommendation the software produces can be traced back to an observable input, not just a bare score with no explanation attached.

The constitutional floor here doesn't move because software is involved. Batson v. Kentucky, 476 U.S. 79 (1986), prohibits race-based peremptory strikes, and J.E.B. v. Alabama ex rel. T.B., 511 U.S. 127 (1994), extended that scrutiny to gender-based strikes.[4][5] A platform can organize your notes. It cannot insulate you from a Batson challenge, and any vendor who implies otherwise is selling something they can't back up.

Stage Four: Strike Tracking That Survives Reconciliation

Run the jurisdiction's actual strike rules, including alternates and cause challenges. Have two lawyers enter strikes independently on separate devices, then reconcile the two records against each other.

The platform needs to produce a visible ledger showing strikes available and used, which juror was affected, the stated reason or category, the sequence and timestamp of each action, which attorney acted, and the final seated panel. If two lawyers' independent entries can't be reconciled into one clean, defensible record, the software has failed the one job that matters most under appellate scrutiny.

Any score or recommendation the system generates should function as decision support, full stop. It is not a substitute for counsel's individualized, non-discriminatory judgment about a specific juror.[3][6]

Stage Five: Export and Record Test

Export the final panel, notes, strike ledger, questionnaire data, and audit history to both PDF and a machine-readable format. Check that pagination, juror identifiers, timestamps, and annotations all survive the export intact.

Then read the contract. Does it permit retrieval and deletion of case data at close? Does it prohibit the vendor from training its models on your client data? Does it name a breach-notification duty and a timeline? These are confidentiality obligations lawyers carry regardless of who's hosting the data, and a glossy interface doesn't answer any of them.[1][2]

Stage Six: The Manual-Fallback Drill

This is the stage vendors resist most, and the one that tells you the most.

Disable the Wi-Fi. Log out the primary user. Remove the tablet. Counsel has to keep working for 20 minutes using printed panel sheets or a local spreadsheet, then reconcile those manual decisions back into the platform once it's restored.

The test passes only if no information is lost, no duplicate strikes slip through, and the final record clearly identifies which entries were made manually and later synchronized. If the vendor tells you this scenario "won't happen" with their system, that's a reason to run the drill twice.

How the Test Reads Across Practice Areas

A plaintiff's lawyer in a catastrophic injury case needs the strike ledger to hold up months later when defense counsel challenges a strike pattern across a multi-week trial. A criminal defense attorney needs the audit trail to show, cleanly, that a strike was based on an articulated, case-specific reason and not a proxy for race, because that record may need to survive a Batson hearing on the spot. Corporate defense counsel handling a long voir dire with dozens of jurors needs synchronized multi-user access so a trial team spread across two tables isn't working off conflicting screens. A prosecutor needs the same thing defense counsel needs: a record that shows the stated, race-neutral reason for every strike, timestamped and attributable, because the state carries that burden too under Batson's step-three analysis.

None of those needs are unique to one side of the aisle. They're all the same requirement wearing a different case caption: a defensible, traceable record of what was done and why.

Treating the Result as a Scorecard, Not a Sales Conversation

Score it as go or no-go. No undocumented failure in juror identity, strike accounting, confidentiality handling, export integrity, or manual fallback. If the vendor fails a stage, the fix needs to happen before signature, not after jury selection has already started in your case. A vendor who argues that a failed stage "won't come up in practice" is asking you to take on the risk they weren't willing to engineer around.

FAQ

What size mock panel should I use for the acceptance test? A panel of 24 to 40 jurors gives enough volume to surface real import and tracking problems without making the test unmanageably long. Build in duplicate names, incomplete answers, and jurors with similar biographies, since those are the conditions that expose weak identity-matching logic.

Does jury selection software itself create a Batson risk? The software doesn't create the risk, but it doesn't remove it either. Batson v. Kentucky, 476 U.S. 79 (1986), and J.E.B. v. Alabama ex rel. T.B., 511 U.S. 127 (1994), govern discriminatory strikes regardless of what tool produced a recommendation.[4][5] ABA guidance makes clear that counsel cannot rely on an AI suggestion once they know, or reasonably should know, a resulting strike is discriminatory.[3]

Why run a manual-fallback drill if the software rarely fails? Because courtroom conditions include courthouse Wi-Fi that does go down, devices that get left in a conference room, and users who get logged out at the wrong moment. The drill isn't about distrust of the product. It's about confirming the record stays intact and traceable when the technology isn't available for 20 minutes in the middle of voir dire.

Who should run the acceptance test, the vendor or the law firm? Counsel should write and freeze the script, then require the vendor to configure the system live without coaching. If the vendor writes the test, it becomes a demo again. The point is to see unscripted configuration under conditions counsel controls.

What should be in the contract before signing, beyond the acceptance test results? Confirm the contract addresses retrieval and deletion of case data at close, a prohibition on using client data to train the vendor's models, and a defined breach-notification duty and timeline. These sit alongside, not instead of, the technical acceptance test.

Running a test like this is part of why we built StrikeList AI around a visible strike ledger and traceable, non-discriminatory inputs rather than a black-box score. Whatever platform you evaluate, insist on seeing it fail in a controlled setting before you ever need it to succeed in a real one.

Notes

1. American Bar Association, Formal Opinion 477R, "Securing Communication of Protected Client Information," May 22, 2017, https://www.americanbar.org/content/dam/aba/administrative/professional_responsibility/aba_formal_opinion_477.pdf
2. American Bar Association, Model Rules of Professional Conduct, Rule 1.1, Comment 8 (technology competence), https://www.americanbar.org/groups/professional_responsibility/publications/model_rules_of_professional_conduct/rule_1_1_competence/comment_on_rule_1_1/
3. American Bar Association, Formal Opinion 512, "Generative Artificial Intelligence Tools," July 29, 2024, https://www.americanbar.org/content/dam/aba/administrative/professional_responsibility/ethics-opinions/aba-formal-opinion-512.pdf
4. Batson v. Kentucky, 476 U.S. 79 (1986), U.S. Supreme Court, decided April 30, 1986, https://supreme.justia.com/cases/federal/us/476/79/
5. J.E.B. v. Alabama ex rel. T.B., 511 U.S. 127 (1994), U.S. Supreme Court, decided April 19, 1994, https://supreme.justia.com/cases/federal/us/511/127/
6. American Bar Association, Model Rules of Professional Conduct, Rule 5.3 (responsibilities regarding nonlawyer assistance, including technology vendors), https://www.americanbar.org/groups/professional_responsibility/publications/model_rules_of_professional_conduct/rule_5_3_responsibilities_regarding_nonlawyer_assistant/