AI CLAIMS EVALUATION SOFTWARE IN INSURANCE BAD FAITH DISCOVERY

A Practitioner’s Discovery Reference: Understanding the Systems, Framing the Requests, Managing the Cost

I.  Purpose and Framing

AI claims evaluation software is now part of the claim-handling record in many insurance cases, and in the right bad-faith case it may explain how the carrier reached its valuation, why it refused to move, or whether the adjuster’s stated rationale matches the system-driven record. For lawyers, the point is not to chase technology for its own sake. The point is to identify whether software influenced the claim decision and, if it did, to obtain the records needed to test that decision in discovery.

This article gives practitioners a practical framework for understanding how AI claims evaluation software works, how to discover whether any such system touched the claim, and how to decide whether the production justifies follow-up discovery, deposition work, or expert review. The central discovery problem is not simply format. It is sequencing. In most cases, the lawyer should first use written discovery to identify the systems, custodians, access history, audit trails, retention policies, deleted or overwritten data, and claim-specific outputs. Only after that first round should counsel decide whether to insist on lawyer-readable exports, data dictionaries, rendered reports, native technical files, or expert analysis.

The practical roadmap is simple. First, find out what systems exist and who used them. Second, obtain the claim-system history, access logs, metadata, and native or reasonably usable exports sufficient to show what happened. Third, review the production before demanding duplicate lawyer-readable versions or expert-only technical files. Fourth, if the production is coded, incomplete, or not reasonably usable, ask for the data dictionary, lookup table, code legend, rendered report, chronology, or witness explanation that makes it usable. Fifth, if the software evidence is a nothing sandwich, stop spending money on it and litigate the case on the claim-handling facts that actually matter.

II.  How the Systems Work

AI claims evaluation software used by the property-and-casualty industry falls into two generations. The generational distinction is the single most important technical fact for discovery purposes, because it drives what can be preserved, what can be reproduced, and what must be extracted from whom.

A.  Generation One — Rules-Based Expert Systems

The dominant products in this category are Colossus, owned by DXC Technology (originally developed by Computer Sciences Corporation (CSC)); Claims Outcome Advisor (COA), later renamed Liability Navigator (LNav), owned by Verisk Analytics (originally developed by Insurance Services Office (ISO)); and ClaimIQ with its bodily-injury module InjuryIQ, owned by Mitchell International (part of Enlyte). A fourth, Injury Claims Evaluation (ICE), originally from Automatic Data Processing (ADP), has a smaller footprint. Guidewire is a broader claims-management platform that includes some evaluation features and was built in part by a former Colossus programmer, though it is not primarily a bodily-injury evaluator. See Settlement Intelligence, “AI Expert Systems for Demand Letters” (2024); Mark C. Blane, “InjuryIQ Computer Program and Colossus Accident Claims Software” (available at blanelaw.com); AutoAccident.com, “What Is Colossus?”.

These systems are expert systems in the formal sense: they implement a human-written ruleset, walking the adjuster through a scripted questionnaire that codes the claim’s injuries against a master library (Colossus reportedly maintains approximately 600 injury profiles; Claims Outcome Advisor (COA) advertises a database of more than 18,000 medical conditions). The adjuster enters injury data, treatment duration, diagnostic findings, jurisdiction, liability percentage, age, occupation, pre-existing conditions, and a set of “value drivers” (the most discussed being Duties Under Duress — whether the injury interferes with obligatory life activities). The system runs a weighted calculation and outputs a suggested general-damages range. See generally Aaron DeShaw, “Colossus Demand Letters by Settlement Intelligence” (collecting historical detail on the system’s architecture).

Two architectural features matter for discovery. First, these systems are deterministic: given the same inputs, the same ruleset, and the same tuning parameters, they produce the same output. The calculation is, in principle, reproducible. Second, each carrier tunes its own installation — setting the dollar value of severity points, adjusting jurisdictional modifiers, enabling or disabling specific rules — so the same claim processed by two different carriers on the same underlying software will produce materially different numbers. Colossus was adopted by Allstate in 1995 as part of its McKinsey-designed Claim Core Process Redesign (CCPR) initiative, and within several years was reportedly in use at carriers representing more than 60% of U.S. personal auto direct written premium. Multistate regulatory action in the mid-2000s resulted in disclosure and calibration requirements for at least one large carrier. See Settlement Intelligence, “Why Do You Need AI Demand Letter Technology” (summarizing historical adoption and regulatory response); Hoffmann Personal Injury, “Colossus Settlement Calculator in Missouri” (January 2026) (noting requirement for disclosure when software may be used).

B.  Generation Two — Machine Learning and Modern Artificial Intelligence

The newer systems — and the ones most aggressively deployed since approximately 2018 — are machine learning (ML) models: neural networks and related statistical models trained on historical claims data rather than programmed with explicit rules. They produce predictions (severity score, fraud likelihood, litigation risk, reserve recommendation, recommended offer) rather than rule-traceable calculations. These are widely referred to as Artificial Intelligence (AI), although that term also loosely covers the older expert systems.

Four structural differences from Generation One drive the discovery strategy. Modern Artificial Intelligence (AI) systems are probabilistic rather than deterministic: the same inputs may produce slightly different outputs across model versions, and the reasoning is distributed across millions of parameters rather than legible rules. They are opaque: even the data scientists who built the model often cannot fully explain why it produced a particular output on a particular claim, and dedicated explainability tools such as SHapley Additive exPlanations (SHAP) and Local Interpretable Model-agnostic Explanations (LIME) must be run to produce post-hoc rationales. They inherit bias from their training data: if the carrier historically underpaid soft-tissue claims in specified zip codes, a model trained on that history reproduces the pattern. And they are deployed at more and earlier decision points than Generation One ever was — not only general-damages valuation but First Notice of Loss (FNOL) triage, reserve setting, Special Investigations Unit (SIU) fraud referral, medical-bill review flagging, and in health insurance the outright denial of coverage. See National Association of Insurance Commissioners (NAIC), “Model Bulletin on the Use of Artificial Intelligence Systems by Insurers” (adopted December 4, 2023); PBS NewsHour, “How Patients Are Using AI to Fight Back Against Denied Insurance Claims” (January 2026) (reporting NAIC 2025 survey finding 84% of health insurers use AI for prior authorization and fraud detection); Aptarro, “Top 10 AI Insurance Claims Processing Software for 2026” (surveying current vendor landscape).

The newer vendor landscape also includes agentic insurance workflows, not just old-school valuation questionnaires. NewgenONE AI Agents for Insurance, for example, advertises agents for claims triage, fraud exposure, adjudication, and settlement support. Although a carrier could integrate AI into existing systems or use enterprise AI from available vendors tuned to its needs.  The point is not that every casualty carrier uses an agentic system on every liability file. The point is that modern claim technology has moved beyond Colossus-style inputs and outputs, and whether such a system touched the claim is now a discovery question.

C.  Why the Distinction Matters for Discovery

First, reproducibility. A rules-based system’s output can be re-derived from preserved inputs, ruleset, and tuning. A machine-learning (ML) output can be re-derived only if the exact model version, feature pipeline, and inference environment are preserved. Missing any of these, the carrier literally cannot show what its system did, which is either a powerful spoliation predicate or a powerful explainability-failure argument depending on the posture.

Second, preservation fragility. Rules-based systems change through discrete tuning events that are logged. Machine-learning (ML) models retrain on schedules — sometimes monthly — and prior versions are frequently not archived unless the carrier’s Artificial Intelligence (AI) governance policy requires it. The model that scored the claim in March 2025 may simply not exist by the time you file suit in 2026.

Third, regulatory posture. The National Association of Insurance Commissioners (NAIC) Model Bulletin on the Use of Artificial Intelligence Systems by Insurers is important discovery architecture, even though it is a model bulletin rather than a statute. It states that decisions or actions affecting consumers that are made or supported by advanced analytical and computational technologies, including AI systems, must comply with applicable insurance laws and regulations, including unfair-trade-practice and unfair-discrimination requirements. It also identifies the kinds of governance, risk-management, internal-control, third-party-vendor, documentation, and oversight materials regulators may request in an examination or investigation. For discovery purposes, that matters because the bulletin describes the records a responsible insurer should be creating and maintaining when AI is used in claim management, fraud detection, underwriting, pricing, or policy servicing. See NAIC, Model Bulletin on the Use of Artificial Intelligence Systems by Insurers (adopted Dec. 4, 2023).

