Arnav Podichetty

the pipeline, step by step

1. 01Profile every column and its null rate, write a keep/drop/standardize spec for each one, then apply the specs. The cleaning rules live in their own files instead of being buried in the code.
2. 02A restore tool that rolls a merged table back to its original columns and removes duplicate keys, for when a merge goes wrong.
3. 03A merge step that left-joins the cleaned tables into patient-level datasets. It skips columns that are already there, so running it twice is safe.
4. 04Cohort exclusions, attaching the outcomes, and a stratified train/test split.
5. 05EDA on missing values, class balance, and where the target column came from, which I used to decide which features to keep.
6. 06Preprocessing and training: one-hot encoding, KNN imputation, scaling, an XGBoost baseline with balanced sample weights, Optuna tuning, SHAP, and saving it all as one bundle.
7. 07Inference: reload the bundle, check it gets the same scores on the test set, sweep decision thresholds, and predict for one patient or a whole batch.
8. 08Comparing three models with the same tuning budget and the same metrics, all logged to MLflow, and saving the best one.

data foundation

• Profiled, wrote specs for, and cleaned 24 clinical trial sources. That came out to 72 CSV files: 1,868 profiling records, 1,868 cleaning rules, and 38,512 standardized rows across 24 cleaned tables (1,167 columns total).
• Turned all the different yes/no formats into 1s and 0s and recorded where each import came from.
• Read multi-sheet Excel workbooks and CSVs with pandas and saved every in-between step (profiles, specs, cleaned tables) as a plain CSV, so any step can be opened up and checked.
• Ended up with a 641×657 train set and a 275×657 test set after exclusions.

keeping it from breaking

• Some sources had more than one row per patient, so I deduplicated them before every join. Otherwise one patient could turn into several and quietly inflate the cohort.
• Made merges skip columns that already exist, which stopped reruns from bloating the table.
• Offset the second cohort’s patient IDs with a fixed key so they couldn’t collide with the first cohort’s.
• Removed the pipeline’s own tracking columns before the final output so they didn’t end up as features.
• Checked every merged output for its shape, duplicate keys, and overlap counts.

modeling & evaluation

• Started with an XGBoost baseline using balanced sample weights and looked at the confusion matrix, ROC AUC, and precision, recall, and F1 for each class.
• Tuned each model with Optuna for 50 trials inside a stratified 3-fold CV loop that recalculates class weights for every fold. Tuning on just one split would’ve made the scores look better than they really are.
• Compared XGBoost, LightGBM, and logistic regression using the same preprocessing, splits, metrics, and tuning budget. They all landed around 0.72–0.76 ROC AUC.
• Ran SHAP on the best model. LightGBM gives back its SHAP values in a different shape than the other two, so that needed its own handling.
• Plotted precision, recall, and F1 across decision thresholds, since picking that cutoff is the actual call a clinician would have to make.
• Logged every run, parameter, and metric to MLflow with a SQLite backend.
• Saved the preprocessor, imputer, scaler, model, and metadata together as joblib bundles, so predictions don’t depend on whatever state a notebook was in.

leakage & governance

• Sorted features into before and after the procedure, then dropped IDs, anything recorded after the outcome, free text, and columns that barely change. Adverse-event fields line up really well with the outcome, but only because they happen after it.
• Traced the target column back through every merge to make sure it still meant what it was supposed to.
• About 40% of the model inputs were missing, so I measured exactly where and wrote down a plan for imputing it.

the ramp

The co-op followed a mentorship plan: two weeks of learning, four weeks working on the pipeline with guidance, and three weeks contributing code. Every week ended with something built.

• Wk 1–2Got comfortable with NumPy and pandas, then trained logistic regression, random forest, XGBoost, and CatBoost from scratch on a public cardiac dataset. We judged them on AUROC, Brier score, and calibration, since with only a 6% event rate, accuracy doesn’t really tell you anything.
• Wk 3–4Learned about aortic stenosis and the TAVI procedure, got a read-only tour of the codebase, and wrote my first real script: a command-line data-quality checker that outputs a JSON report on missing values, class balance, and constant columns.
• Wk 5–6Trained XGBoost on real patient outcomes with Optuna tuning and careful handling of missing labels, then ran SHAP on the test set and wrote a review checking whether the top features made clinical sense or looked like leakage.
• Wk 7Built a three-layer Keras MLP (batch norm, dropout, AdamW) and compared it against the XGBoost baseline to see if deep learning actually helps on tabular clinical data.
• Wk 8Walked through the team’s multi-task model from start to finish: a BiLSTM with multi-head attention over the time-series data, combined with a static encoder and a few prediction heads for different tasks. I wrote the explainer doc for it.
• Wk 9Ran the whole pipeline, then added a stacking meta-learner on top of the tree models’ out-of-fold predictions, trying logistic, ridge, and elastic-net combiners against a simple average.

