# Parsing the Epstein Files for JMail

Palak Agarwal & Omar Alhait, Reducto | AI Engineer World's Fair 2026 | 29:29

Source: https://www.youtube.com/watch?v=HGfsfKaVuGY
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/parsing-the-epstein-files-for-jmail
Published: 2026-10-11
Tags: data-pipelines, evals, privacy, structured-outputs

## TL;DR
- Reducto parses scans, rotated pages, charts, tables, handwriting, and other difficult documents before an AI model uses them.
- The JMail team used parsed Epstein files to build products such as JFlights, with schemas controlling which fields were extracted from the documents.
- Document extraction should start with a small sample in Studio, then move to a representative benchmark before processing a large corpus.

## Summary
Palak Agarwal and Omar Alhait explain how Reducto processed more than three million pages for JMail and related products. The documents included redacted PDFs, scanned government files, complex forms, tables, and handwritten flight logs. Reducto first parses the document, then applies extraction schemas and downstream processing. Omar demonstrates how the team tested configurations in Studio, inspected results, handled figures and citations, and deployed a pipeline through an API call or code snippet. The talk also covers schema generation, including a faster schema based only on the request and an enhanced version informed by parsed documents. Redaction requires care because a black box on a PDF may leave the underlying text accessible. For production work, the speakers recommend inspecting a small sample and building a representative benchmark before scaling. They close with an interactive exercise using Reducto Studio and document extraction prompts.