Fourth, carrier leverage. The opacity of machine-learning (ML) systems creates a layer of deniability — “the model said so” is structurally different from “my adjuster said so” — that shifts leverage toward the carrier in the informal negotiating posture, but creates litigation exposure once the system’s opacity becomes the plaintiff’s evidence rather than the carrier’s shield.

III.  Staged Written Discovery: Identify First, Refine Later

The single most practical insight for AI claims evaluation software discovery is that the first round should identify what exists before counsel fights over the most expensive form of production. A lawyer does not usually know at the start whether the relevant data is readable in native form, whether a useful report already exists, whether the carrier can export a chronology, or whether the raw material is expert-only. The better practice is to ask broadly enough to identify the systems, logs, metadata, users, retention settings, and outputs, then refine the format and follow-up requests after the carrier answers.

A.  First Round — Identify Systems and Records Before Fighting Format

The first round of written discovery should resemble a broad but purposeful system-identification request. Ask the carrier to identify every electronic data system, claims platform, diary or activity-log system, reserve or settlement-authority module, policy-administration system, premium-accounting system, email or messaging platform, recorded-line system, document-imaging system, claims-evaluation tool, rules-based system, algorithmic tool, or Artificial Intelligence (AI) tool that recorded, stored, transmitted, accessed, or helped evaluate the claim. For each system, request the name, vendor or manufacturer, version, purpose, relevant users, audit-trail capability, version-history capability, search methodology, server or cloud location, backup or disaster-recovery sources, retention settings, and whether any claim-related data was deleted, overwritten, or destroyed.

B.  Follow-Up — Require Readability When the First Production Shows It Is Needed

Lawyer-readable production remains important, but it is often better requested after the first responses reveal what systems and exports actually exist. Some native formats are readable. Some Excel or Comma-Separated Values (CSV) exports can be sorted and understood by counsel with only a simple legend. Other native logs are useless without translation. If counsel demands duplicate rendered and native versions for every possible category at the outset, the request may draw avoidable proportionality and burden objections. A more practical sequence is to request native or reasonably usable exports first, evaluate whether they can be read and used, and then demand a lawyer-readable export, chronology, report, data dictionary, lookup table, code legend, or witness explanation if the production is not reasonably usable.

C.  Later Rounds — Add Readable Exports, Translation Materials, and Technical Files Only If Needed

Later rounds of written discovery should be driven by what the first round reveals. If the carrier identifies an applicable claims-evaluation system, audit trail, access log, model record, or vendor platform, counsel can refine the requests to fit the actual system rather than a guessed one. The follow-up may ask for a usable lawyer record — exported timelines, access-history reports, rendered valuation outputs, readable reports, manuals, governance documents, and communications — and, where needed, the technical materials required to test completeness and accuracy: native exports, metadata, session logs, event logs, data dictionaries, code tables, lookup tables, model identifiers, and system-level audit history. The point is not to demand multiple forms of everything reflexively. The point is to use the first discovery responses to decide what additional production is necessary, proportional, and worth fighting over.

A practical first round therefore should not be limited to “all documents relating to software.” It should ask for the claim file, the claim-system audit trail, activity history, event logs, routing history, document index, timestamps, user access logs, metadata, and native or reasonably usable exports sufficient to show when documents were created, modified, accessed, routed, and by whom. It should also ask interrogatories identifying the systems, users, audit capabilities, retention settings, search methodology, cloud or server locations, backup sources, and any deleted or overwritten data. That first round creates the map. The follow-up requests, corporate-representative deposition, readable-export demand, data-dictionary request, and expert review come only if the map shows something worth pursuing.

IV.  What to Ask For, in Seven Categories

The discovery structure below organizes the requests by substantive category. For each category, the practitioner should consider what the material is, why it matters, what format to specify, who will read it (lawyer or expert), and the approximate cost implications of pursuing it.

A.  Preservation

Preservation starts with what the carrier is already required or expected to keep. In a Missouri bad-faith case, the claim file is not supposed to disappear simply because no plaintiff’s lawyer sent a preservation letter. Missouri’s insurer-record-retention regulation requires insurers to maintain books, records, documents, and other business records so claims handling and payment practices can be readily ascertained during market-conduct examinations. It also requires claim records to be maintained for three calendar years after the later of the date the claim is closed or the date the claim is denied, and the regulation identifies claim-file materials such as notices of claim, claim forms, proofs of loss, investigative materials, adjuster notes, evaluation materials, settlement communications, denial materials, payment records, and related correspondence as the kinds of records that must allow the Department to determine what the insurer did and why. 20 CSR 100-8.040. That Missouri retention requirement should be read with the NAIC Market Regulation Handbook, the examination guide state regulators use to conduct standardized market-conduct reviews. The Handbook treats claim handling as a core examination area and frames the claim file as the record from which an examiner tests whether the insurer complied with claim-handling standards. In practical terms, the file should permit reconstruction of the claim: notice, investigation, coverage analysis, valuation, communications, settlement activity, denial or payment rationale, timing, and supervisory review. In addition, most carriers operate under internal document-retention policies, claim-handling procedures, vendor contracts, information-governance rules, and, where AI is used, governance expectations of the kind reflected in the NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers. Those sources matter because they may require preservation of claim materials, decision records, vendor materials, and governance documentation independent of any litigation hold from outside counsel.

A preservation letter remains a legitimate option, but it is a choice, not an automatic rule. At the beginning of most cases, plaintiff’s counsel usually does not know whether the carrier used AI claims evaluation software, a rules-based valuation system, a fraud-scoring tool, a litigation-risk model, or no meaningful software tool at all. Counsel also does not know what logs exist, what they contain, how long they are retained, or whether they would provide useful evidence. These technical logs are usually not the claim log itself. They may be access logs, system telemetry, prompt-and-response records, application logs, Security Information and Event Management (SIEM) exports, Application Programming Interface (API)-management logs, model-monitoring records, vendor logs, or compliance records. Some may be probative because they show who accessed the electronic claim file or claims-evaluation software, when they accessed it, and whether the nominal adjuster was actually the person using the tool. That can help identify supervisors, analysts, Special Investigations Unit (SIU) personnel, coverage staff, or other decision-makers who do not appear clearly in the ordinary claim notes. Other logs may be duplicative. Some may have no practical evidentiary value.

The strategic question is therefore whether an early preservation letter improves the record or simply gives the carrier an opportunity to narrow, sanitize, or reframe a deletion issue that existing retention duties may already make significant. In some cases, a broad preservation letter is the safest course because the systems are unknown and the potential records are fragile. In other cases, counsel may prefer to begin with targeted discovery to identify what systems touched the claim, what records should exist, and what retention policies governed them. If records are missing, the carrier then has to explain their absence against Missouri claim-file obligations, its own retention policies, vendor obligations, and any AI-governance framework it claims to follow. The point is not to avoid preservation. The point is to decide deliberately whether the hold letter helps the case or whether the carrier’s inability to account for missing software evidence is better developed through discovery.

B.  Platform and Architecture Identification

The opening interrogatory should ask the carrier to identify every software application, algorithm, expert system, decision-support tool, machine-learning (ML) model, or automated system used at any stage of claim handling on the claim at issue — including FNOL triage, coverage analysis, reserve setting, severity evaluation, medical-bill review, fraud scoring, litigation-risk scoring, settlement-authority determination, and final valuation. For each, require vendor, product name, version, and dates of use. Follow with document requests for the license or service agreement with each vendor, the user manual, the carrier’s training materials, and the vendor’s methodology documentation.

This is lawyer-reviewable foundation work. The practitioner who skips this step and goes straight to requesting “Colossus data” may miss the other systems that also touched the claim. Expert review is not needed at this phase. Cost: modest.

C.  Tuning and Governance

For rules-based expert systems, the critical evidence is the carrier’s tuning: the severity-point values, dollar-per-point tables, jurisdictional modifiers, value-driver weightings, and any carrier-specific custom rules in effect during the claim. Request the current tuning parameter set, the historical tuning change log (with dates, approvers, and stated rationales for each change), and any internal communications, consulting reports (McKinsey-style engagements have historically been produced in Colossus cases), or loss-ratio analyses that drove tuning decisions. This is where the Allstate McKinsey documents in the multistate litigation emerged — carrier-internal documents showing tuning was deliberately calibrated to reduce claim payments.