ai-assisted documentation

• I also worked on a second project building GenAI workflows that summarize SOPs, pull out definitions, and write requirements from long internal process documents.
• It cut down on manual review time, and the outputs came out consistent enough that the team could reuse them.

handoff

• Wrote a map of the pipeline and instructions for running it, so the next person can pick it up without figuring everything out again.
• Kept a cleaning tracker with each dataset’s status, priority, and notes on how to merge it.
• Wrote down what was finished and what was still groundwork, so my final presentation didn’t make the models sound further along than they were.

stack

The run, from research to release

• Jun 2–30Research and concept. We looked at similar games, interviewed people, and playtested Spyfall, which pointed us toward a phone-first game with simple rules and roles that help the conversation along.
• Jul 7–8First playable build as impfall, fixed within hours and put up on GitHub Pages the next day. Word Mode, a round timer, and movies as a word category came the same week.
• Jul 9Rewrote the whole thing: pulled out the visual-builder code the prototype started in and moved the game into a hand-written React app.js. About 2,700 lines removed and 994 added, and the game played exactly the same.
• Jul 23–28impfall became Masq. Redid the roles and word lists across the board, then added a real Settings screen, How to Play, Credits, and Jester Mode.
• Aug 2–4Music Genres, crossing words out of a category, Custom Categories, a timer pause, and a shuffle that’s actually even. Tagged 1.0.0 on Aug 4.
• Aug 5–7Progressive jester odds, a jester reveal screen of its own, and pictures on the cards: movie posters, album art, animal and food photos. The Jester also got one last chance to steal the round by guessing the word after getting caught.
• Aug 8–10The lobby now saves across reloads, Jester Hints give a Word Mode jester something to work with, animals stopped repeating, and I went through and commented the whole codebase.
• Aug 11–12Moved to masq.games, made the site show up on search engines, added Duel Mode for two players, and put the changelog in the game under Settings → What’s New.
• Aug 17–22Duel Mode came out from behind an easter egg, the Movies/TV list was rebuilt with 608 titles, the icons were redrawn on one grid, and the fonts were replaced (1.13.0).

The game

• Role Mode gives every performer a role tied to the secret word while the Jester goes in blind. Word Mode gives everyone the same word. Duel Mode gives two players different words from the same category, and they question each other until someone guesses the other’s.
• Categories from Biomes, Cuisines, and Music Genres to Movies/TV and Numbers, plus your own through Custom Categories.
• Options for how many jesters there are (fixed or random, from none to the whole table), progressive selection that makes it less likely the same person is the Jester twice in a row, jesters who know each other, a fake word for the Jester, and a round timer with a sound at the end.
• Options that conflict or don’t apply to the current mode get grayed out but stay where they are, so buttons don’t jump around while you’re tapping.

What playtesting changed

• Roles need to actually give clues. A lot of the early roles were generic and repeated across categories like Historical Eras and Biomes, so a Jester could sound believable without knowing the word. I rewrote the role lists so each one is specific, redid all 168 Biomes roles, and made the Jester’s fake roles real roles from a different word.
• The phone isn’t always in your hand. It’s usually face down or across the table, so the game announces “Time to Vote!”, has an optional chime, and shows the word list on The Trial screen where everyone can see it.
• Making it feel fair. A round with zero Jesters now ends with “Every performer was genuine” instead of acting like someone lost. I swapped a shuffle that favored certain seats for a Fisher–Yates shuffle, and progressive odds move the Jester role around the table without locking anyone out.
• Duel Mode was too hidden. It started as an easter egg, but the people who’d want a two-player game were the least likely to find it, so six days later it got its own tile in the lobby.
• Reading on a small screen. I redrew the lobby icons on one 24×24 grid and switched to fonts that are easier to read at 13px.

Artwork pipeline

• Five Node scripts rebuild the artwork maps: movie and TV posters from TMDB, album art from Deezer, and animal, food, and object photos from Wikipedia and Wikimedia Commons.
• The results get saved into the repo, so a round never has to wait on an API, and card art loads before the reveal so it doesn’t pop in late.
• Each script lists the entries it wasn’t sure about and keeps a list of manual fixes for the ones a normal search gets wrong. That caught fifteen titles showing the wrong movie and six titles spelled differently across catalogs.
• The photo scripts grab the photographer credit for every image and won’t save anything if a photo needs a credit and doesn’t have one. The cuisines script also stops if two roles end up with the same photo, since then two players would see the same card.

Engineering

