Talk by Palak Agarwal and Omar Alhait of Reducto on parsing the Epstein files for JMail. Covers turning handwritten flight logs and heavily redacted PDFs into structured data through parsing, schema-driven extraction tested in Studio, and API deployment. Discusses JFlights extraction, a resume schema example, nested fields and citations, OCR versus PDF metadata, redaction risks, and evaluation by sampling and building a benchmark before scaling. The description presents these as the speakers' demonstrated workflow; the title alone is the source of the subject framing. # Channel Presentation Observations: Reducto, *Parsing the Epstein Files for JMail* > **Scope note:** This document covers one video only. No curated metadata was supplied, and the transcript has no timestamps. Observations are limited to this material and do not describe the channel as a whole. --- ## 1. Explicit Self-Description (Creator Claims) ### Company framing - **Stated category:** "we're an agent document platform," which "basically means we help teams turn messy unstructured documents into data that AI can actually use accurately." - **Stated position:** "Reductto is the layer that sits right before your model." - **Stated approach:** "we take a rasterizationbased approach that means we look at your document like a human would look at the document instead of the underlying embedding." - **Stated method:** "everything is powered by our agentic OCR framework where rather than making a single pass and committing to an answer the model flags things that it's uncertain about corrects them and then moves on." ### Speaker roles (as stated) - **Palak:** "I lead developer relations at Reductto." - **Omar:** introduced as "one of our founding engineers." ### Claimed credentials and scale (unverified in material) - "raised 108 million from investors like ACCNC benchmark and more" - "processed over two billion documents" - Customers named: "Harvey Scale and a top five global hedge fund" - Five core capabilities: "Parse, split, extract, edit, and classify." ### Claims about the JMail project (third-party, unverified) - Built "in five hours last November" - "over 450 million visits and 18 million users" - Reducto "was behind parsing all of the documents," described as "over three million pages" --- ## 2. Observable Presentation ### Format and structure - **Hybrid talk and live demo.** The speakers gave background, then walked through a live Reducto Studio session (pipeline setup, schema creation, resume upload). - **Q&A segment.** Audience questions were taken and answered live, including some the speakers deflected. - **Interactive closing.** Attendees were invited to build with a QR-linked prompt and show results for prizes. ### Audience address - **Developers and technical builders.** Evidence includes references to "Cloud code or a codeex," schema and JSON configuration, API calls, and code snippets. - **Enterprise and data teams.** Evidence includes references to customers evaluating "document providers" and running "head-to-heads." - **Prospective hires.** The speakers say "we are hiring" and invite listeners to "come speak to us after." ### Tone and register - **Conversational and informal.** Examples include "Yippee," "Alrighty," and "Cool. Cool. Cool." - **Self-deprecating or candid moments.** Examples include Omar's admission that his early prototype was "pretty shoddy" and his note that "Our tool was working a little too well." - **Humor.** Examples include the Alvin anecdote and "Man, if I answer that question, I might lose my job tomorrow." ### Commercial elements (observable) - Sign-up call to action: "you could sign up today at studio." - Swag and prizes mentioned. - Benchmark plans presented as forthcoming: "we're going to release some benchmarks soon." - Customer head-to-head comparisons referenced as evidence of performance: "we often like win these headto-heads." --- ## 3. Claimed Scope - **Document types:** scanned, rotated, and charted documents; forms, tables, and handwriting; government files. - **Capabilities:** parse, split, extract, edit, classify, with parsing described as "the foundation for all of these other agentic document processing features." - **Customization:** configurable system prompts and per-layout prompts "tailored directly to what you're asking for." - **Schema depth:** nesting "limits to our schema or maybe like four or five layers," with one schema cited at "156 fields." --- ## 4. Evidence of Candor vs. Promotion | Pattern | Evidence from transcript | |---|---| | **Admits limits** | Early JMail prototype "pretty shoddy"; benchmarking needed because "there need to be more data points" | | **Acknowledges others' errors** | Redaction failures attributed to whoever "was cooking up that redaction" | | **Deflects sensitive questions** | Declined to answer a question about model details, citing job risk | | **Frames results as self-assessed** | "we're very confident in our models," with no published benchmark cited yet | > **Caution:** These observations describe how the speakers presented themselves in this talk. They do not establish the accuracy of any performance or market claim. --- ## 5. Transcript Limitations - **Speaker labels are inconsistent.** The transcript shows "Ple" where the title gives "Palak Agarwal." Some speaker turns are unlabeled. - **Transcription artifacts.** Examples include "redu relations," "rasterizationbased," "Jmail/JMail/J drive" variation, and "Alvin" appearing as an audience reference. - **No timestamps or visual evidence.** Demo claims rest on spoken description only. # Delivery Observation — Reducto: Parsing the Epstein Files for JMail ## Speakers & Roles - **Speaker 1 (transcript rendered as "Ple"/"Paula")** — developer relations lead; opens and closes the session. - **Speaker 2 (Omar)** — founding engineer; delivers the technical demo and most Q&A answers. - *(Note: the transcript contains several garbled renderings of names and product names — "Ple," "reductto," "Jail," "Chad GPT" — so name-level claims carry transcription uncertainty.)* --- ## Tone - **Casual and conversational throughout.** Both speakers use frequent fillers ("um," "uh," "right?") and colloquialisms: > "Alrighty, who's ready to talk about some documents. Yippee." - **Humor and playfulness**, especially around the JMail premise and live-demo friction: > "Woody Allen, I know that guy." > "Man, if I answer that question, I might lose my job tomorrow. [laughter]" > "My Wi-Fi is not being helpful with me today." - **Self-deprecating honesty** when describing early work: > "I came up with something that was pretty shoddy in the beginning um like basically a you know rag chatbot application." - **Candid acknowledgment of unglamorous work:** > "like it's a lot of hard menial annoying work, right?" --- ## Vocabulary & Recurring Phrases - **"Right?" as a habitual tag** — extremely frequent in Speaker 2's delivery: > "walking us back to, you know, a very fateful night in November, right?" > "you can't just stick a box on a PDF and then expect it to actually be fully redacted, right?" - **Intensifier stacking** ("really really," "very very"): > "it's a very very complex problem" > "to basically make our parsing really really good" > "we're dealing with... very very certain in the outcomes" - **"You know"** as a near-constant filler for both speakers. - **"Cool" as a segment-transition word:** > "Cool. And so, I guess you know if you could kind of take uh anything out of this..." > "Cool. Cool. Cool. Cool." (Q&A handoff) - **Product-metric framing** from Speaker 1: funding, scale, and customer names delivered as rapid credentialing ("108 million," "two billion documents," "450 million visits," "18 million users"). --- ## Teaching Habits - **Audience check-ins and polls:** > "a quick show of hands. Who here has heard of Jmail or looked through Jmail before?" - **Concrete, repeat-the-question Q&A discipline:** > "So, to repeat the question uh and let me know, you know, how how accurate it was, right?" > "So, if I'm understanding correctly right, what you're saying here?" - **Analogy-driven explanation:** > "your extract schema is sort of like the paintbrush on your reductto canvas" - **Interactive challenges posed to the audience:** > "I would urge you... to send this like uh you know uh cover sheet to Chad GPT and try to get some results out of it." > "I urge you to kind of put our schema to the test." - **Live demo tolerance for friction** — reruns and narrates failures rather than hiding them: > "oh whoops sorry about that actually I'm going to do this real quick" - **Structured takeaway distillation** near the end of the demo: > "the simplicity from this is really like you know getting a schema, right? looking at these results, making sure that the results look like what I would expect, and then just deploying." --- ## Communication Patterns - **Presenter handoff with a personalized introduction:** > "now I'm going to hand it over to Omar, who's one of our founding engineers and worked very closely with the Jail team." - **Narrative framing of engineering work as story** — the November-night origin anecdote, the on-call pager anecdote: > "I was paging Alvin maybe like, you know, a couple times a night... Alvin was sending me a lot of fun messages late at night like, 'Hey, bro, can you slow down?'" - **Recruiting threads woven into technical answers:** > "If you're interested about these things, we are hiring and so uh come speak to us after." - **Soft-gated next steps**: QR code, studio access, interactive exercise, prizes/swag, and an offer to "circle around" for questions. --- ## Uncertainty Notes - **Speaker attribution** beyond the two main voices is unclear; transcript markers like ">>" make some Q&A exchanges ambiguous about who is asking vs. answering. - **Repetition-based confidence is high** for the "right?", "you know", and "really really" patterns (dozens of instances), but **lower** for one-off rhetorical habits such as "at the end of the day" (appears ~3 times) — possibly a genuine tic, possibly incidental. - Name and product renderings in the transcript ("Ple," "reductto," "Chad GPT") appear to be transcription artifacts, so quoted names should be treated with caution even where quotes themselves are exact. # Observation Record: "Parsing the Epstein Files for JMail" **Source:** Video `01a15ca6-aba8-7797-9739-4b05db2c3bdc` **Presenters (per curated title metadata):** Palak Agarwal and Omar Alhait, Reducto **Speaker attribution basis:** The title names two presenters. The transcript supports attributing the opening remarks to the first presenter (rendered as "Ple" in the transcript) and the technical segments to Omar. Audience questioners and unnamed respondents in the Q&A are **unidentified** and are recorded as such. --- ## 1. Reducto: Company Self-Description **Speaker:** Palak Agarwal - **Claimed category:** An "agent document platform" that turns unstructured documents into AI-usable data. - **Claimed traction (self-reported, unverified):** - $108 million raised over three years from investors including "ACCNC benchmark and more" - Over two billion documents processed - Customers named: Harvey, Scale, and "a top five global hedge fund" - **Claimed core capabilities:** Parse, split, extract, edit, classify. - **Claimed technical approach:** - Rasterization-based: the document is viewed "like a human would," not through underlying embeddings. - "Agentic OCR": the model flags uncertainty, corrects, and proceeds, rather than making "a single pass and committing to an answer." --- ## 2. The JMail Project ### 2.1 Origin and Scale **Speaker:** Palak Agarwal (background), Omar Alhait (origin narrative) - **Palak's account:** JMail was "originally built by Riley Walls and Luke in five hours last November" when the Epstein files were released. It was described as a forked Gmail interface that grew into a suite ("J Drive," "J Flight," "J Amazon," "J Photos"). - **Reported usage (stated, not independently verified):** Over 450 million visits and 18 million users by February. - **Reducto's role (claimed):** Reducto "was behind parsing all of the documents," described as over three million pages of redacted PDFs, scanned documents, and government files, including complex forms, tables, and handwriting. ### 2.2 Omar's Account of the Problem **Speaker:** Omar Alhait - The concept was a "what if" discussion with the founding team and a close contact, Luke, a founder at Kino. - **Stated barrier:** Layout understanding was "pretty hard," and reading order was "somewhat subjective." - **Comparison offered:** Omar suggested that audience members send the cover sheet to ChatGPT to see "how accurate it is," implying that general-purpose models struggle with this material. This is an assertion made in passing, with no tested results shown. ### 2.3 Flight Records **Speaker:** Omar Alhait - The flight product compiled flight history for Epstein and affiliates. - **Stated difficulty:** Handwritten documents, which Omar described as harder than the cover sheet. - **Method described:** A pipeline with a separate extraction configuration, tuned on a sample corpus before scaling to "a million different documents." - **Infrastructure note (anecdotal):** Omar described stressing Reducto's infrastructure during parsing and recalled a colleague, Alvin, asking him to "slow down." - **Downstream products (per Omar):** JMail, JFlights, Gemini-related features, and JCal (which Omar says he worked on himself). --- ## 3. Redaction Concerns **Speaker:** Omar Alhait > "Sometimes the redaction was actually not that great... you can't just stick a box on a PDF and then expect it to actually be fully redacted." - **Claimed mechanism:** Reducto parses PDF metadata, which can expose content hidden under visual redaction boxes. - **Mixed findings, as stated:** - Some files were redacted correctly. - Some files exposed underlying content, including "who the redaction was behind." - **Responsibility claimed by the JMail team:** Omar said the team had to perform additional redaction work and felt "a heavy kind of level of responsibility," citing the risk of being sued. - **Self-assessment (ironic, stated):** "Our tool was working a little too well." > **Tension to note:** The presenters frame the redaction failures as the originating party's error, while also acknowledging that Reducto's own parsing surfaced the hidden content. --- ## 4. Product Workflow and Schema Design ### 4.1 Schema-First Workflow **Speaker:** Omar Alhait - **Stated simplicity:** Define a schema, review results against expectations, then deploy via direct API call or pipeline code snippet. - **Analogy offered:** The extract schema is "the paintbrush on your Reducto canvas." ### 4.2 Schema Generation Modes **Speaker:** Omar Alhait (responding to an audience question) - **Standard generation:** A quick LLM call builds a JSON schema from the prompt alone. Omar recommends this for fast results. - **Enhanced generation:** Parses documents first, then tailors schema descriptions to their content. Omar recommends this for nuanced work. ### 4.3 Schema Capacity **Speaker:** Omar Alhait - One schema reportedly had 156 fields, with "completely different" requests. - **Stated nesting limit:** "Four or five layers." - Omar asserted that "if you want to ask for everything in the world, you can still technically be able to fit it in a schema." This is a claim about capacity, not a demonstrated result. --- ## 5. Validation and Accuracy **Speakers:** Unidentified audience member; Omar Alhait responded - **Question asked:** "How do you validate?" - **Response given:** Omar initially interpreted the question as being about the loading state, then said he had misunderstood. The response then moved to schema generation rather than directly describing validation methodology. > **Unresolved:** The transcript does not contain a direct answer about how extraction accuracy is validated. **Benchmarking (Speaker: Unidentified Reducto representative; the response was given before Omar's and Palak's later remarks, so attribution is uncertain):** - **Stated plan:** Public benchmarks "in the coming months." - **Stated rationale:** Prospective customers lack a neutral reference point, and "you typically have to make your own benchmarks." - **Stated confidence:** "We're very confident in our models" and "the premier document extraction solution on the market." The speaker also acknowledged that "there need to be more data points." - **Customer head-to-heads (claimed):** Reducto "often" wins these comparisons, but this was not supported with data in the session. The speaker also noted that customers sometimes misconfigure the API, which can affect results. - **Recommended evaluation path:** Start with a small dataset and "vibe eval" in Studio, then scale to 100 or 1,000 documents with a more systematic approach. --- ## 6. Technical Claims (Unverified, Partially Hedged) ### 6.1 Post-Processing and Citations **Speaker:** Unidentified Reducto respondent who said they were "personally a little bit farther abstracted away from the ML side" - Reducto runs post-processing to link entities, including a citation model that determines where each extracted item came from. - The respondent referenced an NVIDIA paper they had "just found out about," possibly titled "find everything" (recollection uncertain). ### 6.2 Long-Context Recall **Speaker:** Unidentified Reducto respondent - Reducto trains on specific data types and fixes areas where it underperforms, such as long-context recall. - For extraction, the respondent described the challenge as "all the needles in a haystack" rather than "a needle in a haystack." They described it as a challenging research problem that their ML engineers "somehow" handle "pretty well." This is self-described and unverified. ### 6.3 Figure Extraction and Hybrid OCR **Speaker:** Omar Alhait, with a reference to Alvin, who worked on the hybrid OCR model - Reducto has figure models and a hybrid OCR configuration that chooses between strict OCR and PDF metadata. - Omar described this as "not a simple answer" and a potential topic for a separate talk. ### 6.4 Parse as Foundation **Speaker:** Omar Alhait - Parse is the foundation for other features. Parsed content can be split into regions (for example, chapters in a textbook), then used for downstream extraction, such as chapter summaries. --- ## 7. Data Labeling and Model Training **Speaker:** Unidentified respondent - Reducto has a data labeling team and sifts through documents to train models. - The speaker said that "at the end of the day, you still have to label that data," describing labeling as "a lot of hard menial annoying work" that underpins model training. - A related question about training data and proprietary methods was deflected with a joke about job security. No details were given. --- ## 8. Product Perspective on JMail **Speaker:** Omar Alhait - **Early prototype (self-described as "pretty shoddy"):** A RAG chatbot for querying the emails. Omar suggested this might be useful for journalists. - **Stated view of the product's success:** The user numbers ("hundreds of millions" of Gmail users, "tens of million" still logging on weekly) show that a polished product on top of a strong extraction layer is the "one-two punch." **Speaker:** Palak Agarwal - **Stated view:** She would not have read three million scanned documents manually, and she "logged on and started searching" once Omar built the interface. - **Generalization:** "Unstructured data is like everywhere," and this is "exactly what happens in the industry." --- ## 9. Audience Q&A: Custom Logic and Agentic Configuration **Speaker:** Omar Alhait (responding to a question about condition-based logic) - **Stated capability:** Agentic configs can apply system prompts to separate models that process tailored tasks. - **Examples given:** - Distinguishing logos (for instance, Lincoln Financial from Google) through added prompt context. - Tuning layout prompts for difficult documents such as construction blueprints. --- ## 10. Open Items and Unresolved Tensions | Item | Source | Status | |---|---|---| | Validation methodology | Audience question | Not directly answered | | Benchmarks | Reducto representative | Promised, not released | | "Often win head-to-heads" | Reducto representative | Unsupported in session | | Usage and visit figures | Palak Agarwal | Self-reported | | Redaction failures | Omar Alhait | Stated qualitatively, no examples given | | 156-field schema capacity | Omar Alhait | Anecdotal | | NVIDIA paper reference | Unidentified respondent | Recall uncertain | | Hybrid OCR details | Omar Alhait | Deferred to possible future talk | --- ## 11. Session Logistics **Speaker:** Omar Alhait (closing) - Attendees were invited to sign up at Studio and build a document extraction prototype during a roughly 30-minute hands-on exercise, with prizes and swag. - Attendees could paste a QR-code prompt into a coding assistant to begin. - Reducto staff said they would circulate to answer questions. # Speaker Attribution and Provenance Record **Video ID:** `01a15ca6-aba8-7797-9739-4b05db2c3bdc` **Title:** *Parsing the Epstein Files for JMail — Palak Agarwal & Omar Alhait, Reducto* --- ## 1. Identified Speakers ### 1.1 Named Speakers | Speaker label in transcript | Identity source | Stated role | Notes | |---|---|---|---| | **"Ple"** (transcript label) | Title lists **Palak Agarwal**; self-introduction in transcript | Lead developer relations at Reductto | Transcript label "Ple" is likely a transcription rendering of the title name. Identity match is inferred, not confirmed in-transcript. | | **Omar** (addressed by first speaker; self-referred as "Omar" in the transcript's handoff) | Title lists **Omar Alhait** | Founding engineer at Reductto | Handed the session to Omar for the technical segment. Later speech is attributed to Omar on the basis of this handoff. | ### 1.2 Unnamed or Ambiguous Speakers - **Audience questioners:** Several unnamed attendees ask questions. Their speech is marked with generic speaker markers only. - **Unattributed responses:** Some answers appear without a clear speaker label. Examples include a response beginning "Man, if I answer that question, I might lose my job tomorrow" and a response beginning "No, no. So I'll explain." These are **not reliably attributed** and should not be assigned to a named speaker without further evidence. - **Possible Alvin response:** The transcript records a request to Alvin ("Alvin, did you hear that?") followed by "No, no." It is **uncertain** whether Alvin is the speaker of that line. ### 1.3 Referenced but Non-Speaking Individuals | Name | Context in transcript | Role as stated | |---|---|---| | **Riley Walls** | Original builder of JMail | Co-creator, per first speaker | | **Luke** | Described as a founder at "Kino" | Co-creator of JMail, per first speaker | | **Alvin** | Described as having "worked on our hybrid OCR model" and was on call during parsing | Reductto staff, per the speaker who discusses him | | **"Paula"** | Referenced as having "touched on this a little bit" | Unclear. Possibly a reference to Palak; **transcription uncertainty** | | **Woody Allen** | Mentioned in an example involving redacted documents ("I know that guy") | Named individual appearing in a document example. No role or claim is established by the transcript. | --- ## 2. Speaker Roles Summary - **Palak Agarwal (Ple):** Opening presenter; company background, capabilities overview, JMail summary, and handoff. - **Omar Alhait:** Technical presenter; describes the JMail parsing workflow, the flights extraction use case, schema setup, and answers many technical questions. - **Audience members:** Ask questions on validation, redaction, schema limits, entity resolution, figures, benchmarking, and product use. --- ## 3. Referenced Sources and Third-Party Claims ### 3.1 Referenced Sources - **Nvidia paper:** Speaker says Nvidia published a paper on citation determination, which the speaker says they "just found out about like yesterday." Referred to informally as "find everything or something like that." **Title and details unverified.** - **ChatGPT:** Mentioned as a comparison point for a cover sheet test. No claim about its results is established. - **"ARC AGI data set":** Mentioned in passing as an example of a benchmark dataset. ### 3.2 Third-Party Claims Stated by Speakers | Claim | Attributed to | Source channel | |---|---|---| | Reductto raised $108 million from investors including ACCNC and Benchmark | Palak Agarwal (Ple) | Speaker assertion; no external citation given | | Reductto has processed over two billion documents | Palak Agarwal | Speaker assertion | | Reductto customers include Harvey, Scale, and a top-five global hedge fund | Palak Agarwal | Speaker assertion | | JMail was built in five hours in November, the night the Epstein files were released | Palak Agarwal | Speaker assertion | | JMail had over 450 million visits and 18 million users with access by February | Palak Agarwal | Speaker assertion | | Reductto parsed over three million pages of documents for JMail | Palak Agarwal | Speaker assertion | | Redaction in some released files was inadequate; some files exposed underlying content | Omar Alhait | Speaker's personal review, stated as observation | | "Our tool was working a little too well" | Omar Alhait | Speaker's characterization | | Reductto "often" wins head-to-head comparisons with customers | Unnamed speaker (likely Omar or Palak) | Speaker assertion; customer tests not presented | | A schema with 156 fields was used recently | Unnamed speaker (likely Omar) | Speaker's account | | Nesting in schemas is limited to four or five layers | Unnamed speaker | Speaker's account | --- ## 4. Promotional Segments > **Flag: The following segments are promotional. Claims within them are self-reported and unverified in this record.** - **Company introduction (opening):** Funding, customer list, document volume, and product positioning ("agent document platform," "the layer that sits right before your model"). - **Product capability statements:** Five capabilities (parse, split, extract, edit, classify) and claims about the rasterization-based approach and agentic OCR framework. - **Product self-positioning:** "the premier document extraction solution on the market" (stated as confidence, not evidence). - **Benchmarking announcement:** Speaker states benchmarks will be released "soon" and that Reductto is "very confident" in its models. - **Studio sign-up and self-serve offer:** Studio access made self-serve for the session; QR code provided for sign-up. - **Hiring call:** "If you're interested about these things, we are hiring." - **Prize and swag offer:** Prizes and swag offered for interactive exercise demos. --- ## 5. Comment and Availability Limits - **Curated metadata:** No curated metadata was supplied beyond the video title. The title is the only source for speaker identity. - **Comment availability:** No information was supplied about comments on the video. **Comment channel unavailable for this record.** - **Timestamps:** No timestamps were supplied in the transcript. Speaker turn order is recorded from transcript sequence only. - **Transcript quality:** Several passages show transcription artifacts (for example "Ple," "redu relations," "Jmail," "Gemini" in a list where JMail features are described). Attribution in these passages is **uncertain**. - **Missing context:** Slides, screen recordings, and the Studio interface shown on screen are not available in the transcript. Statements referring to on-screen content cannot be verified against the visual record. --- ## 6. Attribution Confidence Notes - **High confidence:** Palak Agarwal's opening remarks and Omar Alhait's technical segment, given the title and the explicit handoff. - **Medium confidence:** Attribution of "Ple" to Palak Agarwal, given title match and transcript label. - **Low confidence:** Any unlabeled response, the "Paula" reference, and the Alvin response. - **Not established:** Identity of any audience member. Hi everyone, my name is Ple. I lead developer redu relations at Reductto. Um, and before we dive into Jmail, I'd love to give you a little background on what we do. Uh we're an agent document platform which basically means we help teams turn messy unstructured documents into data that AI can actually use accurately. Um to give you some context in the last three years we've raised 108 million from investors like ACCNC benchmark and more and processed over two billion documents across customers like Harvey Scale and a top five global hedge fund. Um, and operating at that scale means that we've basically dealt with every document you can possibly think of. Um, and we've iterated reductive product to handle anything. Um, now getting to AI to work on a clean PDF with a frontier model is not that hard, but the truth is that most of enterprise documents are unstructured. That means like scan documents, rotated documents, charts. Um, and that's when things get really complex. Reductto is the layer that sits right before your model. Um we handle complex layouts but also um as well as post-processing so you can focus on building your actual product. Um the reason this works is that we take a rasterizationbased approach that means we look at your document like a human would look at the document instead of the underlying embedding. Um everything is powered by our agentic OCR framework where rather than making a single pass and committing to an answer the model flags things that it's uncertain about corrects them and then moves on to the next step. Uh we'll give you access to our studio. Um we've made it self-s served just for this session. Uh but in total we have five core capabilities. Parse, split, extract, edit, and classify. Um now a quick show of hands. Who here has heard of Jmail or looked through Jmail before? Okay. Wow, that's a that's a good chunk of people. Um, but I'll I'll give a quick rundown in case you haven't. So, Jmail was originally built by Riley Walls and Luke in five hours last November. That's when the Epstein files were released. Uh, the concept is basically Gmail forked and you can log into the inbox like your Epstein and then that grew into a full suite. So you can think of like J drive, JFlight, J, Amazon, J photos and so much more. Um by February there were over 450 million visits and 18 million users that had access Jmail. And we're really proud to share that Reduct was behind parsing all of the documents. And that's not a small number. It's over three million pages of redacted PDFs, scanned documents, and messy government files as well. And to give you an idea, like this ranged from anything like really complex forms and tables to like messy handwriting of like so many different people. Um, now I'm going to hand it over to Omar, who's one of our founding engineers and worked very closely with the Jail team back in November. Um, and he'll give you a technical rundown and more. \>\> Alrighty, who's ready to talk about some documents. Yippee. All right. So, um, yeah. So, uh, walking us back to, you know, a very fateful night in November, right? Um, I was talking with the founding team and we were trying to figure out, you know, what would be a great way to use Reduct with this kind of transformational cultural event that was, you know, going to be unveiled to the public, right? Um it just so happened that um you know we're very close to Luke uh who is a founder at Kino and is working downstairs and we were all just kind of talking about you know what would be cool to build what would be funny. Haha. Um and then uh it kind of snowballed into this idea of like what if you could um you know sign into your email as if you were Jeffrey Epstein and view um you know your email as if you were him. And so um you know it was a really really cool concept as a product but there was one really hard problem to solve that you know was basically a barrier between us and the productized solution. um and you're looking at part of it, right? So, it's really really like I I would urge you if you haven't done this before to send this like uh you know uh cover sheet to Chad GPT and try to get some results out of it that and and just see how accurate it is, right? It's a very very complex problem where you know layouts are um pretty hard to understand. The reading order of this is also somewhat subjective, right? Um, and so we needed something to basically solve this bottleneck so that we could work on all of these cool uh little, you know, products downstream. And so this is where Redto came in. So I'm actually going to show you guys um what we had used for a couple of our products, right? So Oh yes, let me do this real quick. Alrighty. Whoops. Gonna bring this over. All righty. So, here you see a cool product, right? JF flights. Basically, all of Jeffrey Abstein and his affiliates flight history, right? This guy was flying people out. He was flying diplomats out. He himself was flying many places to and from his island, right? Um what was basically the barrier between us and finding out finding all these flights were these pretty shoddy handwritten documents, right? Um again, if you were, you know, if you thought that cover sheet was a little bit rough, think about handwriting, right? So we can see here a pipeline that I had actually set up way back when uh when we were trying to build a good config to basically make our parsing really really good, right? And so in this case uh we had for the for the flights use case, you know, an idea had flown out that like what if we um you know spin this off as a completely separate product where you could just see all of his flights. Um and so what that meant is taking all of his flight documentation and then applying a separate you know extraction config for it. And so what you'll see here is um kind of a little tour as to how Reduct works, right? So Reduct uh within the document extraction use case first parses the document, right? And so this kind of shows you, you know, you could stick any document that you would like here and you could just click run, right? Configure any of our bells and whistles and see real-time results, right? So this was sort of the canvas for myself that I was playing around with to kind of understand before I start, you know, scaling this up to a million different documents and run up a quick check on Reduct's, you know, on Reduct's uh um you know, uh receipts, let me make sure that our um extraction accuracy is what I would expect it to be. And so here is kind of what we ended up with. Um you could see here for a couple of these different documents, you know, some redactions that we had to deal with. Um Woody Allen, I know that guy. Um but yeah, just like a lot of different um you know, use cases that we had to handle through one extraction schema um for the flights use case, right? And so we parsed all the documents uh very quickly. And actually a fun story about this um is Alvin in the room? Alvin is in the room. So, um, back when the, uh, the, uh, first, uh, drop came out, I was paging Alvin maybe like, you know, a couple times a night, uh, he was, he just happened to be on call, uh, the night that I was parsing all these documents. And we were trying to parse them very, very quickly. And so, we put a, you know, a decent amount of stress on our infra. And so, Alvin was sending me a lot of fun messages late at night like, "Hey, bro, can you slow down?" Um, but yeah, we got through them. We got through them in time. And then um once we had this kind of corpus of documents that we were able to um you know um kind of take as a ground truth, we then spun off a a billion different products, right? And so Paula kind of touched on this a little bit, but I'm going to go back to Gmail. So, you know, we we spun up any anything from Jazm to Jlights to Gemini, right? Um yeah. So, and I and also JCAL. This was actually a product that I um worked on myself. So, some fun stuff there. Um cool. And so, I guess you know if you could kind of take uh anything out of this, I do want to say actually um yeah, so if you could take anything out of this, right, like the simplicity from this is really like you know getting a schema, right? looking at these results, making sure that the results look like what I would expect, and then just deploying. Right? So, if I was to deploy this code snippet, I'll just redeploy here for our use case, and I can get either a direct API call or just a pipeline code snippet that I can invoke very quickly, right? Um so the name of name of the game here is like stick your documents in this platform and then immediately start um you know visualizing your data and you could immediately also productionize it uh afterwards. So I'm going to stop here real quick. Um do we want does anybody have any questions thus far about um Jmail or Reduct in general before we can kind of start uh working on a little interactive exercise? \>\> Yeah. Yeah, \>\> great question. So, we can actually come up with this for you, right? Um, you know, my uh my fun analogy here is that like your extract schema is sort of like the paintbrush on your reductto canvas, right? So, it definitely drives everything that you um you know, you get out of the schema. So, for example, right, I could create a new pipeline here, right? and create a new extract pipeline and just call this I don't know let me make a resume schema because I want to parse some résumés right \>\> oh whoops sorry about that actually I'm going to do this real quick so anyway I I'll do this again because it's very simple so I'll create a new extract pipeline here by the way we could do a lot of things with documents par split extract, edit, even classify. Um, and so what I'm going to do here is create a resume schema. Oops. Uh, my Wi-Fi is not being helpful with me today. There we go. \>\> All righty. So, I got a fun schema here. And now it's up to me to basically decide whether or not this schema is like satisfactory or not. Right. it it's really given it's going to give me exactly what I'm asking for and you know once I plug a document in here I might realize like ah this is actually not what I want right so I have a bunch of handy dandy resumes I'm going to stick them in here upload and then just run this so yeah um I hope that answered your question any other questions while We wait for this. \>\> How do you validate? \>\> You're talking about the loading state. Uh that's just like a fun loading state at the end of the day, right? Like our product is like a really, you know, it's a suite of different models uh and different VLMs that we deploy, right? Um I'm I'm \>\> sorry, it's not the I was following what you were saying. \>\> Yeah. \>\> Oh, that's a great question. So, if I'm understanding correctly right, what you're saying here? \>\> Yeah. Yeah. So, this specific um this specific like schema generation that I had just used is really out of the box and it's just kind of like a a quick LLM call that describe like builds a JSON schema exactly for what I asked for. However, we do have an enhanced schema generation, right? And so what this will do is let's say I've parsed my documents, it will then take the output of like what's in the documents and tailor a schema description directly for them. So like if you're looking for example for, you know, something just really quick to just get up on the screen and just see some results, I would recommend regular, you know, uh schema generation. But if you are a lot more interested in like nuance, uh I definitely suggest parsing the documents first and then kind of passing them in. All you would have to do is just click enhance schema generation. And what we will be able to do is um you know run the documents first, try to get an understanding of what's in the in the documents so that we can tailor these schema descriptions directly for that. Make sense? \>\> Cool. Cool. Cool. Cool. you had some reduction. \>\> Yeah. \>\> Correct. Yes. So I mean yeah like at the end of the like this is a great question. Right. So reductto actually parses PDF metadata as well right. So some like sometimes uh and this is honestly testament to like uh who was doing the redaction, right? Sometimes the redaction was actually not that great, right? And so what that ended up being or the responsibility ended up being on us as the JML team to then have to do a bunch of redaction, right? Because you can't just stick a box on a PDF and then expect it to actually be fully redacted, right? Um yeah, seems like there was some uh a lack of understanding when whoever who whoever was cooking up that redaction. um I will say it's like for the files that came out and myself looking through them that's not the case right some files were actually redacted correctly um but there was some files where we were just able to see who was like you know who the redaction was behind and um so it became a really really serious you know situation right because we're dealing with you know people's data that like um you our data is redacted for a reason, right? And uh you want to really make sure that you're not the one that like ends up getting sued at the end of the day because of this. Um and so yeah, there was a you know a a heavy kind of level of responsibility on our shoulders to make sure that whatever was intended to be redacted was actually redacted. Our our our tool was working a little too well. \>\> Cool. Yeah. at the front and then I'll after you \>\> questions or thousands of different things. \>\> Yeah. Yeah. Yeah. Uh it's a great question. Um I'll give you some like you know an example, right? There was there was a schema that I was looking at maybe on Friday uh that had like 156 fields, right? um and all of these different fields, you know, need like they were requesting something completely different, right? Uh and so I urge you to kind of put our schema to the test. I think like our um the like nesting uh limits to our schema or maybe like four or five layers. Uh but in if you want to, you know, ask for everything in the world, you can still technically be able to fit it in in a schema. \>\> Do you have any capabil resolution \>\> entity resolution. Can you give me an example? \>\> So this is a good question. Um there is a lot of post proc postprocessing that we end up doing, right? Let's say like on the extraction side. Um I'm personally a little bit farther abstracted away from like the ML side of things. Uh but I can tell you that we are doing a decent amount of post-processing to basically link um you know entities together. For example, we have like a citation model, right? Where we know we have, you know, one model that could be responsible for extraction, right? But then there might be another model that's also responsible for once this data is extracted, where is each piece kind of extracted from, right? Uh Nvidia actually did a cool um paper on this uh that they that I just found out about like yesterday. I think it's called like find everything or something like that. um where they try to address the bottleneck of like you know citation uh determination and like the speed at which you could find a citation for something that's in a document. \[snorts\] If you're interested about these things, we are hiring and so uh come speak to us after. Sorry. \>\> Questions. \>\> Yeah, absolutely. So, let me try to see if one of the résumés I uploaded has an image in it. \>\> So, let's see here. Right. So, um we have some figure models, right? that are basically determining. Let me actually also rerun this real quick so that it can return figures. \>\> Ah, that's a great question. Um, Alvin, did you hear that? \>\> No, no. So, I I'll explain. The reason why um I I asked Alvin is because Alvin worked on our hybrid OCR model, right? Um and so we have a specific OCR uh like you know configuration that you can enable here that will pri figure out kind of intelligently what to prioritize, right? Um so in some cases we will actually pick out like just you know strict OCR data or we might pick out like um you know metadata from the PDF. Um yeah we've done a lot of work here. Uh and it's it's not a simple sol like it's not a simple answer. Um this is something we could do an entire different talk on. \>\> Yeah. So I'll be frank with you like this is actually exactly what this pipeline is doing, right? So like we first parse the like the Hold on, let me turn return figures. Cool. So, um, while I rerun this, what we're doing here, let me pick a different example. Ah, actually, we're gonna have to wait now. But what we're actually doing in like extraction is taking the parse results and then feeding them into, you know, some extraction pipeline downstream. So, like parse is kind of like the um, you know, it it is it is what made reductto reductive in the first place, right? And then we can do a lot of cool things, you know, downstream of reductto. So uh you know once we have that parse content for example right we could split you know the document into different regions and figure out like if I'm parsing some you know a math textbook I want to understand like where exactly every chapter you know starts and ends and then for each chapter I might want to do like an extraction based on that right and uh get you know the chapter summary or something like that right uh so parse is really the kind of foundation for all of these other agentic um document processing u features. \>\> Man, if I answer that question, I might lose my job tomorrow. \[laughter\] \>\> So, um I mean it's a Yeah, continue. \>\> I think it depends on like what pro data we collect um as well. So we specifically um train on like certain types of data. If we find that it's doing poorly on certain types of data. So we see that like long context recall is not great. Then we got to like try and fix that. Specifically for extract um it's it's not really like Neil in a haststack. It's like all the needles in a haststack if you think about it. So that's like a really um challenging like research problem that our MLES are like somehow able to figure out pretty well. But yeah, happy to chat more later. \>\> Yeah. \>\> Oh, we've been neglecting you guys. Yeah. What's up? You you you'll be Yeah, you should you should stay tapped into our uh like our our socials and you'll find out about this very soon. I think like benchmarking is you know always a topic of discussion and something that we want to really stay on top of especially because you know somebody who is testing who wants to do document extraction might not you know know where to go or who's better right without actually testing themselves. Uh so that's why benchmarking is like something that's you know we're we're prioritizing a lot uh especially in the coming months to to try to show people like how well we are doing. you know, we try we're we're very confident in our models and us being like, you know, the premier document extraction solution on the market. Uh but there need to be uh more, you know, um data points that we can rest on and that the, you know, entire industry can kind of see at face value uh without having to go test themselves or pass in the all entire ARC AGI data set to you know try to understand uh you know how well reducto is doing against another solution. \>\> Yeah. So we're going to release some benchmarks soon. But the real deeper answer here is you typically have to make your own benchmarks unfortunately. So every single one of our customers typically have some benchmark. They're like, "Oh, we're evaluating document providers. Uh we're going to run some head-to-heads uh of like reducto versus like all these other like use cases and you know sometimes they don't use like maybe our APIs really well because they use the wrong config. So we work closely with them like hey turn this on turn this on you get this trade-off and then uh we let them decide um and then like we often like win these headto-heads in like performance. So as with most projects you know gather a simple data set you can do some like vibe eval just look look in studio see if the outputs make sense and then like as you want to scale it out then get like 100 documents a thousand documents do something more systematic and you can also work with our team where we have a lot of people to you know work with customers to help you do your emails but yeah \>\> cooly um any more questions yeah sure well yeah absolutely right um I I think so I'll answer this uh pretty honestly right I think when I was working on this solution right or I was working on this problem I was trying to figure out like what is a good productized way to you know surface our reducts parsing right um and to be frank with you right like I came up with something that was pretty shoddy in the beginning um like basically a you know rag chatbot application where you can ask anything about the emails right and it might be something that would be really really useful for like a journal journalist, right? However, um I think it's testament to the hundreds of millions of people that you know were, you know, using Gmail and and the tens of million that still, you know, log on uh from week to week nowadays. Um it's it's testament to the fact that a nice product on top of a really really nice novel, you know, uh document extraction solution is what is going to kind of be a onetwo punch here. \>\> Yeah. Like would you read three million like scan documents? Honestly, no. And honestly, when I saw the drop, I was like, "This is like way too much work for me." But once Omar built it, I just like logged on and like started searching like random like famous people for fun. And so that's the beauty of it, right? Like I think like unstructured data is like everywhere. And sometimes all you need to take all you need to do is like to extract it and then like do whatever you want with it. It's basically what all our customers like do um conceptually. So I think Gmail is a pretty fun example but it's actually very u it's exactly what happens in the industry. \>\> Yeah. You seen that? Come here. It's it's just hard work, right? Like you know we we have a data labeling team, right? We have to go like par you know like we have to sift through a lot of documents if we're going to train a new model on top of it. Um and be very very certain in the outcomes of you know or or the the sanctity of that data, right? Um and so the short answer for you is just \[snorts\] like it's a lot of hard menial annoying work, right? Uh but that's really what comes into like the beauty of a machine learning model at the end of the day, right? There's nothing that you know really beats that like really really hard, you know, just wrote classification work uh that then compounds into uh model training and then you know then you can kind of figure out like how to stagger your data and like how to train you know on on top of your training set. At the end of day, at the end of the day, you still have to label that data. \>\> Cool. I think we'll take Yeah, we could take one more, but um Yeah. Yeah. So, to repeat the question uh and let me know, you know, how how accurate it was, right? But, uh it seems like, you know, like there are cases in which uh you need to really customize your logic on top of different documents. Uh whether it be corresponding to specific models, right? Sometimes there might be metadata set up in specific ways um in specific documents and you want to really like uh condition um for these specific use cases, right? Um this is a fantastic question, right? And so this is where our agentic um section really comes in, right? So you can actually apply all of these different, you know, uh, configs and apply like, uh, system prompts on top of separate models that will do specific processing that's tailored directly to what you're asking for. So for example, right, if uh you want to do some complex figure extraction, let's say I have a bunch of logos and I want to try to determine like you know what differentiates like I don't know uh some you know uh Lincoln Financial from like Google and like how to separate those kinds of logos, right? I could add some additional color here within our uh you know prompts uh in this config to custom kind of tailor u the outputs that I'm looking for. So if you wanted some specific metadata here, let's say like uh you know some layout might be like really really hard to read in uh I don't know like a construction blueprint, right? I would spend a lot of time in the uh layout prompt kind of tailoring to try to understand uh how well you know uh my current extraction solution is mapping across all of my different um you know construction blueprints I guess right cool. Um does that answer your question? Fantastic. All right. So now we want to kind of um spin this off um into an interactive exercise. Right. So, um, if you guys would like, we're going to basically give you guys, you know, um, however much time you would like. I think we have about 30 minutes left. Um, and you could sign up today at, uh, at studio and essentially, uh, just get started, uh, on some document extraction solution, right? So, what what you'll see here in a QR code is something that you could basically paste directly into a cloud code or a codeex or whatever, and something you could just get started uh, on uh, document extraction with immediately. Uh so we're going to give you guys about 30 minutes and by you know maybe around like five minutes uh like at the five minute remaining mark we'd love to kind of see what you guys have cook uh cooked up and we have a bunch of cool swag and a couple of cool prizes for you guys uh to just kind of show us what you got um with respect to document extraction. Um it could totally be just like an idea um and like a singleshot prompt but uh feel free to just kind of uh give it a whirl. \>\> Sound good? Also, we'll be kind of like circling around if you guys have any questions as to how to use Redto. Uh, I want to come work for you guys, you know, I want to hear about your models, how you guys train, whatever. Um, we are happy to answer. Sound good? \>\> \[music\]