Coder Legion - Recent posts tagged prophet

Thomas Bayes: The Reverend Who Taught Us to Update Our Beliefs with Data

Sat, 18 Jul 2026 16:44:19 +0000

There is a question every professional who works with data should ask — and almost no one formulates explicitly: How should I change my opinion when I receive new evidence? I don't mean a philosophical answer, but a mathematical one. If I believe there's a 30% probability that an electronic component will become obsolete this year, and I suddenly receive an email from the supplier announcing a production capacity reduction, how much should my estimate increase? To 50%? To 70%? How do I calculate it rigorously?

The answer to that question was formulated by an English Presbyterian reverend sometime before 1761, and it wasn't published until two years after his death. His name was Thomas Bayes, and his posthumous essay is, without exaggeration, one of the most influential documents in the history of science. From the spam filters in your email to the probabilistic forecasting models we used in the S&OP Engineering series with Facebook Prophet, everything passes through Bayes' Theorem.

In the lineage of historical figures who shaped our relationship with data — Florence Nightingale and visualization, John Snow and geolocation, Abraham Wald and survivorship bias, Kantorovich and optimization, Deming and quality, Claude Shannon and information — Bayes occupies a singular place: he taught us to think of uncertainty as something quantifiable and updatable, not as an obstacle but as raw material.

The Reverend and the Posthumous Essay

Thomas Bayes was born in London in 1702 into a family of religious dissenters. His father, Joshua Bayes, was one of the first Presbyterian ministers ordained in England. Thomas followed in his father's footsteps, was ordained a minister, and spent most of his life as a pastor in Tunbridge Wells, a quiet spa town southeast of London.

But Bayes was no ordinary pastor. He was a Fellow of the Royal Society (elected in 1742), which indicates that his mathematical reputation was recognized by the scientific elite of his era. He is known to have published a work defending the logical foundations of Newton's calculus, but during his lifetime he was a discreet figure, almost invisible in the great intellectual debates of the Enlightenment.

History might have completely forgotten Bayes were it not for his friend Richard Price, a distinguished Welsh philosopher and mathematician. After Bayes's death in 1761, Price found among his papers an unfinished manuscript titled "An Essay towards solving a Problem in the Doctrine of Chances". Price immediately recognized its importance, completed it, and presented it to the Royal Society in 1763.

The problem Bayes was trying to solve was deceptively simple in its formulation and profoundly revolutionary in its implications: given a series of observations, what is the probability that the underlying cause is one thing or another? In other words, how do we reverse the direction of probability? Not "given that the coin is fair, what is the probability of getting 7 heads in 10 flips?" but the inverse question: "given that I observed 7 heads in 10 flips, what is the probability that the coin is fair?"

The Theorem: Updating Beliefs with Evidence

Bayes' Theorem can be expressed without intimidating formulas using three intuitive concepts:

Prior (Previous Belief): What you believe before seeing the data. Your initial estimate based on experience, intuition, or historical data. In an S&OP context, the prior might be: "Historically, we sell about 10,000 units of this product in July."
Evidence (Likelihood): The new data you observe and the probability of observing that data under different hypotheses. For example: "This June we've received 40% more advance orders than last year."
Posterior (Updated Belief): Your new estimate after integrating the evidence with your previous belief. The posterior mathematically combines what you knew before with what the new data tells you. It doesn't discard your prior experience nor lets itself be blinded by a single new data point: it weighs both.

The beauty of the Bayesian approach is that it's iterative: today's posterior becomes tomorrow's prior. Each new piece of data refines your estimate. It's not a static photograph; it's a movie that updates frame by frame. It is exactly the same philosophy as W. Edwards Deming's PDCA cycle: plan, do, check, adjust. Repeat.

Modern Connection: Prophet and Demand Forecasting

Where does Bayes appear in modern data engineering? Virtually everywhere, but the most direct connection with this blog is Facebook Prophet, the tool we used in Part 2 of the S&OP series to generate probabilistic demand forecasts.

Prophet is, at its core, a Bayesian additive model. It decomposes a time series into three components — trend, seasonality, and holiday effects — and generates not a point prediction, but a confidence interval. That confidence interval is, literally, a Bayesian posterior distribution: it reflects the model's uncertainty given the historical evidence.

Why does this matter in practice? Because the Safety Stock we calculated in Part 3 of the S&OP series — the amount of buffer inventory to absorb demand variability — is calculated on the upper bound of that confidence interval (typically at 95%). If Prophet used a deterministic model (a single number, no uncertainty), our Safety Stock would be a guess. Thanks to Bayes, it's a decision grounded in the probability distribution of future demand.

