Aashni Joshi

Wanted to see what the engines underneath actually look like without any of the platform automation I'd been working on top of, so I stood both of them up myself from vanilla open-source packages and went down the question of when you'd reach for one over the other. Built Spark and Ray on a self-managed Kubernetes cluster from scratch, including the S3, networking, auth, container, and observability setup around them. From there I wrote equivalent ML pipelines in Spark MLlib and Ray + XGBoost and benchmarked them across 858M rows, comparing runtime, memory, and model performance. Most of the project turned into understanding what each framework quietly does for you: Spark was much more forgiving once a workload outgrew memory, while scaling Ray meant going deeper into distributed XGBoost, streaming data, and managing memory myself.

Got curious about what actually sits under the hood of Medicare plan recommenders after reading the recent CMS RFI on AI in plan selection. Pulled three months of CPSC files (contracts and enrollment, around 10 million rows total) and dug into them for staleness, masking, churn, and coverage gaps. 94.6% of enrollment rows turn out to be masked for privacy, thousands of rows have orphaned geography, and month-over-month contract churn is higher than you'd want for a live recommendation engine. Packaged the analysis as a notebook and a dashboard.

Stumbled onto the Stanford HAI group working on KAI, an AI tool that helps students with intellectual and developmental disabilities work through reading comprehension. Went deep into the Lemons group's papers on presumed competence and curriculum-based measurement, then tried to answer a question the research itself raises: how do you scale rubric-based scoring as the tool moves from one RCT to three concurrent pilots? Built a four-dimension rubric grounded in their published work, wrote an evaluator that refuses to penalize non-standard grammar (which is the whole philosophical point), and ran it against six worked examples including a critical test case on non-standard communication.

Watched too many technical founders duct-tape five tools together just to enrich a company, score it against their ICP, find a champion, and draft outbound. Wanted to see how much of that loop could collapse into a single API call. Built Orbit: paste a company name, and in under 10 seconds Claude enriches the account, scores it against a target ICP, surfaces buy signals, infers a champion persona, and drafts a personalized three-touch outbound sequence. One structured call, typed JSON, zero chaining. The data layer is stubbed behind Claude inference on purpose, so swapping in real B2B data APIs later is a clean replacement.

Built this at CalHacks because Kessler syndrome is the most visceral version of a problem I actually want to work on. The idea is simple and terrifying: one collision in LEO spawns debris, that debris causes more collisions, and the cascade runs until the orbit is unusable for generations. Wanted to see that threshold firsthand. Built an n-body orbital dynamics simulator using RK4 numerical integration and Monte Carlo methods, validated trajectories against NASA/JPL ephemeris data at around 90% accuracy. Watching the cascade run in real time changes how you think about who gets to put stuff in orbit.