Parsing the Epstein Files for JMail — Palak Agarwal & Omar Alhait, Reducto

A clean PDF is the easy case. Scanned pages, rotated documents, charts and complicated layouts make it harder to recover information accurately enough for an application to use. Palak Agarwal, who leads developer relations at Reducto, opens with that distinction: document processing sits before the model and handles the messy material that a polished interface will eventually hide.

Reducto describes its approach as rasterization-based: it examines the rendered document visually. Its agentic OCR framework can flag uncertain readings, correct them and continue, rather than commit to a single pass. The platform exposes five capabilities—parse, split, extract, edit and classify—so recovering a page’s contents can support several different downstream tasks.

JMail gives that processing layer a concrete job. The product presents released Epstein emails through a familiar inbox interface, then extends the idea into applications such as JDrive, JFlights and JPhotos. Agarwal reports that Reducto parsed more than three million pages for the project, including redacted PDFs, scans, complex forms, tables and handwriting from many different people.

Omar Alhait, introduced as a Reducto founding engineer, takes over with the original obstacle: an appealing inbox concept still needed usable data. Even a cover sheet could have a difficult layout and a somewhat subjective reading order. Recognizing words was only part of the problem; the pipeline also had to decide how those words belonged together before other products could use them.

JFlights turns flight documentation into a dedicated view of flight history. Its inputs included poor-quality handwritten records, which added another interpretation problem on top of layout. Building the separate product meant taking the flight documents and applying an extraction configuration designed for that use case. Parsing came first; extraction then requested the information the flight application needed.

Studio was the place to develop that configuration before running it at scale. Alhait could upload a document, run the pipeline, adjust settings and inspect results. The useful comparison is between the difficult input and the information the pipeline returns: can one flight schema handle different documents, including those with redactions? He describes inspecting those variations to see whether extraction behaved as expected, before committing to a much larger run.

Throughput brought a separate constraint. During the initial document release, Alhait pushed parsing hard enough to stress the infrastructure and repeatedly page Alvin, the engineer on call. The late-night response was memorable: “Hey bro, can you slow down?” The team completed the processing in time, but the episode separates two requirements that a small demo can conceal: extracting useful information and sustaining the volume needed to process the corpus.

Once the corpus was available, it supported several products, including JFlights and JCal, which Alhait worked on himself. The configured pipeline could then be deployed and invoked through either a direct API call or a generated pipeline code snippet. Studio connected exploratory work to application integration: define the requested output, inspect it, then call the configured processing from code.

An audience question makes the schema’s role explicit: must a user define it in advance? Reducto can generate one from a request. Alhait creates an extraction pipeline for resumes, generates a resume schema, then uploads resumes and runs it. What does that first schema actually ask for? That is the first thing to inspect, because a plausible collection of fields may still request something different from what the application needs.

The schema is the “paintbrush” on the document-processing canvas: it directs what extraction should return. Uploading a real resume can expose a mismatch between the requested fields and the desired result. Generating a schema therefore provides a starting specification; running documents through it tests whether that specification asks the right questions.

A second question presses on validation across millions of documents. After an initial misunderstanding, Alhait explains two ways to generate the schema:

• Regular generation: a quick LLM call builds a JSON schema from the user’s request. This gets an initial result on screen quickly.
• Enhanced generation: the system parses supplied documents first, then uses their contents to tailor the schema descriptions. This gives generation information about the actual material being processed.

The distinction concerns the input to schema generation. A request alone describes the intended task; parsed documents add evidence about how that task appears in this collection. Enhanced generation can make the descriptions more specific, but it does not itself establish extraction accuracy across the corpus. The broader evaluation question returns later in the discussion.

The redacted flight documents raise a consequential question: were the redactions permanently applied? Reducto also parses PDF metadata, so the rendered page is not the only source it can read. A black box drawn over text can conceal that text visually while leaving the underlying data available to extraction.

Alhait distinguishes correctly redacted files from others where information behind the redaction remained accessible. That created additional work for the JMail team: material intended to remain redacted had to remain concealed in the resulting product too. He describes the responsibility, rather than a specific remediation algorithm. “Our tool was working a little too well” captures the failure: recovering more data can violate the document’s intended disclosure limits.

Schemas can request substantial output. Alhait gives an example he had recently seen with 156 fields, each requesting different information. He estimates a nesting limit of four or five layers; that is a recollection in the discussion, rather than a firm specification. Field count and nesting describe what the system can be asked to return, while correctness still depends on extracting the requested information from the document.