The prior in this context is the accumulated experience of the demand planning team and the historical patterns of the time series. The evidence is the new data arriving each week or month. The posterior is the updated forecast that feeds the PuLP linear programming engine to optimize the production plan. Bayes is at the heart of the chain, even though his name is never mentioned in S&OP meetings.

Modern Connection: A/B Testing and Netflix

When Netflix decides which thumbnail to show for a series, it runs a massive A/B test: it shows version A to millions of users and version B to millions of others, then measures which generates more clicks. The classical (frequentist) approach requires waiting until a predetermined sample size is reached to declare a "winner" with statistical significance. If you do peeking — looking at results before time — you invalidate the experiment.

The Bayesian approach to A/B testing eliminates this problem. Instead of a binary hypothesis test (is there a difference or not?), Bayesian A/B testing continuously calculates the probability that version A is better than version B given the data observed so far. You don't need to wait for a fixed sample size because the posterior distribution updates with each new data point.

This has enormous practical implications for startups and teams with limited traffic. If your product doesn't have millions of users, a frequentist test can take weeks or months to be conclusive. A Bayesian test gives you a useful probability estimate much sooner, with the honesty of telling you: "With current data, there's a 78% probability that A is better than B." You decide if that 78% is enough to act on.

Modern Connection: Spam Filters and Classification