For machine-learning (ML) systems, the analog is the Artificial Intelligence (AI) governance framework: the carrier’s written policy on model development, acquisition, validation, monitoring, human oversight, risk management, internal controls, third-party-vendor oversight, and consumer-impact review; model cards or equivalent documentation; intended-use materials; performance metrics; known limitations; fairness testing and bias audits; retraining schedule documentation; and regulatory correspondence. The NAIC Model Bulletin supplies the practical checklist. It does not dictate the plaintiff’s discovery rights, but it identifies the governance and documentation categories regulators expect insurers to have available when AI systems affect consumers. A carrier that used AI in claim handling but cannot identify an AI governance program, risk-management controls, vendor oversight, validation materials, or consumer-impact documentation has created a discovery fact that matters even before the merits of the model are reached.

Production format: tuning parameters as an Excel spreadsheet or matrix with legend (lawyer-readable); change logs as Excel with dates and narrative rationale (lawyer-readable); tuning memoranda and governance frameworks as native Word or Portable Document Format (PDF) (lawyer-readable). Little expert assistance required at this layer; most of the value can be extracted by counsel. Cost: modest to moderate.

D.  Claim-Specific Inputs, Outputs, and Audit Trails

Request the complete session data for each time the system was run on the claim: every field, every entered value, every severity code selected, every value driver activated or deactivated, every override, and the output (range, itemized contribution of inputs where the system produces it, and any alternate scenarios). Request the audit trail showing who ran the system, when, from what workstation, under what user credentials, and with what result. Multiple runs with varying inputs are common and revealing.

Format should be handled pragmatically. In the first round, ask for native or other reasonably usable exports with associated metadata sufficient to show the claim-specific inputs, outputs, timestamps, users, routing, edits, access history, and results. Do not assume at the drafting stage that the native format will be unreadable. Some exports will be usable in Excel or Comma-Separated Values (CSV) format without much translation. Others will not. If the first production is not reasonably usable, the follow-up request should ask for the rendered report, chronological export, screenshots, session replay, data dictionary, lookup table, code legend, or witness explanation necessary to make the production usable for deposition and motion practice.

This sequencing also improves proportionality. If the carrier produces readable exports and the software adds nothing, counsel can stop. If the carrier produces coded data, unexplained logs, or incomplete metadata, counsel has a concrete basis to demand lookup tables, code legends, data dictionaries, or a corporate-representative witness. And if the production shows repeated runs, unexplained edits, hidden users, missing access history, or a serious dispute over what the software did, counsel can then justify deeper technical discovery and expert review.

E.  Machine-Learning Model Artifacts, Training Data, and Validation

For machine-learning (ML) systems, Track B deepens. Request the exact model version that processed the claim — a version identifier or hash plus the serialized model file in its native format (common formats include Pickle, the Open Neural Network Exchange format (ONNX), TensorFlow SavedModel, or Predictive Model Markup Language (PMML)). Request the feature definitions and feature engineering pipeline showing how raw data becomes model input. Request the training dataset or, where volume is prohibitive, a statistically valid sample plus summary statistics, data dictionary, and provenance documentation. Request validation and testing reports — accuracy on held-out data, subpopulation performance, fairness audits. Request ongoing monitoring reports: drift detection, performance degradation alerts, retraining triggers.

Model artifacts are different. The serialized model file, feature pipeline, and raw technical environment are usually expert-only materials. Model cards, validation reports, and governance documents, however, are often lawyer-readable prose documents. A practical strategy is to request the governance and validation materials first, have counsel review them, and escalate to raw technical artifacts only if that review shows the model evidence may matter.

Where the carrier refuses on trade-secret grounds, two responses: propose a tiered protective order (confidential, attorneys-eyes-only, outside-expert-only) that has been the workable resolution in Colossus-line cases for two decades; and narrow the request to what is necessary — the model that scored this claim, not the entire model library; the training data provenance and date range, not necessarily every training record. Proportionality objections under the 2027 amendment to Missouri Rule 56.01(b)(6)(C) will be sharper than before, so tailor accordingly.

F.  Artificial Intelligence Audit Logs

A category that deserves its own treatment, because it is both distinct from general metadata and sometimes a revealing source of evidence in an Artificial Intelligence (AI)-driven claim matter. Modern Artificial Intelligence (AI) platforms — whether vendor-provided, embedded inside claims-management platforms, or internally built — may generate audit or interaction records depending on the tool, configuration, license, retention policy, and whether the carrier enabled the relevant logging features. These records are operationally distinct from the claim-file audit trail discussed in Section IV.D and from the machine-learning (ML) model artifacts discussed in Section IV.E. When they exist, they may capture the adjuster’s or analyst’s use of the Artificial Intelligence (AI) tool on the claim.

Depending on the platform and configuration, AI-related audit evidence may include five categories, each with different evidentiary value.

1.  User information

Identifies who initiated each Artificial Intelligence (AI) interaction — user identifier, role or title, department, session identifier, workstation, and location. In a claims matter the value is obvious: establishing which adjuster, supervisor, Special Investigations Unit (SIU) investigator, coverage analyst, staff counsel, or other user accessed the electronic claim file, ran the claims-evaluation software, reviewed an Artificial Intelligence (AI) output, or touched the claim during the relevant period. These records can identify the practical decision-makers, not just the names that appear in the claim notes. Creates the human chain that connects the automation to accountable decision-makers. Format: lawyer-readable once tabulated (Excel or Comma-Separated Values (CSV) export with session identifiers). Minimal expert assistance required. Request specifically: the identity of every user who ran any Artificial Intelligence (AI) query referencing the claim, accessed the claim through an Artificial Intelligence (AI) tool, or used claims-evaluation software on the claim, by claim number or by time window during claim pendency.

2.  Interaction data

The exact prompt the user sent to the Artificial Intelligence (AI) system and the exact response the system returned, typically stored in JavaScript Object Notation (JSON) format. This is the heart of the log. If an adjuster asked a large language model to “summarize reasons to deny this claim under the intentional acts exclusion,” that prompt is discoverable and it is evidence. If the adjuster prompted neutrally and the model produced a balanced analysis that the adjuster then disregarded to deny the claim, that too is evidence. Leading prompts, prompts designed to extract denial-supporting language, and prompts that omit material facts are all visible in the interaction record and all rich grounds for bad-faith and vexatious-refusal argument.

Format should be handled under the staged approach. Request the native JavaScript Object Notation (JSON) or other reasonably usable export first if the system maintains it, because that preserves the technical record and allows completeness testing. After reviewing what is produced, request a rendered transcript in Portable Document Format (PDF), Microsoft Word, or another lawyer-readable form if the native export is coded, incomplete, or not reasonably usable for deposition and motion practice. Most carriers that use these systems will have some internal compliance method for reviewing interaction records; if the carrier can review the record internally, counsel should ask for the form or explanation necessary to review it in litigation.

3.  Metadata

Distinct from the general metadata discussion in Section IV.H, Artificial Intelligence (AI)-specific metadata includes timestamps at millisecond precision, application name and version, model identifier and version, tenant identifier, session identifier, geographic and network location, and critically, any security or governance policies that fired during the interaction. Modern Artificial Intelligence (AI) platforms log policy triggers such as Personal Identifiable Information (PII) redaction applied, sensitive-data guardrail engaged, content-moderation flag raised, human-review escalation recommended, or coverage-opinion disclaimer inserted. A policy trigger showing that the system recommended human review on a claim where no human review occurred is direct evidence of policy violation.

The same dual-format approach applies. Tabular extracts of policy triggers with timestamps and descriptions are lawyer-readable and high-value. Raw metadata structures are expert territory but should be requested in native format for verification.

4.  Contextual data

Modern Artificial Intelligence (AI) tools, particularly those using retrieval-augmented generation or agentic capability, access external data sources to answer each query — claim files, medical records, policy documents, internal knowledge bases, vendor databases, websites, prior adjuster notes. The audit log records what was accessed. This is discoverable and often decisive. If the Artificial Intelligence (AI) tool was asked to evaluate coverage and the log shows it accessed the exclusions database and policy endorsements but not the insuring agreement, the analysis is structurally incomplete and the resulting denial is structurally indefensible. If the tool accessed materials outside the claim — for example, prior claims by the same claimant, social media, credit reports — that raises privacy and privilege issues and may reveal conduct the carrier would prefer not to display. If it accessed privileged materials (carrier’s coverage counsel work product) in generating an answer that was then shared with the adjuster, the privilege analysis is complicated and likely favorable to the plaintiff.

Format: request a structured list (Comma-Separated Values (CSV) or Excel) of all data sources accessed per interaction, with timestamps and access paths. This is lawyer-readable with minimal translation once the source names are legible.

5.  Reasoning trace for agentic systems

