Anuj Iravane of Anterior explains how the company handles highly unstructured medical data — scanned fax bundles with handwriting, tables, and images — that cannot be retained under contract, by generating synthetic clinical records instead. He describes running the inference workflow backwards: sampling a label and reasoning trace, then constructing the record that would produce them, aided by policies modeled explicitly as decision trees. The talk covers a coarse-to-fine generation pipeline with consistency checks, correct-by-construction labels, clinician ownership of the pipeline as skills, and results showing roughly 90% synthetic datasets with clinicians distinguishing synthetic from real data only about 60% of the time in blind review. # Channel Presentation Observations: "Don't be data poor — Anuj Iravane, Anterior" ## Explicit Self-Description (Creator Claims) - **Speaker role**: "my name is Anoj. I uh I lead AI at Interior" — the speaker introduces himself as the AI lead at Anterior. - **Company description**: "We are a clinicianled AI company um built for health plans uh backed by SEOA and NEA... we run AI transformations for health plans." - **Claimed product scope**: "we build um agents for uh several high stakes uh healthcare administrative workflows in production uh things like pri authorization, payment integrity, uh heat measures etc." - **Work characterization**: "a lot of the work that we do can actually be summarized... in the same way. It's uh policy guided decision-m over highly unstructured data." ## Intended Audience - The talk addresses a **technical AI/engineering audience** at what appears to be a conference or meetup: - References a prior talk: "there's very little exposure to this data source in the pre-training data corpus" attributed to "Aish mentioned in his talk earlier." - Audience familiarity assumed with AI topics: "I'm sure you must have heard this like enough times today already but uh in healthcare uh the the baselines for accuracy are just uh exceptionally high." - Framed as advice to peers: "some takeaways if you're looking to build your own synthetic data pipeline in healthcare or even another domain." - References research context: "There's been a lot of focus on synthetic data recently... frontier labs uh striving to generate synthetic data for continued pre-training for RL for computer use for agents." ## Claimed Scope of the Channel/Content - **Topic scope demonstrated**: technical deep-dive on synthetic data generation for healthcare AI evaluation, including pipeline architecture, policy modeling, and clinician-in-the-loop workflows. - **Breadth beyond healthcare**: the speaker generalizes lessons to other domains — "anywhere uh the data you need is ephemeral, sensitive or even expensive to label, you can think about uh generating data yourself." ## Observable Presentation Patterns - **Results-oriented presentation style**, with specific claimed metrics: - "roughly 90% of our data sets are already made of synthetic data." - "in a blind review clinicians were not a were only able to distinguish uh synthetic from real about 60% of the time." - **Practitioner-first framing**: emphasis on production deployment rather than theory — "agents for uh several high stakes uh healthcare administrative workflows in production," "many customer deployments." - **Honest caveat delivery**: "So room for improvement but... it's quite promising avenue for us to invest more." - **Structured takeaway format**: the talk closes with a numbered list of takeaways ("try reversing your inference workflow... give your domain experts the keys"). ## Evidence Gaps / Not Observable - No channel-level metadata was supplied; observations rest solely on title and transcript. - The talk is a **one-off presentation**; no explicit statements about the channel's broader content strategy, upload cadence, or mission were made. # Delivery Observations — "Don't be data poor" (Anuj Iravane, Anterior) ## Tone & Overall Style - **Conversational, informal technical talk** — delivered like an engineering walkthrough rather than a polished keynote. - Consistent use of **"right?" and "uh" as verbal connective tissue**, giving a thinking-out-loud quality: > "the unstructured data looks something like this, right?" > "So back to our idea of like reversing the process, right?" - Self-deprecating and humility-marking moments: > "but but who came up with this, right? like who who am I to know anything about what a good um medical record looks like?" ## Vocabulary & Recurring Phrases - **"Uh" appears extremely frequently** throughout — likely the single most common filler in the transcript (nearly every sentence). - Repeated core vocabulary: **"data," "pipeline," "synthetic," "diverse/diversity," "generate," "evals," "policy," "clinicians," "records."** - Habit of **framing ideas as rhetorical questions** and answering them: > "and the moment you say generate like the first thing that comes to mind is okay can we can we try to use an LLM to generate synthetic data" > "So, how do we know if this is any good?" - The verbal tic **"so, so" / repeated-word restarts** recurs: > "So so what this talk is about is like what do you do when..." ## Teaching Habits & Structure - **Numbered/parallel takeaway structure** at the end: > "try reversing your inference workflow. Diversity should always be sampled from a from an appropriate distribution... and the fourth most important thing..." - **Concrete example anchoring**: abstract concepts are grounded in specifics (CPAP device policy, 300-page records, 200-case customer sample, blind review at 60%). - **Audience-acknowledging asides** — references the shared event context: > "I'm sure you must have heard this like enough times today already" > "as Aish mentioned in his talk earlier" - **"Quick aside" habit** — twice flags digressions explicitly: > "So just a quick aside on policies." > "And just an aside, generally, I feel like skills are really an amazing interface..." - Uses **relatable analogy**: > "it's like imagining if you wouldn't ask an LLM to write a novel for you in one shot, right?" - **Meta-commentary on the domain's difficulty** framed as "fun facts": > "a not so fun fact uh is that I think around 70% of medical communication still happens via fax" ## Communication Patterns - **Hedging with "I think" / "I personally believe"** before claims: > "I personally believe LLMs are a fantastic tool to generate synthetic data" > "I I personally think it's a very fascinating source of data" - **Emphasis through repetition under uncertainty/excitement**: > "it's it's it's it's close and I'm I'm quite quite it's quite promising" *(stuttering repetition here suggests live pressure or enthusiasm, not a stable pattern on its own)* - **Wordplay bookending**: opens on the title "don't be data poor" and closes by inverting it: > "Uh, and hopefully you won't be data bored." *(Note: "bored" vs "poor" may be a transcription artifact of a spoken pun — flagged as uncertain.)* - Closes with a **portability statement**, generalizing beyond healthcare: > "anywhere uh the data you need is ephemeral, sensitive or even expensive to label, you can think about uh generating data yourself" ## Uncertainty Notes - Filler words and restarts are **directly observable and pervasive**; confident claim. - Whether the heavy "uh" density reflects the speaker's habitual style or transcript quality **cannot be fully separated** from the automated transcription itself. - Only one observable instance each of the closing pun and the snort (marked `[snorts]`), so these are **isolated moments, not patterns**. # Observation Record: "Don't be data poor" — Anuj Iravane, Anterior ## Context & Speaker - **Speaker**: Anuj (self-introduced; title metadata says Anuj Iravane), who leads AI at **Anterior**. - **Company framing (per speaker)**: Anterior is a clinician-led AI company built for health plans, backed by Seqoia and NEA (transcript spelling uncertain: "SEOA and NEA"), running AI transformations for health plans with agents in production for prior authorization, payment integrity, HEDIS measures ("heat measures" in transcript). ## Core Problem Statement - Anterior's work is characterized as **policy-guided decision-making over highly unstructured data**: scanned fax bundles of medical records. - Claim: **~70% of medical communication still happens via fax** ("not so fun fact"). - Data properties: long tail of rare, nuanced cases; models an entire clinical trajectory; varied formats (handwriting, tables, checkboxes, key-value pairs, images). - **Constraint**: Contracts prohibit keeping, deriving information from, redacting, or anonymizing this data — "strict no, completely off the table." Nothing survives in persistent datasets. - Central question of the talk: *what do you do when the dataset you most need is also the data you're least allowed to keep?* - **Bet**: generate this data synthetically. ## Position on LLM-Generated Synthetic Data - **Claim**: LLMs are "a fantastic tool" for synthetic data; other teams have demonstrated this in and outside healthcare. - **Known challenges** (as stated): - One-shotting is hard — records can exceed 300 pages; "you wouldn't ask an LLM to write a novel in one shot." - **Mode collapse** in generating diverse/creative data, attributed by the speaker to two reasons: (1) little exposure to this data in pre-training corpora (referencing "Aish['s]" earlier talk), and (2) training objectives incentivize helpfulness, not creativity or diversity. ## Proposed Approach: Reverse the Inference Workflow - Forward task: unstructured data + policy → reasoning trace → label. - **Reversal**: sample a random label → sample a reasoning trace → generate data backwards. Diversity in sampling the first two stages conditions diverse data generation. - **Policies as symbolic decision trees**: Anterior explicitly models policies (e.g., CPAP medical necessity review) as symbolic decision-tree representations, which the speaker says improves accuracy and consistency in LLM workflows. - Key claim: sampling reasoning traces from a symbolic policy yields a **more uniform and effective prior distribution** than an LLM would, and can test scenarios beyond a production sample (a 95% score on 200 customer cases says nothing about rare edge cases outside that distribution). - Speaker notes **Cynthia** ("for those familiar") follows a similar pattern of sampling from symbolic causal state representations, as do others in the space. ## Pipeline Design - **Coarse-to-fine, layered generation**: 1. Patient invariants (biological sex, birth date, blood group). 2. Patient journey: ordered list of events/provider encounters. 3. Document plans per encounter. 4. Fan-out generation/hydration of actual documents. - Rationale: keeps token payloads efficient and allows scaling to long journeys without overloading LLM context windows. - **Refinement loop** with evals, including an LLM-based cross-document **consistency check** — important because documents are generated in parallel. - **Roundtrip check**: since generation started from the label, labels can be validated against generated records — "correct labels by construction," in theory skipping expensive ground-truthing. - All generation stays in **text/markdown**, not rendered PDFs — speaker argues state-of-the-art PDF parsers make rendering unnecessary for their purposes. ## Domain Expert Ownership - Two mechanisms: 1. **Human-in-the-loop steering** at each generation step; clinicians often model cases seen in production, including failure cases. 2. **Clinicians own the pipeline logic** via a skills-based workflow on an internal generic agent harness — adding a new document type requires only a new skill file, no engineering changes. - Broader claim: **skills are an excellent interface between AI engineers and domain experts**, especially in vertical AI. ## Results (as claimed by speaker) - ~**90% of datasets are synthetic data** (used for evaluation at the moment). - Claimed contribution to high production accuracy across customer deployments. - **Blind review**: clinicians distinguished synthetic from real only ~60% of the time — speaker explicitly notes "room for improvement." - **Just-in-time dataset creation**: datasets built before go-live without waiting for customer data, enabling edge-case simulation. ## Takeaways (speaker's recommendations) 1. Reverse your inference workflow. 2. Sample diversity from an appropriate distribution for your use case. 3. Emulate the real-world data generation process (e.g., provider encounters generating documents). 4. Give domain experts "the keys" — they, not engineers, drive recursive self-improvement. ## Scope Note - Speaker's applicability claim: a PHI problem isn't required — this applies wherever data is **ephemeral, sensitive, or expensive to label**. ## Qualifications & Tensions Preserved - The speaker hedges several claims as theoretical or provisional: "in theory you're able to test…", "in theory this is a really nice property…". - Blind-review fidelity is acknowledged as imperfect ("room for improvement… but it's close"). - Synthetic data is stated to be used **only for evaluation** "at the moment," despite results framing suggesting broader benefit. - The 70% fax statistic is presented without citation ("I think around…"). # Speaker Attribution & Provenance Record ## Video **Title:** Don't be data poor — Anuj Iravane, Anterior **Video ID:** `01a15ca7-cd78-7ca2-a721-e2229eab557d` ## Speakers ### Primary (and only) speaker: Anuj Iravane - **Self-identified role:** Leads AI at **Anterior** ("Interior" / "Antior" in transcript spellings — apparent transcription variants). - **Function in video:** Presenter/talk deliverer; introduces himself: *"my name is Anoj. I I lead AI at Interior."* - **No other speakers** appear in the transcript (audience addressed as "everyone"; no Q&A or dialogue captured). ## Referenced Third Parties & Sources - **Anterior** (speaker's company): described as "clinician-led AI company... built for health plans... backed by SEOA and NEA" — company facts are speaker claims. - **Aish**: referenced as a prior speaker at the same event ("as Aish mentioned in his talk earlier"); no surname given. - **Cynthia** (likely transcription variant of an organization, e.g., a company/research group): noted as following a similar pattern "of sampling scenarios from a symbolic causal state representation." Identity uncertain from transcript. - **"Frontier labs"**: unnamed, credited with work on synthetic data for pre-training/RL/agents. - **"Papers in the healthcare space"** and "several teams": unspecified, uncited by title. - **Clinicians at Anterior**: described as domain experts involved in human-in-the-loop review and blind evaluation; no individuals named. ## Notable Third-Party Claims & Statistics - **~70% of medical communication still happens via fax** — attributed as speaker's claim ("a not so fun fact... I think"). - **~90% of Anterior's datasets are synthetic** — speaker's internal claim. - **Clinicians distinguished synthetic vs. real records only ~60% of the time in blind review** — speaker's internal claim. ## Promotional Segments - **Opening company introduction** (early in talk): Anterior's backing, mission, and production workflows (prior authorization, payment integrity, HEDIS measures) — promotional in nature, flagged as such. - **Results section** (near end): claims of "very high production accuracy score," high-fidelity synthetic data, and "state-of-the-art PDF parsers" — presented by the speaker on behalf of his employer. ## Availability & Provenance Limits - **Comment availability:** Not indicated in provided source material. - **Curated metadata:** None supplied beyond title; no verified speaker bio, citations, or timestamps. - **Uncertainty:** Transcript contains apparent phonetic spellings (e.g., "Antior," "Anoj," "SEOA," "Cynthia," "heat measures"); exact names unverified from source. - **Data-use note (content-level):** Speaker states contracts prohibit retention of customer medical data, including derivative/redacted copies — relevant provenance fact for their claims about synthetic data. Hello everyone. Uh welcome to uh don't be data poor. Uh my name is Anoj. I uh I lead AI at Interior. Um just a bit about Antior. We are a clinicianled AI company um built for health plans uh backed by SEOA and NEA. Um and what we do is we run AI transformations for health plans. Um as part of which we build um agents for uh several high stakes uh healthcare administrative workflows in production uh things like pri authorization, payment integrity, uh heat measures etc. Um it's it's okay if you're not familiar with any of these workflows uh because a lot of the work that we do can actually be summarized uh in in the same way. It's uh policy guided decision-m over highly unstructured data. And the unstructured data looks something like this, right? You have uh uh you have these scanned fax bundles containing medical records full of patient information. Um a not so fun fact uh is that I think around 70% of medical communication still happens via fax. Um and fortunately or unfortunately this is the data that we end up working with the most. It is a very uh rich uh and information dense uh data that we see here. Um the data distribution here is uh it comes from a very long tale of rare uh cases with very nuance scenarios. Uh it models an entire clinical trajectory for a patient. Uh and every single person's journey is very different. Uh it also presents itself in uh varied formats. So you have like uh things like bad handwriting, tables, checkboxes, um key value pairs, images, um a lot of tough data to deal with. But I I personally think it's a very fascinating source of data that we see here. like it's it's it's like sort of like an observation through a very fuzzy lens over an entire person's lifespan. Uh it's really unique and I'm sure you must have heard this like enough times today already but uh in healthcare uh the the baselines for accuracy are just uh exceptionally high. Uh 95% is not good enough. Um at interior this is why we invest very deeply in data sets and evals. uh and these unstructured medical records are are a staple source of uh data for these evals and we we work with this kind of data in almost every workflow that we try to automate but the problem is we can't really keep this data u it's phrase it uh we can't even derive information from it and most of our contracts prohibit us from uh from doing anything like that um even things like uh redacting it anonymizing it and keeping derivative copies like there's a strict no completely off the table. So nothing really survives in any sort of data set that we want to persist over a period of time. \[snorts\] So so what this talk is about is like what do you do when the data set you most need is also the data you're least allowed to keep and the and the bet that we the answer that we put our bets on is that we can kind of synthetically generate this data ourselves. There's been a lot of focus on synthetic data recently. uh you've like frontier labs uh uh striving to generate synthetic data for continued pre-training for RL for computer use for agents uh so it's it's it's a hot topic and it's it's a hot topic on our minds as well uh and the moment you say generate like the first thing that comes to mind is okay can we can we try to use an LLM to generate synthetic data and I think you can I personally believe LLMs are a fantastic tool to generate synthetic data and several teams have already demonstrated uh this already there's been some papers uh in the healthare space outside the healthcare space people have successfully used uh LLMs to generate synthetic data for for different purposes there are some known challenges in trying to use these LLMs uh uh to create data especially we're trying to oneshot the whole process it's really hard to generate diverse realistic looking synthetic records and this is even more of a problem uh when you're trying to doing when you try to do this at scale so u often times these medical records uh are over 300 pages long and it's like imagining if you wouldn't ask an LLM to write a novel for you in one shot, right? So, it's the same reason why you wouldn't use an LLM to just one shot in synthetic record for you. Um, and LM seem to suffer from this very strange mode collapse problem when it comes to generating like diverse uh data, creative data. And I think there's two main reasons for it. The first one is uh like Aish mentioned in his talk earlier, there's very little exposure to this data source in the pre-training data corpus. Um, and today's objectives for pre-training and post- training are are largely uh they're only they're not incentivized for creativity or diversity really. They're incentivized to be helpful assistance. So with these challenges in mind, I'll walk you through like one of our approaches in how we uh manage to build a pipeline to generate synthetic data. Um earlier I mentioned our our forward tasks look something like this, right? You have workflows and tasks that start with some unstructured data and a policy um and you execute your policy against that data. You follow this reasoning trace through it u and you arrive at some sort of an outcome which is your label. So this is our forward task. Uh and the idea we had was to try and reverse this process. uh can we actually sort by sampling a random label um figuring out a reasoning trace for that label and then trying to generate data backwards from that. Uh the idea here being that if you can actually uh sample these two things uh with enough diversity u we will have we will be able to generate data that's conditioned on diverse set of inputs allowing us to kind of circumvent the diversity problem a little bit. Uh so just a quick aside on policies. We've talked about policies a bit but uh let me just clarify what these really mean. Right? So this is an example policy we have for for a CPAP device for patients. Uh this particular one is for a medical necessity review workflow. Uh and it it sort of outlines all these diverse set of conditions uh that a patient might have um in which a CPAP device should be approved or or rejected. Um so and this policy as well as many other policies you can think of these as uh essentially decision trees that outline all these sorts of conditions um um that that dictate how some outcomes are met. And at Antier actually we we spend a lot of time and energy in trying to model these policies explicitly as decision trees. We work with symbolic representation similar to decision trees and it helps us achieve a better accuracy and consistency score when executing them in LM based workflow. And and the reason why I'm bringing this up is that uh by having this sort of symbolic representation of a policy, you actually have a way to kind of deterministically sample different reasoning traces for a given outcome. So back to our idea of like reversing the process, right? uh this this sampling of reasoning traces from the policies uh what helps us get that diverse conditioning input to then generate medical records from uh and the key idea here is that the distribution here uh that we sample from is is a much more uniform uh and effective prior distribution than what you'd normally get from an LLM and one added benefit of sampling this way is that in theory you're able to test uh for far more scenarios than you would likely get from production data sources. So what I mean by that is like say you get a sample of 200 cases from your customer uh um and and and you try to like have an eval that measures performance against that and you get a 95% score uh it doesn't really tell you about uh what you what your performance would be in those rare edge cases that are not in that data set. There'll always be rare edge cases uh that outside that distribution just because of the fact that our data is so uh highly variant. So for those for those familiar with Cynthia like uh they follow a similar pattern uh of sampling scenarios from a symbolic causal state representation there's a few other folks in the space who are working with these symbolic representations to uh to generate diversity and synthetic data generation. So let me walk you through the rest of the pipeline. All right. So uh once we have this diverse set of samples as our conditioning input, what we did was we built an LLM based pipeline that uh follows uh a course to find pattern to progressively uh build up a medical record layer by layer. So here we first start with creating some patient invariants like the biological sex, the birth date, the blood group. uh we use that along with our reasoning trace uh with NLM again to produce an ordered list of uh events and provider encounters that a patient might have had and we call this the patient journey. So this is a high level uh you can think of as a high level uh overview of what a patient might have gone through in their lifespan um captured by a list of events on a high in natural language and in the real world it is actually only during these uh encounters provider encounters that documentation is really generated at least for the data that we get uh most of our data source data is generated during these provider encounters. So we model exactly that in our pipeline. uh uh we first generate a document plan for each encounter and then based on that and the preceding history of the of the patient. We uh we fan out into generating the actual documents uh um to hydrate them with actual synthetic information. Uh and this course to fine layering uh is actually what allows us to keep uh the different prompt payloads in the pipeline very token efficient from both input and output perspective while also enabling uh we this also helps us enable to scale across uh longer patient journeys. So you can scale this uh pipeline. You can have a much longer patient journey uh and you can just fan out and generate documents that way without uh overloading the context windows of your LMS. Finally, we have the sort of refinement loop in the end uh that we that uses a set of eval to provide feedback uh to improve specific parts of the generated documents. Uh for example, one of the eval is an LLM based check for consistency um between all documents. So this makes sure that there's no contradictions or uh u inaccuracies or conflicting information between two documents that are generated. And this is important because we we have a parallel fan art process uh that is used to generate these documents independently. And because we started with the labels for this particular uh pipeline run, uh what we actually also have is uh an ability to kind of use those labels uh run uh and and compare those against the generated uh uh medical records to see if uh the task that we originally used actually matches is the data is in concordance with the task inputs and outputs. So we can do this sort of roundtrip check to ensure that our data is actually in sync and by default get correct labels by construction. So um in theory uh this is a really nice property to have like you can basically skip the ground truththing expensive ground truthing process you need uh for for data for for your data. Uh one thing to clarify here is that uh so far all the generation has been happening just in plain text and markdown text. Um it is possible to go from that to a rendered PDF. uh but we don't really see much value in in doing that uh because uh we have state-of-the-art PDF parsers today. They're available to everyone and they just allow you to convert any sort of complex PDF into a nice markdown representation. So all of the synthetic generation uh um and evaluation happens in the text domain. So this is just an example of like a pipeline that we created from scratch and it's uh it's very easy to build. It's largely fully LM based. Um but but who came up with this, right? like who who am I to know anything about what a good um medical record looks like? U so how do we know if this is any good? And I think this has been mentioned a few times today already but like you really don't like uh no AI engineer would ever would like you want your domain experts to be the ones telling you what's good, what's not good. Um and which is why we believe that uh it is of great value to empower your domain experts to own your whole data pipeline. And specifically we uh we do this in two ways right uh we enable our clinicians to kind of interject at each point u in the generation process with a human in the loop mechanism. So at any point a clinician can steer the generation process to make a medical record in the way they want it. Uh we often see our clinicians use this uh to to first look at cases that happen in production, get some interesting ideas uh and then use that uh use those ideas along with this uh the steering in this pipeline to make cases that look similar to what we might see in production or they have seen in production. And this is what makes the data generated from this really useful, right? Like you can actually model your uh your failure cases beforehand or even after they after you see them in production. And secondly, I think most importantly, we let our clinicians also own the whole logic of the pipeline. Um, we do this by modeling the whole pipeline as a skills-based workflow running on a generic uh agent harness that we built internally. So, every every uh kind of section here you see uh all the way from the patient journey to the document generation to the document enrichment to the evals all of these things are skills uh that run on our agent harness. As an example, if a clinician wanted to say maybe add support for a new document type, let's say for a new customer, they wanted their intake forms uh to look a certain way, uh they could easily just make a new skill file for it, uh attach it to the pipeline, um and and and voila, there wouldn't be any engineering changes required. So, it's completely clinician own from that perspective. And just an aside, generally, I feel like skills are really an amazing interface between AI engineers and domain experts, especially in vertical AI. uh we see this being um we we see this being modeled in several of our other workflows both for internal use cases and in production as well. So some results from this right so even though we only really use uh synthetic data for evaluation at the moment there's already a lot of merits that we get from it. Um roughly 90% of our data sets are already made of synthetic data. Uh this helps us uh maintain a very high uh production accuracy score um for across many customer deployments. Uh the pipelines that that I just showed you uh already we are able to achieve a a very high fidelity on this generated data. Uh in a blind review clinicians were not a were only able to distinguish uh synthetic from real about 60% of the time. So room for improvement but uh uh but but it's but it's it's close and I'm I'm quite quite it's quite promising avenue for us to invest more more here and and the the the the fact that is the most interesting to me and uh what I really what I'm really excited about is that all of these data sets well most of our data sets today then are created just in time for these customer deployments right you can you when you have the ability to like create data from scratch so quickly uh you can kind of uh you don't need to depend on on on waiting for data from a customer you kind of just model all your edge cases, simulate them and test your workflows before you go live with the production class go live in production. So some takeaways if you're looking to build your own synthetic data pipeline in healthcare or even another domain um try reversing your inference workflow. Diversity should always be sampled from a from an appropriate distribution for your use case. uh try to emulate the process in which uh uh the data was actually generated. So like I showed you we were trying to sort of like we were using LLMs. We're trying to emulate how uh our medical records might actually be generated during patient encounters. Uh so and I I would highly recommend you try doing that. Uh and the fourth most important thing I think is uh when you're when you're making a data pipeline like this, it's really important to give your domain experts the keys because uh these are the people who know uh about your data and and and they will help you uh drive towards a recursive self-improvement and not the engineers. Cool. So you don't need a PHI problem for this. Uh anywhere uh the data you need is ephemeral, sensitive or even expensive to label, you can think about uh generating data yourself. Uh, and hopefully you won't be data bored. Thank you everyone.