• It’s plain React 18 loaded from a CDN, with no bundler, package manager, or build step. You just open index.html and it runs.
• The lobby is saved in localStorage: players, mode, categories, jester settings, timer, theme, custom categories, and crossed-out words. Crossed-out words get checked against the catalog on load in case a word was removed. The round itself doesn’t survive a reload on purpose.
• Since React draws the whole game, search engines that don’t run JavaScript were seeing a blank page. I added plain text inside the page that they can read, and it gets replaced as soon as React loads.
• For the font swap I compared x-heights: the new body font at 13px looks about as big as the old one did at 14.7px, and the new UI font was close enough that nothing else had to be resized. The font files went from about 154KB to 129KB.
• There’s a CHANGELOG.md covering all 64 releases that you can read inside the game.

How I used AI

• I used Claude Design for the first prototype and Claude Code for a lot of the implementation. I made the product and visual decisions, came up with the features, playtested every change, and kept iterating on the fixes.
• AI helped draft some of the catalog content, but I checked the genres, word lists, biome roles, and photographer credits myself before shipping. One bad role can ruin a round for everyone.

Credits

Created and coded by me. Richard Chen co-created the game and came up with the original concept, and Esha Bansiya also contributed. Inspired by Spyfall and Imposter.

Where it’s at & what’s next

• Masq launched at masq.games on August 11, 2026 and has passed 100 active users in Google Analytics, when my goal for the summer was 10.
• As of 1.13.0: three modes, ten built-in categories plus custom lists, and 929 credited photos.
• Next on the list from playtesting: a tutorial, example questions for every category, making Locations and Cuisines easier to ask about, and a bigger reveal for the Jester and the word.

Stack

Why I made it

• I was already using Simplify and Jobright, but they were missing features I wanted and left the slowest parts of a form, like Workday’s multi-step flows and searchable dropdowns, for me to do by hand. So I built my own that does exactly what I need.
• Applying to a lot of internships means typing the same name, school, work authorization and EEO answers over and over, and checking every field afterward anyway.

What it is

• A Fill page button, on the page or in the toolbar popup, that fills the whole form from top to bottom, including multi-page Workday-style flows.
• Resume and skill rules pick the right resume and skill set for each job from keywords in the title and description.
• Filled fields get a green outline, and fields that need a second look get an orange one and show up in the popup with the reason.
• Saved answers: answer a custom question once, save it, and similar questions on later forms get filled for you.
• Dedicated support for Greenhouse, Lever, Ashby, SmartRecruiters, Workday, iCIMS and SAP SuccessFactors, tested support for Workable, Rippling, Dover, Jobvite and more, and a generic mode that matches fields by their labels on any other site.
• A movable on-page panel that also shows on the job posting itself, with the role, company, location, pay and posting date read from the page.
• Resume tailoring (optional): a Tailor resume button rewrites the picked resume for the posting, keeps it to one page in Jake’s resume template, and shows what changed. It can swap in a role or project from my profile that fits the job better.
• Fill my profile (optional): Claude reads my resume, a profile page like Simplify or LinkedIn, or pasted text and fills in my profile. Every value has to appear in the source, and I review each change before it’s saved, with anything that would overwrite what I wrote left unticked.
• Light and dark modes on the options page.

How it was made

• Written in TypeScript and built with WXT, a framework for Manifest V3 browser extensions. A content script runs the fill, and an options page holds the profile, resumes and settings.
• Each big applicant tracking system gets its own adapter that knows that site’s markup, and they all share one engine that scans the page, reads each field’s label, picks an answer and fills the control.
• The engine handles text boxes, dropdowns, searchable dropdowns, radios, checkboxes, rich-text editors and date pickers, including ones inside shadow DOM, and skips hidden bot-trap fields.
• The matching code handles the different ways sites spell schools, degrees, majors, states, dates, GPA ranges and yes/no wordings.
• A developer “Capture page” button saves a snapshot of a real form so a broken site can be reproduced and fixed. Unit tests run in Vitest with happy-dom, and live tests drive Chrome with Puppeteer.
• Tailoring runs through a small local helper that Chrome talks to over native messaging. The helper hands the resume, the job page’s text and my profile to Claude Code, signed in with my own Claude account, so there’s no API key. The permission is only requested when tailoring is turned on.
• Every tailored bullet has to trace back to my resume or profile. If a rewrite adds a number or a tool that isn’t there, the original bullet is kept instead. Fill my profile works the same way: a date has to match its own entry, a role only counts as current if it says Present, and anything that fails a check is listed under “Left out”.
• Apart from the Claude features, it makes no network requests of its own. The profile and resumes are stored locally, and a JSON backup moves them to another browser.

Stack

Why I made it