The newest and least familiar category is the reasoning trace for agentic systems, where such systems are actually deployed and where the platform preserves the trace. Agentic Artificial Intelligence (AI) systems — those that plan and execute multi-step workflows rather than simply answering a single prompt — may generate records of the model’s plan, intermediate analytical steps, tool calls, and decision points before producing an output or taking an action. If an agent was deployed to triage claims, evaluate coverage, or recommend denial, the trace may show what the system considered, what it ignored, what alternatives it weighed, and why it produced the output it produced. In a fraud-referral or denial case, that record may matter if it connects the software to the claim decision.

Reasoning traces, if they exist, are typically stored in a structured format such as JavaScript Object Notation (JSON) or a vendor-specific log format and may require expert translation to extract maximum value. Ask first whether the system preserves such records, what retention policy applies, and whether a rendered narrative export is available. If the first answers show that reasoning traces exist and are potentially important, then request the native format, any rendered export, and the documentation necessary to understand the record.

Retention and preservation concerns specific to AI audit logs

Retention and preservation concerns specific to AI audit logs should be framed functionally rather than by assuming a universal retention period. AI-related evidence may reside in ordinary audit metadata, retained prompt-and-response records, application logs, Security Information and Event Management (SIEM) exports, Application Programming Interface (API)-management logs, model-monitoring records, vendor logs, and compliance or eDiscovery repositories. Retention can vary sharply by platform, license, configuration, and whether the record is audit metadata, interaction content, application telemetry, or a vendor-managed system log. The NAIC Model Bulletin is useful here because it expects insurers using AI systems to maintain governance, risk-management, internal-control, validation, monitoring, and third-party-oversight documentation sufficient for regulatory examination or investigation. The discovery request should therefore be functional: identify and preserve all records showing who used the AI tool, when it was used, what claim or data sources it accessed, what task or prompt was submitted if retained, what response or output was returned if retained, what model or version generated the output, what guardrail, policy, Data Loss Prevention (DLP), fairness, bias, or human-review trigger fired, and what vendor or internal system maintained the record. The issue is not whether every platform stores a single complete “AI audit log.” The issue is whether the carrier can account for the AI-supported claim decision through the records its own governance framework, vendor contracts, retention policies, and regulatory obligations should have required it to maintain.

Practical limits

Two caveats. First, not every carrier has deployed Artificial Intelligence (AI) tools that generate logs of the type described above; the Platform and Architecture Identification interrogatory in Section IV.B is the threshold step to determine whether these records exist at all. Second, carriers may resist production of prompt-and-response content on claims of vendor confidentiality, trade secret, or work-product privilege where counsel used the tool. The work-product argument is the most serious and depends on whether the Artificial Intelligence (AI) tool was used by counsel or by claims personnel. For claims personnel running routine adjuster tasks, work-product protection is usually weaker. A tiered protective order often resolves vendor-confidentiality concerns. Claims of trade secret in prompting strategy should be tested against the actual need for confidentiality and the availability of a protective order.

G.  Human-Review Documentation

Request the carrier’s written policy on when human review of software output is required, and all documentation of actual human review on the claim — adjuster approvals, supervisor overrides, escalation memos, Special Investigations Unit (SIU) referrals. If the policy requires a human to review any denial or any valuation below a threshold but no such review is documented on the claim, the policy-violation predicate supports bad faith on its own.

This is lawyer-readable, high-value discovery. The carrier either produces the documentation or concedes it does not exist; either outcome is useful. Cost: minimal.

H.  Metadata and Hidden Data

The category most often underestimated by counsel. Every category above has metadata that sits beyond the visible document: creation and modification timestamps, authoring user identifiers, system of origin, version identifiers, access history, deletion history, and field-level change history. In modern claims platforms, a note that appears on the claim file may have been edited four times with the prior versions overwritten or retained in a shadow history depending on configuration. A valuation that appears as a single number may have been preceded by five earlier valuations that were replaced. Fraud or SIU flags may have been set and cleared.

Request metadata preservation in the litigation hold, specify metadata production in the format clause of the Request for Production, and include an interrogatory asking the carrier to identify all systems with field-level change history or version history capability for the claim. An expert is required to fully exploit metadata, but the lawyer can review summary reports (for example, a chronological list of all edits to the claim notes with dates and editors) and identify the ones worth having the expert pursue. Cost depends on how deep the expert goes; the initial summary reports are inexpensive to request.

V.  Format Specifications — The Practical Middle Ground

Format is where the case cost is won or lost. The following framework balances completeness with reviewability.

The ideal

The ideal production gives counsel both a practical view and a technical record: native or reasonably usable exports with metadata, plus whatever rendered report, chronology, data dictionary, lookup table, or code legend is necessary to understand the production. But the ideal need not always be demanded in full at the outset. If a native spreadsheet or exported activity history is readable, insisting on a duplicate Portable Document Format (PDF) version may add little and invite unnecessary objections. If the native production is unreadable, incomplete, or coded, then the follow-up request for a lawyer-readable version is not a luxury; it is the step necessary to make the production reasonably usable.

What’s actually achievable in practice

What is actually achievable in practice is usually learned after the first set of written discovery. Structured claims data may be readable as Comma-Separated Values (CSV) or Microsoft Excel if the field names and codes are understandable. Log files may require a chronology, data dictionary, or corporate-representative explanation. Model files in machine-learning (ML) cases remain expert-only, but model cards, governance materials, validation summaries, and vendor documentation may be lawyer-readable. The practical approach is to ask first for production in native or other reasonably usable form with the metadata needed to preserve the evidence, then use the first production to decide whether to demand a rendered export, additional translation materials, a deposition, or a consulting expert.

What to avoid asking for unless genuinely needed

Source code is rarely worth the fight. It is vendor trade secret, protective-order litigation is expensive, and functional equivalents (inputs, outputs, ruleset documentation, and expert testing) almost always suffice. Raw neural-network weights are useless without the inference pipeline and feature engineering; ask first for the model card and validation reports and escalate only if those are inadequate. Entire training datasets are frequently terabyte-scale; ask for the data dictionary, provenance documentation, statistical summary, and a sample first, and escalate only if those reveal a reason to go deeper.

Why sequencing drives case cost

The practical reality is that expert hours are the largest variable cost in software discovery. A consulting expert can spend many hours translating a log file into something the lawyer can use, before any substantive analysis occurs. Sequencing reduces that cost. First-round written discovery identifies the systems, records, users, audit capabilities, and retention problems. Counsel reviews what can be reviewed. If the production is readable and unimportant, the software issue ends. If it is unreadable but potentially important, counsel has a concrete basis to ask for translation materials or a witness. If it is both important and technically complex, then expert time is justified. The goal is not to avoid technical discovery; it is to avoid buying technical translation before knowing whether the translation matters.

VI.  Practical Reality Check — Sizing the Case Before You Spend

Software discovery is inherently speculative. Before the first production arrives, the lawyer does not know whether the case has a smoking gun, a moderate pattern, or nothing at all. A mature approach acknowledges that most cases fall in the second or third category, and builds the spending curve accordingly.

A.  The Three Likely Outcomes

The first possible outcome is the smoking gun: tuning memoranda directing loss suppression, session logs showing manipulation of inputs, validation reports revealing known bias, regulatory correspondence admitting violations. These cases settle or try for substantial numbers and justify heavy expert investment.

The second possible outcome is moderate support: consistent patterns of lowballing across the file, documentation gaps, missing or perfunctory human reviews. Builds the bad-faith narrative but is not dispositive by itself. The case can still be won on the combined strength of software evidence plus adjuster conduct plus liability picture, but the software evidence is supporting, not leading.

The third possible outcome is a nothing sandwich: the system was used and implemented properly, documented cleanly, and outputs are consistent with the fair claims practices. The case either lives or dies on grounds independent of the software — adjuster conduct, coverage analysis, liability dispute, the quality of the damages evidence.

B.  Signals the Case Is in the Software

Certain indicators raise the probability that software discovery will pay off. The carrier’s offer is dramatically lower than comparable verdicts or a reasonable demand. The carrier cannot explain how it arrived at the number when pressed. The adjuster’s claim notes reflect minimal independent analysis and rely heavily on a software-generated range. A pre-litigation request for the basis of the offer produced stonewalling rather than explanation. The claims files does not have a record that supports what was done in the actual claim. The specific system or the specific carrier’s calibration has been flagged in public reporting or prior litigation. When several of these indicators align, the software discovery is likely to produce useful material.

C.  Signals the Case Lives Elsewhere

