About
Rigorous science,production-ready systems.
The hardest part of most AI/ML projects isn't the model architecture. It's learning the domain, deciding what you're actually trying to measure, and developing an evaluation strategy that aligns with your organization's objectives.
AI/ML methods are evolving rapidly. But the gap between technical capability and rigorous application remains wide. Organizations often deploy models that optimize the wrong objectives or evaluate systems using metrics that are misaligned with their goals. A more sophisticated model won't save a poorly-framed problem or poor conceptualization.
Conducting an AI/ML project is like doing good research. You have to ask the right questions, carefully frame the problem, thoughtfully operationalize key concepts, select appropriate methods for the problem (not trendy ones), and evaluate model performance, from bias to generalizability.
I'm a data scientist and machine learning engineer, and I bring research-level rigor to applied ML. I leverage my experience with causal inference, statistical modeling, and research design to solve complex business problems involving unstructured, domain-specific text.
I've spent a lot of time working with complex, domain-specific text — international treaties, court cases, regulatory documents, multilingual documents. In specialized fields like law and finance, terms carry precise meaning, document structure matters, and a wrong classification can have real consequences. Many organizations try to apply off-the-shelf solutions to these specialized problems and find that the gap between general capability and domain-specific performance is wider than they expected.
I build domain-adapted classifier systems, recommender systems, and agentic RAG systems. I work end-to-end — from problem framing, to measurement strategy, to model development, to deployment, to monitoring — so nothing is lost in translation from problem to production.
If that sounds like your situation, let's talk.
Education
PhD | Political Science
Emory University
Specialization in quantitative methods. Research focused on computational analysis of text, applications of machine learning to legal text, and measurement in large-scale observational data.
BBA | Business Honors
McCombs School of Business, University of Texas at Austin
Canfield Business Honors Program — an accelerated, MBA-style undergraduate program at a top-10 business school. Grounding in strategy, finance, and organizational decision-making.
Professional Certificate
Stanford University, DeepLearning.AI
A professional certificate on ML methods, covering supervised learning, unsupervised learning, deep learning, natural language processing, and recommender systems.
Experience
Data Scientist | Researcher
University of Oslo
Data Scientist | Researcher
University of Geneva
Data Scientist | Researcher
Washington University in St. Louis
Data Scientist | Researcher
Emory University
Media
How I work
I structure every engagement clearly: discovery and problem framing, a scoped proposal that explains exactly what I'm building and why, milestone-based execution with regular check-ins, and a documented handoff that leaves your team able to operate independently.
Problem framing.
I start every engagement with a conversation about how to frame the problem. What business decision does this system need to support? Or what business problem does it need to solve? What does success look like? What are the costs of errors? These questions determine the right method — not the other way around.
Measurement validity.
I emphasize measurement strategy and good conceptualization. A model trained on data with poorly-conceptualized labels won't perform well in production. Do the labels we're using accurately capture the business or domain concepts we care about?
Production-ready deliverables.
I scope every engagement to deliver something operational and production-ready: a robust data pipeline, a documented ML model, a production-ready API and deployment strategy, and a monitoring system for calibrating model performance.
No black boxes.
I explain what I'm building, how it works, why I'm doing it that way, and what the limitations are — in normal, non-technical language. I document decisions, explain tradeoffs, and make sure your team can operate and maintain what I deliver. The goal is capability transfer, not dependency.