• I first made it to predict the setlists for two concerts I was going to, beabadoobee and Gorillaz.
• Setlist predictors already exist, but they mostly give one “average setlist” for a whole tour. I wanted one that predicts a specific show, gives a probability for every song, and checks itself against what the band actually played.

What it is

• The prediction is written on a setlist sheet taped to the stage floor. Songs they almost always play are written firmly, and gambles are light and scrawled.
• Songs that take turns in the same spot are written beside each other (“or Stockholm Syndrome”), and it flags the chance they play at least one rarely played deep cut.
• You can fit the prediction to a show by setting the date, city, country, tour and whether it’s a festival set, or leave it blank for a typical show.
• Save a prediction before the show, and once the real setlist is posted it’s graded and compared with a plain count of what the band has been playing.

How it was made

• A FastAPI backend downloads and caches setlists in SQLite, and a plain HTML, CSS and JavaScript front end is served from it.
• Each row is one song at one show, labelled played or not, with 22 features like recent play rates, tour play rate, shows since it was last played, multi-night runs, festival vs headline rates, country, and how much the band varies its sets. Every feature only uses shows before that one, so nothing from the future leaks in.
• I compared model types over five rounds of testing, then settled on one CatBoost model tuned with Optuna and trained on 100 artists across many genres (33,860 setlists) with every artist weighted equally. It beat the “tour play count” baseline for all 81 artists it hadn’t been tuned on, by 34% on average.
• The trained model ships with the repo, so predictions are good from the first search. Visitors can use their own free setlist.fm API key, which stays in their browser, and each browser’s searches and saved predictions stay private.

Stack

Why I made it

• Most of what I love comes in clusters across mediums: a movie leads me to an album, which leads me to a book. Recommendation sites mostly stay inside one medium and match on genre, so I wanted one that could go across all of them.

What it is

• You enter a title and its medium, and it returns movies, TV shows, books, anime, games and music that share its feel.
• Every pick comes with a short “why this matches” blurb.
• The backend is feature-complete. A minimal test page works now, and a fuller React interface is the main thing left.

How it was made

• A Python backend on FastAPI pulls metadata from five APIs through one shared ingest pipeline: TMDB for movies and TV, AniList for anime and manga, Hardcover for books, RAWG for games and Last.fm for albums.
• For every item, an LLM writes a standardized “taste profile” as JSON. The profile is embedded locally with sentence-transformers (bge-small-en-v1.5) and stored in PostgreSQL with pgvector.
• To recommend, a pgvector cosine search finds about 30 nearest neighbors in any medium, and then an LLM re-ranks them and writes the blurbs. If the LLM call fails, it falls back to plain similarity order.
• The LLM step works with any OpenAI-compatible endpoint. In development I ran Qwen3.5-4B locally through llama.cpp on my RTX 3080, and turning off the model’s thinking phase cut each item from about 65 seconds to about 9. For a hosted version, the same settings point to Groq instead.

Stack

Why I made it

• I love learning what songs actually mean and how they were made, but that meant pausing to look things up on Genius in another tab. I wanted it right inside the app I’m already listening in.

What it is

• The “About” description from Genius for the current track, plus the album, release date, producers, writers and streaming links.
• Live lyric annotations: as Spotify’s synced lyrics play, the panel shows the Genius annotation for the current line.
• A collapsible section for samples, covers, remixes and interpolations.
• It’s available on the Spicetify Marketplace.

How it was made

• It’s a single JavaScript file running inside Spicetify, a customizable Spotify client. It uses Spicetify’s player API to know what’s playing and to listen for song changes.
• For each track it searches the Genius API, then pulls the song’s details and its referents (Genius’s annotations).
• Spotify’s line-synced lyrics come from Spotify’s internal lyrics endpoint. Genius fragments and Spotify’s lyric lines rarely line up exactly, so each line is matched to an annotation by word overlap instead of exact text.
• Song data is cached locally and fetched in the background on every song change, so the panel opens instantly. You bring your own free Genius token, which is stored locally, so no secrets are in the code.

Stack

Why I made it

• I’d often have slideshows with QR codes open on my Mac and would have to pull out my phone just to open the link on the computer I was already using.

What it is

• Three ways in: drag a screenshot over part of the screen, open an image file, or paste one from the clipboard.
• Click the decoded link to copy it, with a light and dark mode in Settings.
• It lives in the menu bar and comes as a DMG installer so it’s easy to install.

How it was made

• Written in Swift. The window is built with SwiftUI and lives in an AppKit menu bar item and popover.
• Screenshots use macOS’s own screencapture tool for the region selection, which is why the app asks for Screen Recording permission.
• QR codes are read with Apple’s Vision framework (VNDetectBarcodesRequest), which returns clear errors when there’s no code or the image can’t be read.

Stack