Conversely, the following indicators suggest that the leverage point is not in the software. The carrier’s offer is defensible on the merits even if the plaintiff disagrees with it. The real fight is over coverage interpretation or liability, not damages methodology. The adjuster did substantive work independent of the software and can defend the evaluation in her own words. The damages are genuinely disputed on medical, causation, or liability grounds. The legal theory being asserted does not turn on mechanism but on outcome. In these cases, software discovery is at best a small supplement and at worst a distraction that dilutes litigation focus.

D.  When to Retain an Expert and Approximate Cost

A phased expert engagement matches investment to confirmed value. In the preservation and initial-request phase, counsel works alone, informed by reference materials and the system descriptions above. No expert is required to draft a litigation hold letter or an opening interrogatory set.

In the follow-up drafting phase after the first production, a consulting expert retained for five to ten hours at approximately three hundred to five hundred dollars per hour — roughly twenty-five hundred to five thousand dollars — can review the initial production, identify what is missing, and help counsel draft targeted follow-up requests. This is almost always worth doing, even on moderate cases.

In the deposition preparation phase, a consulting expert retained for fifteen to thirty hours — roughly seventy-five hundred to fifteen thousand dollars — can analyze the technical production, identify anomalies, and prepare the lawyer to take a Rule 57.03(b)(4) corporate deposition or the adjuster’s deposition with substantive technical questioning. Worth doing if counsel’s review has already confirmed that the software evidence is likely to be central.

A testifying expert at trial is a substantially larger commitment, typically thirty thousand to one hundred thousand dollars or more depending on scope, preparation, deposition, and trial testimony. Escalate to testifying expert only after the evidence from consulting review has confirmed that the software theory is both provable and case-central.

The cost estimates above are rough ranges based on market rates; actual costs depend on the complexity of the system, the volume of the production, and the expert’s market. Verify against current fee schedules before budgeting.

E.  When the Production Is a Nothing Sandwich

The lawyer should be willing to accept this result and reorient. If the production is a nothing sandwich, that should not be a crisis. A bad-faith case should not be taken on the hope that a computer system will eventually produce the evidence that makes the case. Software discovery is a way to test and potentially strengthen an existing theory, not a substitute for one. If the claim-handling facts, coverage position, liability picture, damages evidence, communications, timing, or settlement conduct support the case independent of the software, proceed on those grounds and drop the software angle. If the production shows the system added nothing meaningful, the right move is to stop spending expert money on it and redirect the remaining discovery budget toward witnesses, documents, and conduct that actually matter. What does not work is persisting in a software-driven narrative after the production fails to support it; that path leads to bloated expert costs, weak exhibits, and a trial presentation that the carrier will dismantle.

VII.  Proportionality and the Need for Additional Discovery

Bad-faith and vexatious-refusal cases often require more written discovery and more depositions than an ordinary tort case. That is not because plaintiff’s counsel wants a broader fight. It is because the claim itself puts the insurer’s internal claim handling, evaluation process, settlement authority, supervisory review, software use, document-retention practices, and decision-making chain directly at issue. Missouri Rule 56.01(b)(1) permits discovery that is relevant and proportional to the needs of the case, considering the totality of the circumstances, including the importance of the issues, the amount in controversy, the parties’ relative access to relevant information, the parties’ resources, the importance of the discovery in resolving the issues, and whether the burden or expense outweighs the likely benefit. The proportionality factors therefore support case-specific expansion where the insurer has the information, the amount at stake is substantial, and the plaintiff must prove more than an ordinary contract dispute.

The updated Missouri discovery rules make that argument more focused, not weaker. Missouri’s revised discovery rules brought Missouri practice closer to the Federal Rules of Civil Procedure, added express Electronically Stored Information (ESI) provisions, and limited discovery to information that is both relevant and proportional to the needs of the case. See Thompson Coburn, “What You Need to Know About Missouri’s Updated Discovery Rules”; Thompson Coburn, “Changes to Missouri Discovery Rules Made Official by Missouri Supreme Court”. The point for bad-faith practice is that proportionality is not a numerical cap dressed up as a balancing test. It is a reasoned inquiry into whether the discovery sought is justified by what the case is about. Where the insurer’s conduct is the issue, proportionality often supports additional interrogatories, targeted document requests, and more than the ordinary number of depositions because those tools are the only practical way to reconstruct how the claim was handled.

Several proportionality factors usually point in the same direction. First, the amount in controversy is often large because the case may involve the underlying covered loss, excess exposure, consequential damages, statutory interest, attorney fees, and, in the right case, punitive-damages exposure. Second, the relative access factor strongly favors the insured. The carrier controls the claim file, reserve history, internal communications, evaluation software, authority structure, manuals, guidelines, training materials, vendor documents, audit trails, and the witnesses who made or approved the decisions. Third, the discovery is important to resolving the issues because common-law bad faith and statutory vexatious refusal focus on different legal inquiries but both require close examination of the insurer’s claim handling. Bad faith discovery often turns on the insurer’s decision-making process, knowledge, motives, settlement authority, and handling of excess exposure. Vexatious-refusal discovery focuses more directly on whether the insurer had a reasonable cause or excuse for refusing payment, judged from the information available when payment was withheld or denied. In both settings, the timing of decisions, the information available to the insurer, the basis for nonpayment or nonsettlement, and the identity of the people who made or approved the decision are central. Fourth, in a Bad Faith case the proof burden is higher than in an ordinary negligence case: the plaintiff must usually show an intentional state of mind. That burden makes access to the insurer’s internal reasoning and decision chain essential.

The number of witnesses also matters. A serious bad-faith case may involve the front-line adjuster, claim supervisor, manager, coverage analyst, Special Investigations Unit (SIU) personnel, reserve or authority committee members, staff counsel or coverage counsel depending on privilege rulings, information-systems witnesses, software-vendor or claims-technology witnesses, and a Rule 57.03(b)(4) corporate representative. Ten depositions may be enough in some cases, but it is not hard to identify cases where the standard limit does not fit the issues. The same is true of the twenty-five-interrogatory structure: identifying every system, custodian, vendor, retention policy, authority level, decision-maker, and claim-specific software record may require carefully drafted written discovery beyond a basic form set. Missouri Rule 57.03 requires leave of court or stipulation if the deposition count exceeds the rule’s limit, and Rule 56.01’s proportionality standard supplies the practical argument for that leave when the additional discovery is targeted, sequenced, and tied to issues the insurer actually placed in dispute.

The better practice is to frame any request for expanded discovery as proportional, phased, and efficient. The motion should not ask for “more discovery” in the abstract. It should identify the specific additional interrogatories, document categories, or depositions needed; explain why the information is uniquely within the insurer’s possession; tie each item to an element of bad faith, vexatious refusal, damages, punitive exposure, or software-supported claim handling; and show why the burden is justified by the amount in controversy and the importance of the evidence. A court is much more likely to allow additional discovery when counsel can show that the requested discovery is not cumulative, cannot be obtained from a less burdensome source, and is sequenced to avoid unnecessary cost.

That proportionality showing also fits the software-discovery framework in this article. Counsel should first use written discovery to identify the systems, custodians, vendors, and retention obligations, then take a focused corporate-representative deposition to learn what exists, and only then serve targeted follow-up requests or seek additional depositions. This sequencing demonstrates proportionality because it narrows the dispute before the expensive discovery occurs. If the software evidence is a nothing sandwich, the extra discovery stops. If the discovery shows that software, hidden decision-makers, missing records, or unexplained access history mattered, the record supports additional discovery under Rule 56.01 and a case-specific order allowing the discovery necessary to reach the merits.

VIII.  Suggested Sequencing to Minimize Sunk Cost

A five-phase sequence should minimize sunk cost while reflecting the reality that counsel usually does not know at the outset whether AI claims evaluation software, a rules-based system, or any meaningful software tool touched the claim. The goal is to identify what systems exist, what records should exist, and whether the software evidence matters before committing major expert money.

Phase One, at or before filing: assess preservation against existing obligations. Review the claim-file retention rules, the known claim-handling timeline, any indication of software-assisted handling, and whether a preservation letter would improve the record. A hold letter is an option in this phase, not an automatic step. In the right case, it may be the safest way to protect unknown technical records. In another case, counsel may choose to rely initially on Missouri claim-file obligations, internal retention policies, vendor obligations, and later discovery to test what should have been preserved. Cost: counsel time only.

