Financial engineering is what happens when you point the tools of mathematics, computer science, and engineering at money. It is the discipline behind pricing a derivative, measuring the risk of a portfolio, and deciding what a future cash flow is worth today. For engineers, it is a surprisingly familiar world — models, assumptions, edge cases, and a relentless question of what a thing is really worth. This series builds it from first principles.
Financial engineering applies math, statistics, and computation to money — and under the jargon it rests on three ideas an engineer will recognize: the time value of money, the trade-off between risk and return, and no-arbitrage. This series builds quant finance from those foundations. (Educational, not financial advice.)
Financial engineering has always been computational, but a new layer is reshaping it: artificial intelligence applied not just to predict prices but to read documents, structure judgment, monitor risk, and preserve institutional decision-making. AI financial engineering is the discipline of building these systems end to end — and doing it in an industry where being wrong costs real money and being unexplainable is often illegal. This series builds that discipline from first principles to production.
Financial engineering has always been computational; AI now extends it into reading documents, structuring judgment, and monitoring risk. What AI financial engineering is — the synthesis of model-driven quant and data-driven AI — and why finance (real money, mandatory explainability, auditability, adversarial data, human judgment) makes it uniquely hard. (Educational, not financial advice.)
"Ontology" sounds like philosophy, and historically it was — the study of what exists. In computing it means something more concrete and more useful: a formal, explicit description of the things in a domain and how they relate, written so a machine can reason about it. As AI systems increasingly need to ground their answers in structured truth rather than guess from text, ontologies and the knowledge graphs built on them have become quietly essential. This series builds both from first principles.
'Ontology' sounds like philosophy; in computing it's a formal, machine-readable description of a domain's things and relationships. The ladder from schema to taxonomy to ontology, the building blocks (classes, individuals, properties, axioms), and why ontologies give LLMs the verifiable source of truth they lack.
Every coding agent, under the hood, runs the same loop: understand the situation, take an action, observe what happened, and decide the next action — repeating until the task is done. This read-edit-run-observe loop is the engine of a coding agent, and it works for code precisely because each action produces concrete, verifiable feedback. This post builds that loop and shows why closing it against real results is what separates an agent from a code generator.
Every coding agent runs the same loop: observe the state, decide an action, act through a tool, observe the result, repeat. Closing the loop against code's concrete feedback (errors as rich signals) is what makes it an agent that converges to working code, not a one-shot generator — and the loop is only as reliable as the feedback driving it.
Having understood the screen, a computer-use agent must act on it — move the cursor, click the right spot, type the right text — and then look again to see what happened. This perceive-act loop, running over a graphical interface with imprecise actions and visual feedback, is the engine of a computer-use agent, and it's both simple in shape and hard in execution. This post covers how agents act on a GUI and the loop that ties perception and action together.
An agent acts by simulating human input — mouse, keyboard, navigation — translating intent into precise physical actions on a visual surface where a click can mechanically succeed yet do the wrong thing. The perceive-act loop (visual on both ends, slow, per-step-fallible), and why closing it (verify, adapt) beats brittle scripted RPA.
The elegant idea of value functions becomes a practical algorithm through one trick: learn by comparing your prediction to a slightly-better prediction, and nudge toward the difference. Temporal-difference learning and its famous instance, Q-learning, are how an agent learns the value of its actions purely from experience — no model of the world required. This is the algorithm that first made reinforcement learning work, and its core idea quietly underlies much of the field.
Learn a guess from a better guess: temporal-difference learning and Q-learning nudge value estimates toward reward + γ × value-of-next, model-free, bootstrapping from every step. Off-policy learning, ε-greedy exploration, and why the Q-table can't scale — motivating deep RL.
Behind every reinforcement learning algorithm is one formal structure: the Markov decision process. It's the precise way of writing down "an agent making a sequence of decisions under uncertainty," and once a problem is framed as an MDP, the whole toolkit of RL applies to it. This post builds the MDP from its parts and explains the one assumption — the Markov property — that makes the entire theory work.
Behind every RL algorithm is one structure: the Markov decision process (states, actions, transitions, reward, discount). The Markov property that makes it tractable, why state design matters, and reward design as RL's subtle, decisive, error-prone part (reward hacking) — the problem RLHF later solves.
Supervised learning needs a teacher who knows every right answer; reinforcement learning needs only a goal and the freedom to try. It's how a system learns to play a game, control a robot, or — increasingly — align a language model, not by being shown correct outputs but by acting, seeing what happens, and learning from the consequences. This series builds RL from first principles, and it starts with why "learning from reward" is a fundamentally different and more general kind of learning.
Supervised learning needs a teacher who knows every answer; RL needs only a goal and the freedom to try. Learning from consequences via the agent-environment-reward loop, the policy, delayed reward and credit assignment, and the exploration-exploitation dilemma that makes RL its own discipline.
Knowing the algorithms is maybe 20% of doing machine learning. The other 80% is the workflow around them: framing the problem, preparing the data, iterating honestly, and getting a model into production where it keeps working. This closing post assembles the series into the end-to-end process real ML follows — and names the places where projects actually fail, which are almost never the algorithm.
Algorithms are ~20% of ML; the other 80% is the workflow — framing the problem, preparing data, iterating honestly, and keeping a model working in production where it decays (concept drift). Why classical ML isn't obsolete, and why these foundations are universal to deep learning and LLMs.
Most data in the world is unlabeled, and labeling it is expensive — so some of the most useful machine learning finds structure in data with no answer key at all. Unsupervised learning groups similar things, compresses high-dimensional data, and flags the anomalies, all without being told what "right" looks like. This post covers the main unsupervised techniques and, just as importantly, how you tell whether they worked when there's no label to check against.
Most data is unlabeled, and some of the most useful ML finds structure without an answer key. Clustering, dimensionality reduction (the root of embeddings and semantic search), anomaly detection, and the hard problem of evaluating when there's no label to check against.
The most dangerous number in machine learning is accuracy, because it's the one everyone reaches for and the one that most often misleads. A fraud model that's 99.9% accurate by never catching any fraud is useless and common. Choosing the right evaluation metric — and understanding what each one hides — is the difference between a model that looks good and a model that works. This post is about measuring models honestly.
The most dangerous number in ML is accuracy — a 99.9%-accurate fraud model that catches nothing is common. The confusion matrix, precision vs recall (a business decision), F1/ROC, regression metrics, segment-level evaluation (how bias is caught), and why every offline metric is a proxy (Goodhart's law).
If there is one idea that separates people who understand machine learning from people who can run a library, it is this: the goal is never to do well on the data you have, but on the data you don't. A model that nails its training data and fails in production hasn't learned — it has memorized. Overfitting is the central failure mode of ML, and the techniques to fight it (the train/test split, regularization, the bias-variance trade-off) are the discipline's core craft.
The goal is never to do well on the data you have, but on the data you don't. Overfitting vs underfitting, the bias-variance trade-off, the train/test split (why training accuracy is meaningless and leakage/contamination fools you), and regularization as Occam's razor for models.
If you have a spreadsheet and a prediction to make, the state of the art is probably not a neural network — it's a gradient-boosted ensemble of decision trees. Decision trees are intuitive, handle messy real-world data gracefully, and when combined into ensembles become the most consistently winning approach to tabular machine learning. This post builds from a single tree to the ensembles that quietly power a huge fraction of production ML.
If you have a spreadsheet and a prediction to make, the state of the art is probably not a neural network — it's a gradient-boosted ensemble of trees. From a single decision tree to random forests and boosting, and the useful heuristic: tabular → trees, unstructured → deep learning.
Before neural networks, the two models that still quietly run more of the world's predictions than anything else are linear and logistic regression. They are simple enough to understand completely, fast enough to train on anything, and interpretable enough to explain to a regulator — and understanding them teaches the mechanics (fitting, loss, gradient descent) that every more complex model shares. This post builds both from scratch and shows why "just use a linear model" is often the right answer.
Linear and logistic regression still run more of the world's predictions than anything else — and they teach the universal loop (model, loss, gradient descent) that scales all the way to training an LLM. Fitting a line, the learning rate, and the sigmoid that becomes the softmax.
The glamorous part of machine learning is the model; the decisive part is the data and the features. A mediocre model on great features beats a great model on poor ones, almost every time — which is why experienced practitioners spend most of their effort here and almost none picking algorithms. This post is about the unglamorous, high-leverage work of turning raw data into the features a model can actually learn from.
A mediocre model on great features beats a great model on poor ones. The data properties that govern what's possible (quantity, quality, representativeness — the root of bias) and feature engineering as the model's vocabulary — the highest-leverage, least-glamorous work in ML.
Most of this blog's AI content sits on top of machine learning without ever defining it. This series fixes that from the ground up: before transformers and LLMs, before fine-tuning and RAG, there is the plain idea of a program that improves at a task by learning patterns from data instead of being explicitly told the rules. Understanding that idea — and its three core flavors — is the foundation everything else in modern AI is built on.
Before transformers and LLMs there is the plain idea of a program that learns patterns from data instead of being told the rules. What machine learning is, the vocabulary (features, model, training, generalization), and the three paradigms — supervised, unsupervised, reinforcement — the whole AI stack is built on.
Every time you type into a search box and get useful results in milliseconds from billions of documents, a remarkable amount of engineering is hiding behind the cursor. Information retrieval is the science of finding relevant information in a large collection, and it's one of the oldest, most practical, and — in the age of RAG — most suddenly-relevant-again fields in computing. This series builds search from first principles, and it starts with why "just find the matching documents" is far harder than it sounds.
Finding relevant information in a huge collection in milliseconds is far harder than 'just find the matching documents'. The two problems hiding in search (matching and ranking), why scanning fails, and the offline-index/online-retrieve pipeline that makes search fast — and that RAG reuses directly.
Strip away the variations and every graph neural network does the same fundamental thing: each node repeatedly gathers information from its neighbors and updates itself. This is message passing, and it's the single idea you need to understand GNNs — GCN, GraphSAGE, GAT, and the rest are all just different choices for how a node listens to its neighbors. This post builds message passing from scratch and shows why it elegantly satisfies everything a graph architecture must.
Strip away the variations and every GNN does the same thing: each node repeatedly aggregates information from its neighbors and updates itself. Message passing, why stacking layers widens a node's view to its k-hop neighborhood (convolution generalized to graphs), and the failure modes (over-smoothing, over-squashing) that shape real GNNs.
Neural networks conquered images, text, and audio — but a huge amount of the world's most valuable data isn't any of those. It's graphs: social networks, molecules, knowledge graphs, payment networks, supply chains. Standard deep learning can't handle them, because graphs break the assumptions CNNs and transformers are built on. Graph neural networks are the architecture built for data whose meaning lives in its connections, and this series builds them from first principles.
Neural networks conquered images, text, and audio — but much of the world's most valuable data is graphs: social networks, molecules, knowledge graphs, payment networks. Why standard deep learning can't handle them, the two properties a graph architecture must have, and what a GNN learns instead.
Forecasting the future from the past is one of the oldest and most valuable things data can do — predict demand, traffic, revenue, load, prices. But time-series data breaks the assumptions most machine learning is built on, and treating it like ordinary data is the fastest way to build a forecaster that looks great in testing and fails in production. This series builds forecasting from first principles, starting with why time is different.
Forecasting the future from the past is one of data's oldest, most valuable jobs — but time-series data breaks ML's i.i.d. assumption (order matters, observations are dependent, the data is non-stationary). Why that dependence makes forecasting both possible and hard, and the vocabulary (trend, seasonality, noise, stationarity, horizon).
Humans see so effortlessly that it's easy to forget vision is one of the hardest problems in computing. To a computer an image is just a grid of numbers, and turning those numbers into "that's a cat" requires bridging an enormous gap between raw pixels and meaning. This series builds computer vision from first principles — from pixels to classical methods to the deep learning that finally cracked it — and it starts with why the problem is so deceptively hard.
To a computer an image is just a grid of numbers, and turning those into 'that's a cat' means bridging the semantic gap — made brutal by viewpoint, lighting, scale, occlusion, and intra-class variation. Why vision defeats hand-written rules and is fundamentally a learning problem.
Stream processing has a small, elegant core model: everything is an event, events form streams, and time is a first-class concern. Getting these three ideas precise — especially the subtle and crucial distinction between when an event happened and when you process it — is what makes the rest of stream processing (windowing, state, correctness) comprehensible. This post builds the core vocabulary that everything else depends on.
The core model: events, streams, and time as first-class. The crucial, most-misunderstood distinction between event time (when it happened) and processing time (when you handle it), why correct answers depend on event time, and why that makes time the central problem of streaming.
Most software processes data at rest: you store it, then query it. Stream processing flips that — it computes on data in motion, as each event arrives, continuously and forever. This shift from "store then process" to "process as it flows" underpins fraud detection, real-time analytics, monitoring, and the event-driven systems that react to the world as it happens. This series builds stream processing from first principles, starting with why computing on data in motion is a fundamentally different model.
Most software processes data at rest; stream processing computes on data in motion, as each event arrives, continuously and forever. Batch vs stream, why unboundedness makes streaming hard, and when latency justifies its complexity over simpler batch.