Structured Data and Database Discovery

What This Solves

Your opposing party runs SAP. The relevant data is not in a folder or an email thread. It lives across dozens of tables, linked by foreign keys, filtered by application logic, and displayed to users through views that assemble records on the fly. A simple export of those tables gives you raw field values with no context. The numbers don't make sense without the schema, and the schema doesn't make sense without knowing which stored procedures assembled the report your client relied on.

This is the problem structured data discovery addresses. When litigation involves an ERP system, a financial database, a healthcare record platform, or a custom CRM, collecting the relevant data requires understanding the system before writing a single query. GDF's forensic analysts work directly with your database team, application vendors, and technical stakeholders to extract exactly what the matter requires, in a form reviewers can actually use, with a methodology that survives challenge.

Why Databases Cannot Be Treated Like Files

The Sedona Conference has addressed structured data handling directly, noting that databases present unique challenges that standard document collection workflows do not resolve. A single "document" in an ERP system may span ten tables. A sales transaction record in Oracle, for example, pulls from the customer master, the item catalog, the pricing engine, the warehouse allocation tables, and the accounts receivable ledger before any report is generated. Export the raw tables without that context and you have data, but not information.

Several other problems make database discovery genuinely different from file or email collection:

• Field labels in one system may have completely different meaning in another deployment of the same software, because implementations customize field names and repurpose columns.
• Deleted records often leave artifacts in audit tables, change logs, or transaction journals, but those artifacts are only accessible if you know to look for them.
• Calculated fields, derived values, and report summaries exist only at query time. They cannot be "collected" as a static file; the query logic must be preserved and reproduced.
• Multi-tenant and multi-company configurations mean that data from different business units shares tables but is separated only by a company code or tenant identifier, which must be scoped correctly in every extraction query.

GDF's database forensics practice is built around these realities. Every engagement begins with understanding the system architecture, not with running queries.

Enterprise Systems We Support

GDF has performed structured data analysis and forensic extraction from a wide range of enterprise platforms. Each requires a different approach based on its data model, access controls, and application logic.

• Oracle E-Business Suite and Oracle Database: Financial ledgers, supply chain modules, HR records, and custom application schemas. GDF handles multi-org configurations and identifies relevant audit trail tables including FND_LOGINS and audit change tracking.
• SAP ERP (ECC, S/4HANA): Complex table structures including BKPF/BSEG for financial postings, VBAK/VBAP for sales orders, and change document tables (CDHDR/CDPOS) that record field-level modifications with timestamps and user IDs.
• Salesforce: Object-level data including standard and custom objects, field history tracking tables, and the audit trail that logs administrative changes. GDF collects via the Salesforce API with metadata preservation, not manual CSV export.
• NetSuite: Saved search outputs, transaction records across multiple subsidiaries, and the audit trail log that captures who changed what and when across the entire tenant.
• Workday: HR, payroll, and financial data with full awareness of effective dating and supervisory organization structures that affect how records relate to each other.
• PeopleSoft (Oracle): HR and financial modules with component-level audit logging, effective-dated rows, and the PeopleTools architecture that separates application data from system configuration.
• Epic and Cerner (healthcare): Electronic health record data, audit logs, access history, medication administration records, and the clinical documentation that supports medical malpractice, employment, and regulatory matters.
• Custom SQL databases: Microsoft SQL Server, PostgreSQL, MySQL, and other relational platforms, including legacy applications built on proprietary schemas with limited documentation.

GDF's Structured Data Analysis Process

Defensibility and Chain of Custody

Courts have scrutinized database extraction methodology in discovery disputes. The producing party must be able to explain, with specificity, what data was collected, how the queries were constructed, what filtering criteria were applied, and whether the output accurately represents what the system contains. GDF's structured data engagements are designed to answer each of those questions in writing, before a challenge arises.

Every extraction includes: read-only database access with session logging; hash verification of output files at time of extraction; a signed chain-of-custody log recording every analyst who touched the data; and a query log that can be rerun to produce an identical output, confirming reproducibility. When damages calculations or financial analyses depend on database records, GDF's approach also documents the mathematical relationship between the raw data and any derived figures so that opposing experts can audit the work.

What GDF Delivers

• Schema analysis report with table relationship diagrams
• Written extraction methodology document, suitable for disclosure to opposing counsel
• Normalized data exports in review-ready format with decoded field labels
• Full query log with timestamps, row counts, and hash values
• Chain-of-custody documentation covering the entire extraction process
• Expert declaration or affidavit on collection methodology, if required
• Deposition and trial testimony on database analysis findings