Phase Two, first-round written discovery: use interrogatories and document requests to identify every system used, every vendor, every custodian, every category of claim-specific software record, the audit-trail and version-history capabilities of each system, the users who accessed the claim or software, the retention policies governing those records, the search methodology used to collect electronically stored information, the location of servers, cloud repositories, backups, and disaster-recovery sources, and whether any data was deleted, overwritten, or destroyed. Ask for native or other reasonably usable exports with associated metadata sufficient to show what happened. Do not assume at this point that every native format will be unreadable or that every category requires duplicate lawyer-readable production. Cost: counsel time only.

Phase Three, review and targeted clarification: review the carrier’s written answers and first production to decide whether the data is usable, what systems actually matter, and what is missing. If the production is readable and reveals no meaningful software issue, stop spending money on the software angle. If the production shows applicable systems but the exports are coded, incomplete, or not reasonably usable, request the data dictionaries, lookup tables, code legends, chronological exports, rendered reports, screenshots, session replays, or explanatory witness testimony needed to make the production usable. If the responses identify fragile or short-lived records, consider a preservation-confirmation request at that point. Cost: counsel time, with limited consulting expert input only if needed.

Phase Four, architecture deposition and targeted follow-up production: if the first round shows that claims-evaluation software, audit trails, hidden decision-makers, missing records, or unclear retention practices may matter, take a Rule 57.03(b)(4) corporate representative deposition on information-systems architecture, claim-file workflow, claims-evaluation software, Artificial Intelligence (AI) governance, access logging, retention settings, vendor systems, search methodology, and who accessed or used the electronic claim file. Then serve targeted follow-up requests informed by the testimony — tuning parameters, claim-specific session data, access logs, rendered software outputs if needed, model artifacts if a machine-learning (ML) system was used, human-review documentation, metadata, data dictionaries, and retention-policy materials. Cost: counsel time plus modest deposition expense; consulting expert engaged if the production indicates technical review may add value.

Phase Five, expert engagement and merits depositions: if the clarified production and architecture testimony show useful software evidence, a consulting expert reviews the technical materials and helps prepare the adjuster’s deposition, the supervisor’s deposition, the information-systems witness, and any Artificial Intelligence (AI) governance representative. A testifying expert should be engaged only if consulting review confirms that the software evidence is both provable and case-central. If the production is a nothing sandwich, stop spending expert money there and proceed on the claim-handling, coverage, liability, damages, timing, communications, or settlement-conduct evidence that actually supports the case. Cost: potentially the largest expense phase, but only after the evidentiary basis has been confirmed.

IX.  A Candid Word on Expectations

Not every case has a software-driven leverage point, and the industry-wide enthusiasm for Colossus discovery in the past produced both spectacular verdicts but even more nothing-sandwich productions. The value of a disciplined approach to this work is not that every case yields a smoking gun but that the lawyer who knows what to ask for can tell quickly whether there is one, and can allocate litigation investment accordingly.

Technology discovery is genuinely outside most lawyers’ comfort zones, and two opposite errors are common. The first is to avoid the area entirely and miss the evidence that in the right case would have been dispositive. The second is to hand the whole area off to a testifying expert at the outset and spend fifty thousand dollars before knowing whether the case warrants any of it. The middle path — counsel fluent enough in the technology to draft the hold letter, the opening interrogatories, and the Phase Three deposition without expert assistance, and to recognize when the production merits escalation — is both practically and economically the correct posture.

A final observation: the carrier’s production will frequently be the first real test of whether the case is what it appeared to be at intake. A practitioner should approach that moment with an open mind, because the software evidence either expands the case or redirects the litigation to grounds that were always the real leverage point.

X.  Legal Authority for Staged ESI Production and Reasonably Usable Follow-Up

A natural question once staged software discovery is understood: is later follow-up for native data, readable exports, metadata, or translation materials supported by the rules and case law, or is it merely a practitioner preference the carrier can refuse on authority? The answer is that it is supported — clearly under Missouri’s current rules, and substantially under the federal framework, the Sedona Conference Principles, and the dominant weight of federal case law — although the better practice is to sequence the issue. Ask first for native or reasonably usable production sufficient to identify what exists. If the production is unreadable, incomplete, or stripped of useful metadata, then request the additional form, export, data dictionary, or code legend necessary to make the production reasonably usable.

A.  Missouri Rules (Current Law)

Missouri expressly adopted Electronically Stored Information (ESI) discovery provisions through Senate Bill 224 (2019), effective August 28, 2019, with further revisions effective September 2, 2021. Missouri Supreme Court Rule 56.01(a) now expressly includes ESI within the methods of discovery. Missouri Supreme Court Rule 58.01(a)(1) expressly permits discovery of ESI. Most importantly for present purposes, Missouri Supreme Court Rule 58.01(b)(1)(C) expressly permits the requesting party to specify that ESI be produced in native format. Missouri Supreme Court Rule 56.01(b)(3) creates an exception for ESI that is not reasonably accessible because of undue burden or cost, mirroring the federal framework. Missouri Supreme Court Rule 56.01(b)(1) imposes the proportionality standard, and the forthcoming amendment to Rule 56.01(b)(6)(C) effective January 1, 2027 (Order No. 3156) will sharpen proportionality analysis further.

Missouri’s rule on “method of production” is Missouri Supreme Court Rule 58.01(c)(4), which gives the producer the choice of producing documents as kept in the usual course of business or organizing and labeling them to correspond to request categories. See Adam S. Davis, “Beyond the Usual Course: Producing Documents Under the Discovery Rules,” Missouri Bar Journal (Jan. 2020) (discussing Rule 58.01(c)(4) mechanics and federal parallels). Missouri practice has long given broad reach to ESI discovery in the possession, custody, or control of the responding party, Hancock v. Shook, 100 S.W.3d 786 (Mo. 2003), and the 2019 and 2021 amendments now supply the express ESI-format framework that Missouri previously lacked.

For overviews of the Missouri rule changes and their federal-rules analog, see Thompson Coburn, “What You Need to Know About Missouri’s Updated Discovery Rules” (Sept. 17, 2019); Thompson Coburn, “Changes to Missouri Discovery Rules Made Official by Missouri Supreme Court” (2021); Hennessy & Roach, “Missouri’s (Now Official!) New Discovery Rules” (Apr. 2021); Tueth Keeney, “Missouri Supreme Court Updates Civil Discovery Rules”; and Capes Sokol, “Significant Changes Coming to Missouri Trial Practice: Discovery Limits”.

B.  Federal Rule 34 and Its Three-Part Framework

Federal Rule of Civil Procedure 34(b)(2)(E) governs the form of Electronically Stored Information (ESI) production under three subparts. See Fed. R. Civ. P. 34 (Cornell Legal Information Institute). Subpart (i) provides that documents must be produced as kept in the usual course of business or organized and labeled to correspond to request categories. Subpart (ii) provides that if the request does not specify a form, ESI must be produced in the form in which it is ordinarily maintained or in a reasonably usable form. Subpart (iii) states that a party need not produce the same ESI in more than one form.

Subpart (iii) is the provision carriers invoke to resist later requests for an additional form of production. The key practitioner insight is that (iii) is a default, not a prohibition. The rule permits the requesting party to specify a form under Rule 34(b)(1)(C), permits stipulation, and permits the court to order a different or additional form for good cause. The staged approach preserves the argument without overreaching: ask first for native or reasonably usable production, review whether it is actually usable, and then seek the readable export, metadata, data dictionary, or code legend necessary to make the production meaningful.

The practitioner who specifies the form at the outset under Rule 34(b)(1)(C) preserves the argument. Failing to specify is the single most common source of ESI-format disputes. See ILS, “The Choice Is Yours: ESI Production Under FRCP 34” (collecting cases on waiver of format specification).

C.  The “Reasonably Usable” Standard and When PDF Fails

The dominant line of federal authority holds that production of Electronically Stored Information (ESI) in Portable Document Format (PDF) or Tagged Image File Format (TIFF) stripped of metadata is not a reasonably usable form, and courts have repeatedly ordered re-production in native format when the initial production was degraded. The most recent and on-point case is Blevins-Clark v. Beacon Communities, LLC, 2025 U.S. Dist. LEXIS 189822 (E.D. Ky. Sept. 26, 2025), where the court held that producing native files as Portable Document Format (PDF) without metadata was not reasonably usable, with Judge Stinnett writing that “producing documents without the underlying metadata is the equivalent of manufacturing a car without an engine — a shell without much use.” See Logikcull, “FRCP Rule 34 in Practice: PDF Production Without Metadata Is Not Reasonably Useable” (Feb. 2026) (discussing Blevins-Clark).