A question about entity resolution leads to a more specific account of post-processing. Alhait says the system does work to link entities, then describes a citation model: one model can extract a value, while another determines where that value came from in the document. This explains source attribution for extracted information; the discussion does not establish how the system resolves identities across records.

Another question separates two sources of text that can coexist inside a PDF: information recovered from the rendered image through OCR, and information available from the PDF itself. Alhait initially starts enabling figure output on the resume example, then addresses the clarified question through Reducto’s hybrid OCR configuration. It can prioritize OCR data in some cases and PDF metadata in others. The selection rules are not explained, so this establishes a configurable hybrid approach without exposing its decision procedure.

Does the extraction workflow first recover document structure, or simply hand everything to an LLM? Alhait’s answer is that extraction consumes the parse results. Parsing is an upstream operation whose output becomes input to a downstream extraction pipeline. That separation also makes other operations possible after the content has been recovered.

A math textbook illustrates the dependency. First parse its content. Then split it into regions by identifying where chapters begin and end. Extraction can operate on each chapter to produce something such as a chapter summary. The chapter boundaries determine the material each extraction receives; recovering those boundaries is therefore part of preparing the task, rather than merely formatting its final answer.

The team declines to name the models used for parsing and extraction, but describes how production failures guide training. If a particular kind of data performs poorly—for example, when recall over long context is weak—the team trains to address it. Comprehensive extraction is “all the needles in a haystack”: finding one relevant item is insufficient when the schema asks for many different facts spread through the material.

The benchmarking discussion finally answers the scaling concern raised during the resume demo. Reducto’s team says it plans to release benchmarks, while acknowledging that customers usually need evaluations built around their own documents. The recording supplies no comparative results or evaluation protocol that would establish the team’s claimed performance advantage.

Configuration matters to those comparisons. A customer can evaluate a provider with unsuitable API settings and get results that do not represent the intended setup. The team describes working through configuration options and their tradeoffs with customers before letting them decide. A useful comparison therefore includes the settings used to process the documents, as well as the provider’s name.

The practical sequence starts small: use a simple dataset and inspect whether Studio’s outputs make sense. These “vibe evals” help reveal obvious mismatches before committing more effort. As the workflow scales, move to a more systematic evaluation with a hundred or a thousand documents. The shift is from checking a few understandable examples to testing whether the configured extraction holds up across the collection it must serve.

Alhait returns to product design with an admission: his early way to expose the parsed corpus was a rough retrieval-augmented chatbot that answered questions about the emails. He sees a possible use for journalists, but credits JMail’s product experience with making the extracted material appealing to a much wider audience. The same underlying information can support very different ways of exploring it.

Another team member gives the observable change: an overwhelming collection of scanned documents became something they could log into and search for familiar names. Extraction made the material usable; the interface made starting easy. JMail is an unusual subject for a document application, but that movement from unstructured files to an approachable product is the pattern the team also sees in industry.

The model work underneath remains labor-intensive. Reducto has a labeling team that sifts through documents and checks the data used to train new models. Alhait emphasizes the repetitive classification work before discussing how to arrange the training data. Better training procedures still need trustworthy labels. His account leaves the labor in the story: “you still have to label that data.”

The final technical question concerns documents that need specialized logic: particular metadata arrangements, model choices or processing instructions. Alhait describes configurations and system prompts applied to separate models for specific processing tasks. This gives the user a place to express document-specific requirements beyond the extraction schema.

Where should those instructions go? The examples distinguish two kinds of customization:

• Figure interpretation: for a collection of logos, add instructions that help distinguish Lincoln Financial from Google and produce the desired figure outputs.
• Layout interpretation: for difficult construction blueprints, spend time adjusting the layout prompt and checking how the extraction behaves across different blueprints.

The relationship is between the failure and the stage receiving the correction: instructions about figures belong with figure processing; instructions about hard-to-read layouts belong with layout processing.

The recording ends by turning the case study into an exercise. Participants are invited to sign up for Studio and use material supplied through a QR code to begin an extraction project with a coding assistant. The proposed session allows about 30 minutes, with a show-and-tell near the final five-minute mark. An idea and a single-shot prompt are enough to participate; the team will circulate to help with Reducto and answer model-training questions.