Reducto parses scans, rotated pages, charts, tables, handwriting, and other difficult documents before an AI model uses them.
2
The JMail team used parsed Epstein files to build products such as JFlights, with schemas controlling which fields were extracted from the documents.
3
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.
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
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
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
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.
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
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
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
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
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.
"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."Palak Agarwal23:10
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.