## Key ideas
### Reducto puts document parsing before the model
[00:12](https://www.youtube.com/watch?v=HGfsfKaVuGY&t=12s)
Palak Agarwal describes Reducto as the layer before an AI model. It handles scanned and rotated documents, charts, complex layouts, and post-processing so product teams can work with cleaner data. The system uses a rasterization-based approach, looking at pages as a person would rather than relying only on the underlying PDF embedding. Its OCR framework can flag uncertain results, correct them, and continue through later steps. Agarwal names five capabilities: parse, split, extract, edit, and classify.

### JMail made difficult documents useful through downstream products
[01:57](https://www.youtube.com/watch?v=HGfsfKaVuGY&t=117s)
Palak Agarwal explains that JMail began as a Gmail fork built after the Epstein files were released, then expanded into products including JDrive, JFlights, Jamazon, and JPhotos. Reducto processed more than three million pages of redacted PDFs, scanned documents, and government files for the project. The collection included complex forms, tables, and handwriting from many people. The point of the document layer was to make this material searchable and usable in applications rather than leaving users with a large file archive.

### Handwritten flight logs exposed the main extraction bottleneck
[03:17](https://www.youtube.com/watch?v=HGfsfKaVuGY&t=197s)
Omar Alhait describes the JFlights use case, which turned flight records into a separate product. The source material included poor-quality handwritten documents, making the task harder than processing a clean PDF. Layout and reading order were also difficult because the correct sequence on a page could be subjective. Reducto gave the team a way to parse the files and apply a flight-specific extraction configuration before building the interface around the resulting records.

### A small Studio check should come before large-scale processing
[06:35](https://www.youtube.com/watch?v=HGfsfKaVuGY&t=395s)
Alhait walks through a pipeline in Reducto Studio. A user adds a document, configures the available options, runs it, and inspects the live result. He describes using this process to understand whether the extraction accuracy matched his expectations before scaling to a million documents. The team examined redactions and other document variations through a shared extraction schema. Once the output looked acceptable, the same pipeline could be deployed through a direct API call or generated code snippet.

### Schema design determines what extraction returns
[08:57](https://www.youtube.com/watch?v=HGfsfKaVuGY&t=537s)
Alhait compares an extraction schema to a paintbrush on the Reducto canvas. The schema tells the system what to return, so a quick schema can produce exactly the requested fields even when those fields do not fit the documents well. Reducto can generate a basic JSON schema from a short request, as shown in the resume example. An enhanced option first parses the documents and then tailors the schema description to the content it finds. Alhait recommends the enhanced approach when document-specific details matter.

### PDF redaction must remove the underlying information
[13:44](https://www.youtube.com/watch?v=HGfsfKaVuGY&t=824s)
The speakers explain that parsing PDF metadata can expose information that a visual redaction did not actually remove. A black box placed over text is not enough if the original content remains in the file. Some of the Epstein files were redacted correctly, while others allowed the team to identify information that was intended to stay hidden. This created a responsibility for the JMail team to apply additional redaction and avoid exposing people's data.

### Extraction can combine nested fields, citations, figures, and OCR
[15:34](https://www.youtube.com/watch?v=HGfsfKaVuGY&t=934s)
Alhait says schemas can contain several layers of nesting, with a practical limit of around four or five layers in the configuration he was discussing. Reducto also uses post-processing to link entities and a citation model to identify where an extracted value came from. Figure models can return images or other visual content. Its hybrid OCR configuration decides whether to use strict OCR output or PDF metadata, depending on the document. The choice requires document-specific testing rather than one fixed rule.

### Parsing is the foundation for splitting and extraction
[19:43](https://www.youtube.com/watch?v=HGfsfKaVuGY&t=1183s)
Alhait describes parsing as the foundation for later document operations. Once a document has been parsed, Reducto can split it into regions and apply different extraction steps to those regions. His example is a math textbook where the system identifies chapter boundaries and then extracts a summary for each chapter. This separates understanding the page structure from asking for particular fields, allowing downstream workflows to build on the parsed content.

### Evaluation should grow from inspection to a representative benchmark
[21:30](https://www.youtube.com/watch?v=HGfsfKaVuGY&t=1290s)
The speakers recommend starting with a simple sample and checking results in Studio before scaling. A team can then expand to a larger set, such as hundreds or thousands of documents, and run a more systematic evaluation. Customers often create their own head-to-head benchmarks across document providers, although the configuration must match each provider's capabilities. Reducto plans to release benchmarks, but Alhait says teams usually still need benchmarks that reflect their own documents and extraction requirements.

## Notable quotes
- Palak Agarwal: "Reducto is the layer that sits right before your model." (01:16)
- Omar Alhait: "The simplicity from this is really like getting a schema, looking at these results, making sure that the results look like what I would expect, and then just deploying." (08:53)
- Omar Alhait: "You can't just stick a box on a PDF and then expect it to actually be fully redacted." (14:11)
- Omar Alhait: "Parse is really the kind of foundation for all of these other agentic document processing features." (20:24)
- Palak Agarwal: "As with most projects, gather a simple data set, you can do some vibe eval, just look in Studio to see if the outputs make sense, and then as you want to scale it out, get 100 documents, a thousand documents, do something more systematic." (23:10)

## Tools & references mentioned
- Reducto
- JMail
- JFlights
- JDrive
- Jamazon
- JPhotos
- Jemini
- JCAL
- Studio
- Claude Code
- Codex
- NVIDIA
- Harvey
- Scale

## Who should watch
- You are building search, extraction, or workflow software on top of scanned PDFs, handwriting, tables, or inconsistent page layouts.
- Your team needs to decide how to design extraction schemas and test them before sending a large document corpus through a pipeline.
- You need practical guidance on PDF redaction, citations, figures, OCR choices, or document-specific evaluation.

## Related talks

- [Structuring the Unstructured](https://aietalks.com/talks/structuring-the-unstructured) (Cedric Clyburn, Red Hat, 20:41)
- [From Raw Documents to AI-Ready Data](https://aietalks.com/talks/from-raw-documents-to-ai-ready-data) (Leo Platzer & Jeff Koss, Deasy Labs (Collibra), 21:37)
- [From MCP to Scale: Pipelines That Build Themselves](https://aietalks.com/talks/from-mcp-to-scale-pipelines-that-build-themselves) (Rafael Levi, Bright Data, 25:26)
- [Forget RAG Pipelines: Build Production-Ready Agents in 15 Minutes](https://aietalks.com/talks/forget-rag-pipelines-build-production-ready-agents-in-15-minutes) (Nina Lopatina & Rajiv Shah, Contextual AI, 1:15:43)
- [Grep or Embeddings? Agentic Search Over Company Documents](https://aietalks.com/talks/grep-or-embeddings-agentic-search-over-company-documents) (George He, LlamaIndex, 23:22)