Structured Data eDiscovery for Records That Never Became Documents

Turn Business System Records Into Evidence a Reviewer Can Follow

A business record in an enterprise system is often assembled from linked tables, application rules and report logic rather than stored as a single document. We identify those relationships before the export so that field values and calculated results keep the context needed to interpret them, and so that the other side cannot dismiss the production as a pile of unexplained numbers.

Global Digital Forensics has served clients since 1992, including AmLaw 100 firms and Fortune 1000 companies, and its founder Joseph Caruso has worked with mainframe databases, real time transaction systems and the source code that drives them since 1980. His class action work has covered airline reservation architecture, credit card transaction and deposit systems and the configuration behind them. We work with database teams, vendors and technical owners on ERP, financial, healthcare, trading and custom business sources, documenting fields, queries, filters, transformations, validation and omissions for every agreed extraction.

Why a Database Export Is Not a Document Production

The Sedona Conference published its Database Principles in 2014 to address exactly this problem: databases are preserved and produced differently from documents. A single transaction can depend on customer, item, pricing, allocation and receivables records, so we explain the relationships behind the report rather than present raw tables without context.

Field meanings are confirmed in the deployed system, because custom labels and repurposed columns differ even between installations of the same product. Retained audit tables, change records and transaction journals are reviewed for evidence of deleted or changed items where those sources exist. For calculated outputs we preserve the report or query logic, the parameters, the source fields, the schema and the time or version context, so the record shows how the static result was produced and what it would take to repeat the calculation. Company and tenant identifiers in shared tables are confirmed so each extraction applies the correct business boundary. Understanding the architecture and the application logic comes before query design, every time.

Ask a discovery specialist how this fits your matter; the first consultation is free.

Scoping the Trading, Card and Ledger Systems Behind Disputes

In a securities fraud matter pursued by a group of plaintiff securities attorneys, the evidence they needed was buried in paper statements and trade confirmations until we concluded that the real record lived in a clearing firm's stock trade database. We worked with counsel to identify which clearing firm controlled it, guided the output and receipt of the entire transaction database covering a few hundred securities over ten years, and then found that the data did not reconcile with independent information about the case. Repeated testing showed that the clearing firm's decompression algorithms had corrupted the output. The firm corrected the problem and produced the data again, and we rebuilt the application that recorded the trades from limited technical documentation so the legal team and its industry experts could examine the activity and develop their arguments.

In a dispute over allegedly hidden fees at a large publicly traded financial institution, the transaction records sat with a third party processor in geographically and technologically disparate systems, and both sides faced collection costs out of proportion to the case. We mapped how the processor collected the data, how the institution received it and how the fees were calculated, then showed that a defined subset could support a sample based calculation whose estimate and limitations could be explained, which informed the deposition notices and document requests intended to narrow the inquiry. The same approach applies to relational databases, ERP and accounting systems, CRM platforms, HR and payroll systems, healthcare record systems and the legacy mainframe applications that still run much of the financial world, each scoped on its own data model, access controls and application logic.

Document the Extraction So Another Examiner Can Repeat It

The methodology explains the data selected, how the queries were constructed, the filters applied and the validation performed against the underlying source. That written record lets the retaining attorneys and any opposing examiner assess what the output represents and where its coverage ends, which is a far stronger position than asking a court to take the export on faith.

We use read only access where feasible and retain session and query logs, integrity checks, custody records and a record of the system state at extraction, so results from a live, changing system can be placed in time. Where derived financial figures rest on the records, the workpapers explain their mathematical relationship to the raw data for independent review, and they list the business inputs a damages calculation will draw on.

Send the custodians and the deadline and the first call sets the collection plan.

Exports, Workpapers and Testimony You Receive

The schema report and relationship diagrams explain how the relevant tables connect. The extraction method record documents the queries and the selection logic for counsel's disclosure decisions, and the normalized exports use agreed formats and decoded labels so reviewers can interpret the fields without a data dictionary open beside them. The query log records execution times, row counts and integrity values, and the custody documentation records handling throughout the extraction. Where the matter requires it, an expert declaration or affidavit explains the collection method, and our examiners provide deposition and trial testimony on the supported database findings.

Bring the system, the reports and the deadline to a free initial consultation and we will tell you whether the records you have been offered can answer the question being asked.