The seminal earlier decision is Bray & Gillespie Management LLC v. Lexington Insurance Co., 2009 U.S. Dist. LEXIS 21250 (M.D. Fla. Mar. 4, 2009), where the court held that converting ESI to TIFF stripped of metadata eliminated the search capabilities available in native form and therefore did not satisfy Rule 34’s reasonably-usable requirement. See Bow Tie Law, “Name That Form of Production: Converting ESI to TIFF Without Metadata Is Not a Reasonably Useable Form” (case summary and analysis by Josh Gilliland).

The Illinois state court case Kamuda v. Sterigenics U.S., LLC (Cook Cty. Cir. Ct. 2020) is instructive for state-court practice: Judge Christopher Lawler ordered all ESI produced in native format over the defendants’ offered compromise of a TIFF-plus-native hybrid, relying in part on the Sedona Principles, Third Edition. See CloudNine, “Court Orders Defendants to Produce All ESI in Native Format” (summarizing the Kamuda ruling).

Other important decisions supporting native or metadata-inclusive production include Echavarria v. Roach, 2018 U.S. Dist. LEXIS 216021 (D. Mass. Dec. 26, 2018) (production must be organized, metadata matters); City of Colton v. American Promotional Events, Inc., 2011 U.S. Dist. LEXIS 126848 (C.D. Cal. Oct. 13, 2011) (Rule 34(b)(2)(E)(i) applies to ESI; ordering re-production in native format with metadata or categorization by request); and Landry v. Swire Oilfield Services, L.L.C., 2018 U.S. Dist. LEXIS 885 (D.N.M. Jan. 3, 2018) (form of production cannot be degraded by the producing party). See generally Bow Tie Law, “Organizing a Production Pursuant to Federal Rule of Civil Procedure Rule 34(b)(2)(E)” (Dec. 2018); Bow Tie Law, “Adventures in Statutory Construction of FRCP Rule 34(b)(2)(E)” (discussing City of Colton).

The counter-line of authority should also be understood. Where the requesting party fails to specify a format in the initial request and the producing party makes a reasonably-usable production, courts have generally declined to order re-production. The lesson is procedural: specify format in the Rule 34 request or its Missouri analog, and raise the issue at the Rule 26(f) or equivalent conference.

Representative of that line: Babakhanov v. Ahuja (S.D.N.Y. 2023) (denying motion to compel native production of electronic medical records where Portable Document Format (PDF) production was reasonably usable and no format was initially specified); Bah v. Han-Dee Hugo’s (E.D.N.C. Sept. 2024) (denying motion for additional metadata where TIFF plus text production matched parties’ joint discovery plan). See Kilpatrick Townsend, “Crafting Customized ESI Agreements in E-Discovery” (Apr. 2025) (collecting the “reasonably usable” line of cases); eDiscovery Today, “No Additional Metadata for You, Court Tells Plaintiff” (Oct. 2024) (discussing Bah).

D.  The Sedona Conference Principles

The leading treatise on Electronically Stored Information (ESI) discovery is The Sedona Principles, Third Edition: Best Practices, Recommendations & Principles for Addressing Electronic Document Production, 19 Sedona Conf. J. 1 (2018). Available at thesedonaconference.org. Principle 12 addresses metadata and has been revised through each edition; the current position, reflected in the 2007 Second Edition revision that carried forward to the Third Edition, favors production in native format with metadata as the default, moving away from the earlier TIFF-plus-load-file approach. Principles 1 through 3 address the attorney’s supervisory duty, reasonable quality measures, and the goal of reducing cost and improving completeness in the e-discovery process.

For the specific problem of discovery from databases — directly applicable to Colossus, Liability Navigator, ClaimIQ, and modern claims-management systems — see The Sedona Conference Database Principles: Addressing the Preservation and Production of Databases and Database Information in Civil Litigation, 15 Sedona Conf. J. 171 (2014), available at thesedonaconference.org. The Database Principles specifically address the functional-purpose analysis, the handling of field-level data and lookup tables, and the proportionality of whole-database versus targeted-extract production. For practitioners working a case against a carrier’s claims system, the Database Principles are the closest single resource to a roadmap.

See also The Sedona Conference Commentary on ESI Evidence & Admissibility, Second Edition (public comment edition available at thesedonaconference.org/publications); and the broader Sedona catalog for practice commentary on legal holds, cooperation, search methods, and protective orders.

E.  Court-Endorsed Hybrid Production Protocols

The most practical authority for staged production is the hybrid-production protocol developed by federal courts in their local Electronically Stored Information (ESI) principles. The United States District Court for the District of Maryland has published detailed ESI Principles that include in Appendix 2.1 a “Hybrid Production Protocol” permitting native production for appropriate materials alongside static-image Bates-numbered placeholders, load files, metadata, and extracted text. The protocol explains in its question-and-answer section that production of TIFF-only images strips application and user-created metadata — formulas, tracked changes, speaker notes, comments — that are “evidence, like margin notes on paper documents,” and should not be eradicated from production.

Federal courts routinely publish sample ESI Protocols on their websites. For broader guidance on when and how to insist on one, see Kilpatrick Townsend LitSmart, “Warning: Follow Your ESI Protocol Because the Court Will — Part One” (collecting authority on enforcement of ESI protocols).

F.  Practitioner Commentary and the Craig Ball Approach

Among practitioners, Craig Ball is widely regarded as the leading commentator on form of production. His blog Ball in Your Court, particularly the post “Clarify Requests for Native ESI” (Aug. 2022), provides model language for native-format requests and explains why TIFF-plus-load-file productions are often larger and less useful than native-plus-metadata productions. The practical point is consistent with the staged framework: preserve the technical record where it matters, use static-image format where redaction or Bates placeholder practice requires it, and demand a second form only when the first form is not reasonably usable for the purpose at hand.

For the plaintiff-side perspective with particular attention to cost and practical access, see Advocate Magazine, “Demystifying ESI for Plaintiffs’ Lawyers” (Feb. 2022) (discussing the duty to preserve, the person-most-qualified deposition as a tool for learning what ESI exists, and the format-specification mechanics in both federal and California state practice). On the mechanics of form of production and the reasonably-usable standard generally, see Troutman Pepper Locke, “What Is a ‘Reasonably Useful Form’ for Production of ESI?” (JD Supra, Mar. 2020); FindLaw, “eDiscovery Federal Rule 34: Forms of Production”; and Lexology, “Best Practices for e-Discovery Production”.

G.  Practical Takeaway

The authorities above support a staged approach in three convergent ways. First, Missouri’s current rules expressly permit the requesting party to specify native format or another reasonably usable form of production. Second, the federal “reasonably usable” standard, as applied in Blevins-Clark, Bray & Gillespie, Kamuda, and related cases, establishes that a Portable Document Format (PDF) production stripped of useful metadata may be inadequate where native format or metadata is necessary to understand the evidence. Third, the Sedona Principles and federal local-rule Electronically Stored Information (ESI) protocols support practical, case-specific production methods in complex cases. The practitioner who asks first for native or reasonably usable exports, reviews what is produced, and then demands a readable export, metadata, data dictionary, lookup table, or technical file only when the first production shows the need is operating within the mainstream of current Electronically Stored Information (ESI) practice.

The one real constraint is the rule-based objection that a party should not have to produce the same Electronically Stored Information (ESI) in more than one form without a demonstrated reason. That is why sequencing matters. If the first production is reasonably usable, counsel may not need a second form. If the first production is coded, incomplete, stripped of metadata, or impossible to use in deposition or motion practice, the later request is not duplication for its own sake. It is a request for the form or explanatory materials necessary to make the production usable and to test whether the carrier’s claim-handling account is complete.

XI.  Sources for Further Research

The following bibliography collects the sources referenced throughout this memo, organized by topic, with direct hyperlinks. All sources were verified accessible at the time of drafting. Primary legal sources (rules, cases) should be verified independently on Lexis before use in a brief.

Claims-Evaluation Software: History, Architecture, and Current Use

Aaron DeShaw, “AI Expert Systems for Demand Letters,” Settlement Intelligence (June 2025)  (history of Colossus, Liability Navigator, ClaimIQ, Guidewire as expert systems).

Aaron DeShaw, “Why Do You Need AI Demand Letter Technology to Maximize Settlement Offers,” Settlement Intelligence (2022)  (industry adoption figures; use of software as cost-containment).

Aaron DeShaw, “Colossus Demand Letters by Settlement Intelligence” (Aug. 2023)  (detailed Colossus architecture and value drivers).

Mark C. Blane, “InjuryIQ Computer Program and Colossus Accident Claims Software”  (identifies the four major bodily-injury evaluation programs and their owners).