One of the first triumphs of machine learning in production at scale was the Bayesian spam filter. The Naive Bayes algorithm (called "naive" because it assumes independence between words, a crude simplification that's surprisingly effective) calculates the probability that an email is spam given the words it contains.

The prior is the base rate of spam (approximately 45% of all global email). The evidence is the email's words: "offer," "free," "urgent" increase the posterior probability of spam; "meeting," "budget," "attached" reduce it. Each word updates the probability, exactly as Bayes prescribed 260 years ago.

The connection with Abraham Wald's survivorship bias is direct: in a spam filter, the data you don't see (legitimate emails erroneously filtered as spam) is as important as what you do see. If your filter has a high false positive rate, you're making the same mistake as the WWII engineers who only analyzed the planes that returned. Bayes and Wald, separated by two centuries, are talking about the same problem: absent information distorts your conclusions.

Modern Connection: Medical Diagnosis and the Perfect Test Paradox

There's a classic example of Bayesian reasoning that should be mandatory in every engineer's training, because it destroys a very widespread intuition. Suppose there's a medical test for a rare disease (prevalence: 1 in 10,000 people). The test has a sensitivity of 99% (correctly detects 99% of the sick) and a specificity of 99% (correctly identifies 99% of the healthy).

Question: if you test positive, what is the probability that you're actually sick?

The intuitive answer most people give — including many physicians — is "99%." The correct Bayesian answer is approximately 1%. How is this possible? Because the prevalence (the prior) is so low that, even with a 99% test, the vast majority of positives are false positives.

This reasoning is directly applicable to AI system engineering. When we configure alerts in the obsolescence radar or in any monitoring system, the false positive rate is the silent enemy. An anomaly detection system with 99% accuracy can generate hundreds of false alerts if the base rate of actual anomalies is very low. Bayes forces us to think about the prior before celebrating the test's accuracy.

The Legacy: Think in Distributions, Not Points

Thomas Bayes's deepest contribution was not a formula; it was a mindset shift. Before Bayes, probability was conceived as a fixed property of objects: a coin has a 50% chance of landing heads, period. After Bayes, probability became a measure of our degree of knowledge about the world, continuously updated with new evidence.

This distinction is the difference between an engineer who says "July demand will be 10,000 units" and one who says "July demand has a 95% probability of falling between 8,500 and 11,500 units, and our production plan must absorb that variability." The first operates with false certainties; the second, with quantified uncertainty. The first is vulnerable to the bullwhip effect that destroys supply chains; the second is armored against it.

In a world where AI models are stochastic by nature — as we painfully documented in the Autopilot post-mortem, where the same pipeline produces different results on each run — thinking Bayesianly isn't a philosophical option: it's an operational necessity. Don't ask "what is the answer?" Ask "what is the distribution of possible answers, and with what confidence?"

A reverend from the 18th century, working in solitude with quill and ink in an English spa town, solved a problem that today powers medicine, marketing, cybersecurity, supply chain management, and artificial intelligence. And he did it with an idea so simple it fits in a single sentence: update what you believe with what you observe. Two hundred and sixty years later, we still haven't found better advice.

Sources of Interest:

S&OP Engineering II: Demand Planning from Guessing to Probability

Sat, 28 Mar 2026 16:18:34 +0000

Your Excel says "we'll sell 100 units." A round, clean, deterministic number. What if you sell 120? Stockout, unhappy customer, contractual penalty. What if you sell 50? 50 units sitting in your warehouse, immobilizing capital that could be generating returns.

The problem isn't the forecast itself. It's the arrogance of the single number.

In Chapter 1 we built a "Quality Valve" that filters ERP noise. Now that we have a pure signal, we're going to do something Excel can't: measure uncertainty.

Executive Summary: A probabilistic forecast doesn't tell you "you'll sell 100." It tells you "with 95% probability, you'll sell between 35 and 157." That uncertainty band is the mathematical foundation for calculating your Safety Stock without resorting to rules of thumb.

The Architecture: MLOps, Not Scripts

We haven't written a throwaway script. We've connected our mathematical brain (Python/Prophet) directly to our Single Source of Truth (Supabase/PostgreSQL).

The key design is the demand_forecasts table. Notice one column that separates this from a basic tutorial:

CREATE TABLE demand_forecasts (
    id              UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
    execution_date  DATE NOT NULL,     -- ← When we ran the model
    ds              DATE NOT NULL,     -- Predicted future date
    yhat            NUMERIC NOT NULL,  -- Central prediction
    yhat_lower      NUMERIC NOT NULL,  -- Lower bound (Safety Stock)
    yhat_upper      NUMERIC NOT NULL,  -- Upper bound (Risk)
    model_version   TEXT NOT NULL,     -- Traceability
    UNIQUE(execution_date, ds)         -- One forecast per execution and date
);

Why execution_date? Because in 6 months, when you want to audit whether your model was accurate, you need to know when you made the prediction versus what actually happened. This is what MLOps calls Snapshotting: recording the context of each execution to evaluate model drift over time.

Without this column, you have a model. With it, you have an auditable system.

The Engineering: Why Prophet (and Not a Textbook ARIMA)

Prophet is a time series engine developed by Meta, designed for irregular business data: gaps, holidays, trend changes. Exactly what a real supply chain has.

Here's the core fragment from our ProphetPredictor class:

def train_model(self, country_code='ES'):
    """
    Trains Prophet with two key S&OP configurations:
    - interval_width: Confidence interval width
    - country_holidays: Country operational context
    """
    self.model = Prophet(
        interval_width=0.95,     # ← 95% confidence interval
        weekly_seasonality=True,
        yearly_seasonality=True
    )
    # Holidays that alter loading/unloading patterns
    self.model.add_country_holidays(country_name=country_code)
    self.model.fit(self.ts_df)

Two engineering decisions that separate us from a YouTube tutorial:

interval_width=0.95: This is not a decorative parameter. The upper bound (yhat_upper) represents the maximum probable demand with 95% confidence. This is literally your calculation basis for Safety Stock: Safety Stock = yhat_upper - yhat. Without this interval, your safety stock is a gut feeling; with it, it's mathematics.

add_country_holidays('ES'): In S&OP, holidays aren't "days off." They're operational anomalies: the factory closes, the warehouse doesn't dispatch, transportation stops. If the model doesn't know that August 15th is a national holiday in Spain, it will interpret the drop in orders as a downward trend. This corrupts the September prediction.

Translating Math into Business Decisions

Theory is nice. But a CEO doesn't approve budgets based on Python code. They need visual evidence.

The Probabilistic Forecast

The black dots are your actual historical demand. The central blue line is the prediction (yhat). The shaded band is the 95% confidence interval. The greater the historical volatility, the wider the band → the more Safety Stock you need → the more cash you immobilize. This band is the conversation you should be having with your CFO.

Explainability: Separating Trend from Seasonal Noise

This is XAI (Explainable AI) applied to business. The model separates Trend (is the business growing or shrinking?) from Seasonality (are there spikes by time of year?) and holiday effects. This is what the CEO needs to see to approve the operations plan: knowing whether growth is real or just a calendar effect.

Open Kitchen: Try It Yourself

I distrust articles I can't execute. That's why I've prepared an isolated environment where you can train the model on an anonymized snapshot of the data we just cleaned in Chapter 1.

You don't need to install Python, Prophet, or configure Supabase. You just need a browser:

Open the interactive Notebook on Google Colab

Hit "Play" on the cells and watch a probabilistic forecast with uncertainty bands being generated. Modify the horizon, the country, the confidence interval. Do engineering, not faith.

Next Step: From Prediction to Decision

Now we know the probability of what we're going to sell. The question shifts from "how much will we sell?" to "what should we manufacture or purchase to maximize margin and minimize risk?".

In Chapter 3, we'll introduce Mathematical Optimization (PuLP) and Theory of Constraints to transform predictions into supply decisions: how much to buy, when to produce, and how to distribute finite resources while minimizing costs.

The difference between an Operations Director who reacts and one who decides is a mathematical model between the data and the action.