Applied AI & Data Science · Ph.D. Economics

Hi, I'm Preston Monk.

I'm an economist who builds AI systems for businesses. I want to understand the whole thing: where the data comes from, what it means, how a model uses it, and whether the answer is reliable enough for someone to act on. That takes me across data engineering, data science, and AI engineering. I don't really see three separate disciplines. I see one system.

What I'm building How I got here

01 Data engineering
02 Data science
03 AI engineering

Philosophy.

What a business knows is rarely in one place. Some of it sits in a transactional database. Some is in manufacturer documentation nobody has opened in years. Some is in a spreadsheet one person maintains. Some exists only as a rule an experienced employee applies without thinking about it. All of it is evidence, and none of it was organized for a machine to reason over.

This is where I have seen AI systems fail. By an AI system I mean an application built on a foundation model — Claude or GPT — where the model is a component we call, not something we train. We supply the question and all of the context it answers from. Everything that determines whether the answer is right happens before the model is called. Hand it a partial, inconsistent picture and it will still answer, fluently, with no way to check it. The fix is not a better prompt. It is representing what a business knows in a form its people can query.

Building that representation is most of the work, and it doesn't sit inside a single discipline. Whether an answer can be trusted depends on how the data was assembled, what the modeling can support, and how the system retrieves and checks its evidence. In most organizations those are three separate jobs, often three separate teams: data engineering, data science, and AI engineering. But the decisions constrain each other. Dividing them is how systems end up fluent and unreliable.

So I work across all three. My training is in economics — a discipline about decisions under uncertainty: what causes what, what a measurement is really capturing, how much weight a result can bear. A language model producing the answer makes those questions harder to ask and easier to skip.

My goal is to understand this entire stack. Not every corner of software — this one: how a business turns what it knows into systems that can reason over it, and whether the answers are good enough to act on.

Case study

What I'm building.

Enterprise product intelligence system

Simplify

Context

A national imaging and printing distributor with thousands of SKUs and hundreds of thousands of transaction records. Sales representatives and customers need answers to distinct classes of question: which consumables and parts are compatible with a given machine, what supersedes a discontinued item, and what an account is due to reorder. Each requires different evidence. A single undifferentiated retrieval strategy returns answers that are plausible but unreliable. The same data also has to drive action: which accounts to contact, when, and what to put in front of them.

Compatibility graph

The system is built on a graph representation of product relationships covering compatibility, supersession, and complementarity across the catalog. It is constructed by integrating structured product and transaction data with unstructured technical documentation, so that relationships reflect documented equipment support rather than statistical co-occurrence in sales history.

Intent alignment

Each natural-language request is resolved to a specific intent before retrieval begins: compatibility, replacement, replenishment, cross-sell, or technical lookup. The intent determines the retrieval path. Graph traversal serves compatibility and replacement, SQL serves transactional and inventory questions, and document retrieval serves specifications. Deterministic business rules bound what the system is permitted to assert.

Grounding

Generation occurs last, over evidence that has already been retrieved and validated. Responses carry the records and documentation supporting them, so any answer can be traced to its source.

Recommendation

Retrieval answers the question in front of a representative. Prediction determines which conversation is worth having at all. A recommendation engine built on five years of transaction history models purchasing behavior directly — which accounts are due to reorder, which are drifting toward attrition, which capital equipment is approaching replacement — and ranks what each account should be offered next. This is the half of the platform that generates sales rather than information, and the two halves reinforce each other: a recommendation opens the conversation, and the agent supplies the evidence to support it.

Evaluation

Each intent is evaluated against its own criteria. Compatibility accuracy, replacement validity, and recommendation relevance are distinct measures; a single aggregate score would obscure failure in any one of them.

Predictive modeling · Knowledge graphs · Hybrid retrieval · Intent routing · Deterministic rules · LLM evaluation

Toolkit

What I work with.

Applied AI & retrieval: Large language models, retrieval-augmented generation, hybrid retrieval architectures, semantic search, embeddings, knowledge graphs, graph traversal, SQL retrieval, document retrieval, prompt and context engineering, tool calling, AI agents, LLM evaluation
Data science & machine learning: Statistical modeling, predictive modeling, recommendation systems, forecasting, causal inference, feature engineering, model evaluation, A/B testing, anomaly detection, customer analytics, decision support systems
Languages: Python, SQL, TypeScript, R, Git
Data engineering & platforms: PostgreSQL, vector databases, PySpark, Azure Fabric, AWS, Docker, ETL pipelines

Writing

Thinking out loud.

Notes on working across disciplines that used to require separate careers, and on the gap between a system that answers and a system you can trust. First pieces landing soon.

01 Why AI makes the polymath viable again Draft
02 Why retrieval usually beats a bigger model Draft
03 Evaluating AI when there is no ground truth Draft

About

How I got here.

I completed my Ph.D. in Economics at Florida State in 2024, based at the DeVoe L. Moore Center. My dissertation linked millions of property transactions to demographic, economic, environmental, and public administrative records, building spatial models of how properties, neighborhoods, schools, crime, and infrastructure interact. I used difference-in-differences, nearest-neighbor matching, and spatial econometrics to identify how neighborhood shocks move property values and push households to relocate.

Both halves of that were demanding. Assembling records that were never designed to be joined took years, and every construction decision had to hold up under a committee. The modeling is what made it mean anything: an estimate is only as credible as the identification strategy behind it, and building that strategy is the work. The data and the model are not separable — a careless join produces a confident, wrong result.

That is the training I brought into AI engineering. Economists are taught to worry about identification — whether the thing you measured is really the thing you meant to measure — and to treat a claim nobody can verify as no claim at all. Those instincts matter more, not less, once a language model is producing fluent answers at speed. It is why I build systems that carry their evidence: where an answer came from, what supports it, and how much weight it can hold.

Preston is based in Miami, where he lives the American Dream with his wife Malaya and son Rainer.

Ph.D. Economics — 2024: Florida State University
M.S. Economics — 2019: Florida State University
B.S.B.A. Economics — 2018: University of South Alabama