Mark C. Blane, “What Is Claims Outcome Advisor (COA)?”  (Claims Outcome Advisor / Liability Navigator architecture, 18,000-condition database).

AutoAccident.com, “What Is Colossus?”  (Colossus severity-points system; practitioner strategy for working with and around the system).

Hoffmann Personal Injury, “Colossus Settlement Calculator in Missouri” (Jan. 2026)  (Missouri-specific practitioner overview).

Morgan & Morgan, “Colossus Claims Software: How It Can Unfairly Deny Valid Claims” (Dec. 2025)  (plaintiff-side critique and litigation approach).

OBX Law / Glover Law, “Beating Colossus Insurance Software” (Dec. 2025)  (Duties Under Duress value driver analysis).

Shattered Documentary, “Colossus: The Controversial History of Claims Management Software” (Nov. 2025)  (Australian origin, regulatory history).

Artificial Intelligence in Insurance Claims

National Association of Insurance Commissioners (NAIC), “Model Bulletin on the Use of Artificial Intelligence Systems by Insurers” (adopted Dec. 4, 2023)  (governance, documentation, and transparency requirements; state adoption varies).

PBS NewsHour, “How Patients Are Using AI to Fight Back Against Denied Insurance Claims” (Jan. 2026)  (reporting NAIC 2025 survey results on AI use in health insurance).

Counterforce Health, “Fighting AI Driven Insurance Denials” (2025 Guide)  (CMS guidance, California SB 1120, consumer-protection framework).

McCormick & Murphy, “How AI Technology Is Changing Car Insurance Claims Processing in 2025” (Dec. 2025)  (AI applications in auto claims processing; bias and explainability concerns).

Aptarro, “Top 10 AI Insurance Claims Processing Software for 2026”  (current vendor landscape).

Federal ESI Framework: Rules and Key Cases

Federal Rule of Civil Procedure 34 (Cornell Legal Information Institute)  (full text with Advisory Committee Notes, 2006 and 2015 amendments).

Logikcull, “FRCP Rule 34 in Practice: PDF Production Without Metadata Is Not Reasonably Useable” (Feb. 2026)  (discussing Blevins-Clark v. Beacon Communities, LLC, 2025 U.S. Dist. LEXIS 189822).

Bow Tie Law (Josh Gilliland), “Organizing a Production Pursuant to Federal Rule of Civil Procedure Rule 34(b)(2)(E)” (Dec. 2018)  (Echavarria v. Roach; Landry v. Swire; form-of-production fundamentals).

Bow Tie Law, “Adventures in Statutory Construction of FRCP Rule 34(b)(2)(E)”  (City of Colton v. American Promotional Events analysis).

Bow Tie Law, “Name That Form of Production: Converting ESI to TIFF Without Metadata Is Not a Reasonably Useable Form” (May 2009)  (analysis of Bray & Gillespie Mgmt. LLC v. Lexington Ins. Co.).

CloudNine, “Court Orders Defendants to Produce All ESI in Native Format” (Jan. 2020)  (Kamuda v. Sterigenics U.S., LLC — Illinois state ruling applying Sedona Principles).

Electronic Discovery Law, “Production of ESI in Paper Format Does Not Comply with Rule 34” (Aug. 2008)  (native production with metadata ordered).

Kilpatrick Townsend, “Crafting Customized ESI Agreements in E-Discovery” (Apr. 2025)  (Babakhanov v. Ahuja; Dewey v. Bechthold; Urban 8 Fox Lake Corp. v. Nationwide Affordable Housing Fund 4 LLC; model language for ESI agreements).

eDiscovery Today, “No Additional Metadata for You, Court Tells Plaintiff” (Oct. 2024)  (Bah v. Han-Dee Hugo’s — limits on metadata when production is reasonably usable).

ILS, “The Choice Is Yours: ESI Production Under FRCP 34”  (Mudbug, Inc. v. Bloomin’ Brands; State Farm Mutual v. Universal Rehab; Wai Feng Trading v. Quick Fitting — waiver of format specification cases).

Troutman Pepper Locke (via JD Supra), “What Is a ‘Reasonably Useful Form’ for Production of ESI?” (Mar. 2020)  (overview of the reasonably-usable standard).

FindLaw, “eDiscovery Federal Rule 34: Forms of Production”  (plain-language summary of the three-part framework).

Lexology, “Best Practices for e-Discovery Production”  (near-paper versus native format; load files; metadata preservation).

Missouri ESI Rules and Practice

Missouri Supreme Court Rules 56.01 and 58.01  (current rule text on scope of discovery and document production).

Thompson Coburn, “What You Need to Know About Missouri’s Updated Discovery Rules” (Sept. 17, 2019)  (Senate Bill 224 overview; native format provision).

Thompson Coburn, “Changes to Missouri Discovery Rules Made Official by Missouri Supreme Court” (2021)  (September 2, 2021 amendments; proportionality standard; clawback rule).

Hennessy & Roach, “Missouri’s (Now Official!) New Discovery Rules” (Apr. 2021)  (Rule 58.01(b)(1)(C) native-format analysis).

Tueth Keeney, “Missouri Supreme Court Updates Civil Discovery Rules”  (section-by-section change summary).

Capes Sokol, “Significant Changes Coming to Missouri Trial Practice: Discovery Limits”  (side-by-side comparison with Federal Rules).

ALFA International, “Missouri Transportation Law” (2020)  (Hancock v. Shook and scope-of-discovery analysis; black box and ESI discovery).

Adam S. Davis, “Beyond the Usual Course: Producing Documents Under the Discovery Rules,” Missouri Bar Journal (Jan. 2020)  (Missouri Rule 58.01(c)(4) mechanics).

Sedona Conference Principles and ESI Treatises

The Sedona Principles, Third Edition (2018), 19 Sedona Conf. J. 1  (foundational ESI discovery treatise; Principles 1 through 14).

The Sedona Conference Database Principles (2014), 15 Sedona Conf. J. 171  (preservation and production of databases; directly applicable to claims systems).

The Sedona Conference Publications Index  (complete catalog of Sedona Principles, Commentaries, and Guidelines, including legal holds, proportionality, Rule 45 subpoenas, and BYOD).

The Sedona Principles, Second Edition (2007)  (historical version reflecting the shift to native-format preference in Principle 12).

Federal Court ESI Protocols and Hybrid-Production Guidance

U.S. District Court for the District of Maryland, ESI Principles (including Appendix 2.1 Hybrid Production Protocol)  (detailed hybrid-production protocol; Q&A on metadata, hash values, and authentication).

Kilpatrick Townsend LitSmart, “Warning: Follow Your ESI Protocol Because the Court Will — Part One”  (enforcement of ESI protocols and consequences of non-compliance).

Craig Ball, “Clarify Requests for Native ESI,” Ball in Your Court (Aug. 2022)  (model language for native-format requests; load file specifications; Bates and hash considerations).

Advocate Magazine, “Demystifying ESI for Plaintiffs’ Lawyers” (Feb. 2022)  (person-most-qualified deposition technique; state versus federal burden-of-inaccessibility differences).

Bad-Faith Discovery Practice

Claims Journal, “Going on the Offensive in Defending Bad Faith Claims” (Dec. 2015)  (defense-side discovery strategy; useful for anticipating carrier objections).

Butler Weihmuller Katz Craig LLP, “The Expanding Scope of Discovery in Bad Faith Cases” (Mealey’s Litigation Report: Bad Faith, 1998, with updates)  (Colonial Life & Accident v. Superior Court; claim manuals, reserves, other insureds).

Advocate Magazine, “Discovery: The Claims File in Bad-Faith Cases” (Oct. 2018)  (third-party failure-to-settle discovery priorities; genuine-dispute defense avoidance).

Daniels Law, “Discovery and Depositions in the Bad Faith Case” (Sept. 2023)  (person-most-qualified deposition as discovery tool).

For related blogs see:

• AI Systems for Missouri Lawyers: How They Work, What They Risk, and How to Use Them Responsibly
• Proving the Insurer’s Breach of Fiduciary Duty in Missouri: A Discovery and Deposition Practice Guide
• Discovery in Missouri Insurance Coverage Litigation: Claim Files, Reserve Data, and the Work Product Doctrine
• When the Carrier Breaches First: Answering Cooperation and Consent Defenses
• Artificial Intelligence and Insurance Policy Interpretation: What the Eleventh Circuit Opened, What the Scholars Are Fighting About, and What Missouri Practitioners Need to Know