on simulation and env. i always view the starting world as the end state of a simulated history, vs just a collection of db records or files which you’d have to check for consistency after the fact. say, we’re training a customer service agent, when we drop it in a training env to solve its first ticket, there should already be history. maybe there was a software outage days ago, which resulted in tickets piled up. some got refunded over time, and some is still waiting. if that initial state comes from simulation (meaning the history actually ran), things like timestamps, causes, or even complex scenarios should all line up on their own. you no longer have to go back and check if the refund happened after the outage. now our data/env quality question gets simplified to “whether the world generating them is right”, and the good news is… we don’t have to “train a simulation model”. rather there’s ancient old math designs exactly solve for this new problem! for example, to simulate state changes like opened to escalated to closed for a ticket properly, we can take “state transitions” to model the ticket with explicit transition probabilities. so it won’t look fake or inconsistent. another sweet spot is to inject that outage in a history timeline. the old school “discrete event simulation” was made for it - it helps schedule the outage and all of its downstream effects on their own clocks, with realistic uncertainty baked in. a wrong world gets great consequences - reward hacking on deemed fake env, unsafe when deployed to real world when trained on wrong setup, etc etc, but i believe these explicit stochastic math first sims could already go a long way. so much more to reread and model. fun times.