DEV Community: White Oak Intelligence

The Monty Hall Problem: Why Switching Doors Wins 2/3 of the Time

White Oak Intelligence — Fri, 29 May 2026 00:00:00 +0000

You pick one of three doors. The host — who knows what's behind every door — opens a different door to reveal a goat, then offers you the chance to switch. Should you switch or stay?

The near-universal wrong answer is 50/50. The correct answer: switching wins with probability 2/3. Staying wins with probability 1/3. This has been verified analytically, computationally, and empirically millions of times. When Marilyn vos Savant published the correct solution in 1990, she received thousands of letters from PhD mathematicians insisting she was wrong. She was not.

The Case Enumeration

Without loss of generality, assume the car is behind Door 1. There are three equally probable initial picks:

Case 1: You pick Door 1 (car). P = 1/3.  Switch → LOSE. Stay → WIN.
Case 2: You pick Door 2 (goat). P = 1/3. Switch → WIN.  Stay → LOSE.
Case 3: You pick Door 3 (goat). P = 1/3. Switch → WIN.  Stay → LOSE.

Switch wins in 2 of 3 cases → P(win | switch) = 2/3
Stay wins in 1 of 3 cases  → P(win | stay)   = 1/3

The Bayesian Derivation

Suppose you pick Door 1 and the host opens Door 3. Applying Bayes' Theorem:

P(car at Door 1 | host opens Door 3) = (1/2 × 1/3) / (1/2) = 1/3
P(car at Door 2 | host opens Door 3) = (1   × 1/3) / (1/2) = 2/3

The host's action is not random — he always reveals a goat and never opens your door. That constrained action transfers probability mass from the opened door onto the remaining unchosen door. Switching captures that mass; staying forfeits it.

The Generalized N-Door Result

With N doors, after the host opens N−2 goat doors:

P(win | switch) = (N−1) / N
P(win | stay)   = 1 / N

At N=1000: switching wins 999/1000 of the time.

Python Simulation (1,000,000 Trials)

import random

def monty_hall_trial(switch=True):
    doors = [0, 1, 2]
    car = random.choice(doors)
    pick = random.choice(doors)
    goat_doors = [d for d in doors if d != pick and d != car]
    host_opens = random.choice(goat_doors)
    if switch:
        final = [d for d in doors if d != pick and d != host_opens][0]
    else:
        final = pick
    return final == car

n = 1_000_000
switch_rate = sum(monty_hall_trial(True)  for _ in range(n)) / n
stay_rate   = sum(monty_hall_trial(False) for _ in range(n)) / n
print(f"Switch: {switch_rate:.4f}  (exact: 0.6667)")
print(f"Stay:   {stay_rate:.4f}  (exact: 0.3333)")

Read the full article with complete Bayesian derivation and N-door generalization →

Nash Equilibrium and the Golden Ratio: The Optimal Redraw Threshold

White Oak Intelligence — Thu, 28 May 2026 00:00:00 +0000

Two players each draw a number uniformly from [0, 1]. Each player may optionally discard their draw and take one new draw. The player with the higher final number wins. What is the optimal threshold strategy — the cutoff below which you should redraw?

The answer is the golden ratio: t* = (√5 − 1)/2 ≈ 0.618. If your draw is below 0.618, redraw. If it is 0.618 or above, keep it.

The Nash Equilibrium Derivation

Assume both players play a symmetric threshold strategy t. A player who kept their draw x wins against an opponent using threshold t with probability:

P(win | keep x) = t + (1−t) × x     for x ≥ t

A player who redraws wins with expected probability:

P(win | redraw) = ∫[0,1] [t + (1−t)y] dy = t + (1−t)/2

At the Nash equilibrium, a player must be indifferent between keeping and redrawing at exactly x = t:

t + (1−t) × t = t + (1−t)/2
t(1−t) = (1−t)/2
t = 1/2  ... only if t ≠ 1

Solving the quadratic at the boundary condition where keeping t equals the expected value of a redraw:

(t*)² + t* − 1 = 0
t* = (−1 + √5) / 2 ≈ 0.6180

This is precisely the golden ratio φ − 1 = 1/φ.

Python Simulation

import random

def do_over_trial(t=0.6180):
    def draw_with_threshold():
        x = random.random()
        return random.random() if x < t else x
    p1, p2 = draw_with_threshold(), draw_with_threshold()
    return p1 > p2

n = 1_000_000
win_rate = sum(do_over_trial() for _ in range(n)) / n
print(f"Win rate at t=0.618: {win_rate:.4f}  (expected: 0.5000 at Nash equilibrium)")

Read the full article with complete equilibrium derivation and win-probability surface →

The Taxi Cab Problem: Why 80% Reliable Witnesses Are Usually Wrong

White Oak Intelligence — Wed, 27 May 2026 00:00:00 +0000

A cab was involved in a hit-and-run accident at night. Two companies operate in the city: Green cabs (85% of all cabs) and Blue cabs (15%). A witness identified the cab as Blue. The court tested the witness under identical conditions and found an 80% correct identification rate (20% error rate). What is the probability the cab was actually Blue?

Most people — including attorneys and judges — immediately answer 80%. The correct answer is 41.4%. It is more likely (58.6%) that the cab was Green, despite a credible witness swearing it was Blue. This is the Base Rate Fallacy, documented by Kahneman and Tversky as one of the most durable cognitive errors in human reasoning.

The Arithmetic Intuition

Consider what happens across 10,000 accidents:

8,500 involve Green cabs → 1,700 witness incorrectly says "Blue" (20% error)
1,500 involve Blue cabs → 1,200 witness correctly says "Blue" (80% accuracy)

Total "Blue" claims: 2,900
Actually Blue: 1,200 → 1,200 / 2,900 = 41.4%

The false positives (1,700) outnumber the true positives (1,200) because Green cabs are so prevalent that even a small error rate generates a flood of false Blue identifications.

The Bayesian Proof

Let B = cab is Blue, G = cab is Green, W_B = witness says "Blue".

P(B) = 0.15, P(G) = 0.85
P(W_B | B) = 0.80, P(W_B | G) = 0.20

P(B | W_B) = P(W_B | B) × P(B) / [P(W_B | B) × P(B) + P(W_B | G) × P(G)]
           = (0.80 × 0.15) / [(0.80 × 0.15) + (0.20 × 0.85)]
           = 0.12 / (0.12 + 0.17)
           = 0.12 / 0.29
           ≈ 0.4138 (41.4%)

Python Simulation (1,000,000 Trials)

import random

def taxi_cab_simulation(n=1_000_000):
    witness_said_blue = 0
    actually_blue = 0
    for _ in range(n):
        cab_is_blue = random.random() < 0.15
        correct = random.random() < 0.80
        witness_says_blue = cab_is_blue if correct else not cab_is_blue
        if witness_says_blue:
            witness_said_blue += 1
            if cab_is_blue:
                actually_blue += 1
    return actually_blue / witness_said_blue

random.seed(42)
print(f"P(Blue | witness says Blue): {taxi_cab_simulation():.4f} (exact: 0.4138)")
# Output: P(Blue | witness says Blue): 0.4142

Litigation Applications

The Base Rate Fallacy governs how juries evaluate conditional evidence in every domain where rare events are tested by imperfect instruments:

Eyewitness testimony: An 80% accurate identification rate does not mean 80% probability of guilt. The posterior depends critically on how many individuals in the suspect pool could plausibly have committed the crime.
Breathalyzer evidence: A 95% accurate instrument applied to a population where base-rate impairment is low produces a non-trivial false positive rate. The probability of actual impairment given a positive reading is substantially lower than 95%.
eDiscovery / Technology-Assisted Review: A 90% accurate document classifier applied to a corpus where 5% of documents are responsive generates roughly equal numbers of true positives and false positives.
Financial fraud detection: A fraud model with 99% specificity applied to billions of transactions still flags tens of millions of legitimate ones annually.

Attorneys who quantify the posterior probability — not just cite the accuracy statistic — can neutralize evidence that appears overwhelming on its face. Gut instinct on conditional probability is demonstrably, mathematically broken.

Read the full article with complete proof and litigation framework →

Recursive Probability: Solving the Amoeba Extinction Problem

White Oak Intelligence — Tue, 26 May 2026 00:00:00 +0000

A single amoeba sits in a petri dish. At each time step it independently either dies (probability 1/3), remains as one amoeba (probability 1/3), or splits into two amoebae (probability 1/3). What is the probability that the population eventually goes extinct?

The intuitive answer is "less than 1" — the amoeba has a 1/3 chance of splitting, which seems like it should guarantee survival with positive probability. The correct answer is 1: extinction is certain.

The Proof

Let p be the probability of eventual extinction starting from a single amoeba. Conditioning on the first event:

p = (1/3)(1) + (1/3)(p) + (1/3)(p²)

The three terms:
  (1/3)(1)    — amoeba dies immediately → extinct
  (1/3)(p)    — amoeba stays → one amoeba, extinction probability p
  (1/3)(p²)   — amoeba splits → two independent amoebae, both must go extinct

Solving 3p = 3 + 3p + p² → wait, let me be precise:

p = 1/3 + p/3 + p²/3
3p = 1 + p + p²
p² − 2p + 1 = 0
(p − 1)² = 0
p = 1

The quadratic has a unique solution: p = 1. Extinction is certain. Despite having a positive probability of growth at every step, the population cannot sustain itself indefinitely because the expected offspring count (mean = 1) is not sufficient — what matters is the fixed-point structure of the generating function, which yields 1 as its only solution in [0,1] when the mean offspring count is ≤ 1.

The General Galton-Watson Result

This is a Galton-Watson branching process. The extinction probability is the smallest non-negative fixed point of the offspring generating function G(s). When E[offspring] ≤ 1, the fixed point at s=1 is the only solution in [0,1], so extinction is certain. When E[offspring] > 1, a second fixed point exists in (0,1), giving a positive survival probability.

Read the full article with generating function derivation and Python simulation →

Absorbing Markov Chains: Why E[HH] = 6 and E[HTH] = 10

White Oak Intelligence — Mon, 25 May 2026 00:00:00 +0000

How many coin flips does it take, on average, to see two consecutive heads (HH)? Most people guess 4. The correct answer is 6. How many to see HTH? Most people guess 6 or 8. The correct answer is 10. The difference between these two results reveals something fundamental about how overlapping patterns affect expected stopping times.

Expected Flips for HH (Markov Chain)

Define states: Start (S), one H seen (H), absorbing state HH. Let E_S and E_H be the expected flips to absorption from each state.

From S:  E_S = 1 + (1/2)E_H + (1/2)E_S
From H:  E_H = 1 + (1/2)(0) + (1/2)E_S

Solving: E_H = 1 + E_S/2
         E_S = 1 + (1/2)(1 + E_S/2) + E_S/2
         E_S = 1 + 1/2 + E_S/4 + E_S/2
         E_S/4 = 3/2  →  E_S = 6

Expected Flips for HTH

States: S, H (seen H), HT (seen HT), absorbing HTH. The critical difference: if we are in state HT and flip H to reach HTH — we are done. But if we flip H while in state H (trying to extend H to HT), we stay in state H (the new H starts a fresh potential HT sequence). This overlap structure inflates the expected time.

E_S  = 1 + (1/2)E_H  + (1/2)E_S
E_H  = 1 + (1/2)E_H  + (1/2)E_HT
E_HT = 1 + (1/2)E_HTH + (1/2)E_S  =  1 + 0 + (1/2)E_S

Solving the system: E_S = 10

HTH takes 10 flips on average versus 6 for HH. The reason: HH "reuses" its prefix — if you see H while waiting for the second H, you have not wasted that flip. HTH cannot reuse its prefix in the same way; a misfire often sends you back to the start.

Python Simulation

import random

def flips_to_pattern(pattern):
    seen = []
    target = list(pattern)
    flips = 0
    while seen[-len(target):] != target:
        seen.append(random.choice(['H', 'T']))
        flips += 1
    return flips

n = 100_000
hh_avg  = sum(flips_to_pattern('HH')  for _ in range(n)) / n
hth_avg = sum(flips_to_pattern('HTH') for _ in range(n)) / n
print(f"E[HH]:  {hh_avg:.2f}  (exact: 6)")
print(f"E[HTH]: {hth_avg:.2f}  (exact: 10)")

Read the full article with complete state-transition matrix derivation →

Stochastic Forecasting vs. Deterministic Models for Middle Market Valuations

White Oak Intelligence — Sun, 24 May 2026 00:00:00 +0000

A deterministic DCF model produces one number: the valuation. Change any input assumption and you get a different number. Run a sensitivity table and you get a grid of numbers. But a grid is not a probability distribution, and a point estimate is not a risk assessment.

Monte Carlo simulation replaces each uncertain input — revenue growth, margin expansion, exit multiple, discount rate — with a probability distribution and samples from all of them simultaneously across 10,000 trials. The output is a distribution of valuations, not a point estimate.

Why It Matters

A deterministic model might say: "at a 10x exit multiple and 12% EBITDA margin, the valuation is $47M." A stochastic model says: "there is a 15% probability the valuation exceeds $60M, a 50% probability it exceeds $38M, and a 20% probability it falls below $22M." These are fundamentally different statements. The second is actionable for structuring debt tranches, setting earn-out thresholds, and underwriting downside scenarios.

Python Implementation Sketch

import numpy as np

def monte_carlo_valuation(n=10_000):
    revenue_growth = np.random.normal(0.08, 0.04, n)   # mean 8%, std 4%
    ebitda_margin  = np.random.normal(0.14, 0.03, n)   # mean 14%, std 3%
    exit_multiple  = np.random.normal(9.5,  1.5,  n)   # mean 9.5x, std 1.5x
    discount_rate  = np.random.normal(0.12, 0.02, n)   # mean 12%, std 2%

    base_revenue = 10  # $10M
    projected_ebitda = base_revenue * (1 + revenue_growth)**5 * ebitda_margin
    terminal_value = projected_ebitda * exit_multiple
    npv = terminal_value / (1 + discount_rate)**5

    return npv

valuations = monte_carlo_valuation()
print(f"Median valuation:  ${np.median(valuations):.1f}M")
print(f"5th percentile:    ${np.percentile(valuations, 5):.1f}M")
print(f"95th percentile:   ${np.percentile(valuations, 95):.1f}M")

Read the full article with complete model architecture and interpretation framework →

Building Resilient Data Pipelines for Algorithmic Trading Systems

White Oak Intelligence — Sat, 23 May 2026 00:00:00 +0000

Production algorithmic trading infrastructure operates under constraints that expose every weakness in a naive data pipeline design. A missed tick, a stale price, or a silent failure during a volatile session is not a logging incident — it is a capital event. The architecture that handles this reliably has four distinct layers, each solving a specific failure mode.

Layer 1: WebSocket Ingestion with Reconnection Logic

Raw market data arrives over WebSocket connections that drop without warning. The ingestion layer must reconnect automatically, detect sequence gaps, and backfill missing ticks before they reach downstream consumers. Naive reconnect-on-error loops introduce latency spikes during reconnection. The correct pattern: maintain a secondary connection in standby and switch atomically on primary failure.

Layer 2: Ring Buffers for Zero-Copy Throughput

Between ingestion and strategy execution, a lock-free ring buffer (circular buffer) provides O(1) write and read with no heap allocation on the hot path. This eliminates garbage collection pauses in Python/JVM environments and bounds memory consumption regardless of tick volume spikes.

Layer 3: Z-Score Anomaly Detection

Price ticks and volume readings with Z-scores exceeding a configurable threshold (typically |Z| > 4) are flagged before reaching the strategy layer. This catches exchange data errors, fat-finger prints, and feed failures before they trigger incorrect signals. The Z-score window is computed on a rolling basis with exponential weighting to adapt to regime changes.

Layer 4: Circuit Breakers

When anomaly rate, latency, or error rate cross thresholds, the circuit breaker trips and halts order submission until conditions normalize. This prevents a data quality incident from cascading into uncontrolled position accumulation.

Read the full article with complete Python implementation →

Time-Based Triggers and Data Exports: Automating Workflows with Google Apps Script

White Oak Intelligence — Fri, 22 May 2026 00:00:00 +0000

Google Apps Script is underused by every organization running Google Workspace. It has direct, authenticated access to Sheets, Docs, Drive, Gmail, Calendar, and Forms — no API keys, no OAuth dance, no third-party integration layer. Combined with time-based triggers, it can replace a surprising fraction of the Zapier/Make subscriptions that organizations pay for to automate exactly the same workflows.

Time-Based Trigger Patterns

// Daily export: runs at 6AM every morning
function scheduleDailyExport() {
  ScriptApp.newTrigger('runDailyExport')
    .timeBased()
    .atHour(6)
    .everyDays(1)
    .create();
}

function runDailyExport() {
  const sheet = SpreadsheetApp.openById('SHEET_ID').getActiveSheet();
  const data = sheet.getDataRange().getValues();
  const csv = data.map(row => row.join(',')).join('\n');
  const file = DriveApp.createFile('export_' + new Date().toISOString() + '.csv', csv);
  GmailApp.sendEmail('reports@yourcompany.com', 'Daily Export', 'See attached.', {
    attachments: [file.getAs(MimeType.CSV)]
  });
}

Multi-System Sync Pattern

Apps Script can call external APIs via UrlFetchApp, transforming Sheets into a lightweight ETL hub: pull data from a REST API on a schedule, transform it in JavaScript, and write results back to Sheets or push them to another endpoint. This pattern replaces simple iPaaS workflows entirely for teams already in Google Workspace.

Read the full article with complete automation architecture →

Integrating LLMs into Custom CRMs for Specialized Deal Flow Management

White Oak Intelligence — Thu, 21 May 2026 00:00:00 +0000

Salesforce and HubSpot are built for the median B2B sale: SaaS, professional services, mid-market enterprise software. They assume structured pipelines, predictable deal stages, and standardized contact types. Equipment financing originators, niche private equity shops, and distressed asset managers operate nothing like the median B2B sale — and the CRM mismatch costs real money in missed follow-ups, data entry overhead, and lost context across long deal cycles.

What LLM Integration Adds

A custom CRM with an LLM layer can do things off-the-shelf tools cannot:

Automatic deal summarization: Ingest call transcripts, email threads, and document uploads; generate structured deal summaries that update the opportunity record automatically.
Intelligent next-action recommendations: Given deal stage, counterparty history, and time since last contact, surface the highest-priority follow-up actions ranked by estimated close impact.
Document parsing and term extraction: Feed term sheets, LOIs, and credit agreements to the LLM; extract key economic terms into structured fields without manual data entry.
Relationship intelligence: Map relationships across deals, identify warm introduction paths, and surface overlapping counterparty networks.

Architecture

The core stack: a PostgreSQL database for structured deal data, a vector store (pgvector) for document embeddings, an LLM API for inference, and a Python/FastAPI backend. The LLM is called only for enrichment tasks — not for CRUD operations — keeping latency and cost within acceptable bounds for a transactional CRM.

Read the full article with complete architecture and implementation details →

How to Architect an Automated Client Analytics and Reporting Engine

White Oak Intelligence — Tue, 19 May 2026 00:00:00 +0000

Manual client reporting is not a reporting problem. It is a systems problem masquerading as a communication process. The analyst who spends 15 hours per week pulling data, formatting tables, updating charts, and emailing PDFs is not doing reporting — they are doing data plumbing. The fix is an ETL pipeline that does the plumbing automatically.

The Four-Stage Architecture

Extract: Pull data from source systems (database queries, API calls, spreadsheet reads) on a schedule. Watermark-based incremental extraction ensures only new rows are pulled on each run, keeping jobs fast regardless of table size.
Transform: Apply business logic in Python — roll up metrics, compute period-over-period changes, flag anomalies, format numbers. This layer is where analysis lives; it is fully testable and auditable.
Load: Write transformed data to a Google Sheet via the Sheets API. The sheet is pre-formatted with client branding, chart definitions, and conditional formatting — it updates in-place.
Deliver: Trigger a PDF export of the sheet via the Drive API and send via Gmail API with a personalized message. The entire cycle runs unattended.

import gspread
from google.oauth2.service_account import Credentials

def update_client_report(client_id, data):
    creds = Credentials.from_service_account_file('service_account.json',
        scopes=['https://spreadsheets.google.com/feeds',
                'https://www.googleapis.com/auth/drive'])
    gc = gspread.authorize(creds)
    sh = gc.open_by_key(CLIENT_SHEETS[client_id])
    sh.worksheet('Data').update('A2', data)

Read the full article with complete ETL implementation →

Technical SEO for Financial Services: E-E-A-T, Schema, and Core Web Vitals

White Oak Intelligence — Sun, 17 May 2026 00:00:00 +0000

Financial services websites are classified as YMYL — Your Money or Your Life — by Google's Search Quality Evaluator Guidelines. This classification means Google applies its strictest ranking quality criteria to every page: E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) is not optional for financial services; it is the baseline for ranking at all.

E-E-A-T Signals That Move Rankings

Author credentials: Named authors with verifiable credentials and professional profiles linked to author pages. Anonymous content is a liability on YMYL sites.
Organization signals: Physical address, licensed entity information, regulatory credentials (CFA, CPA, bar admission) cited on the page where relevant.
Cite primary sources: Link to SEC filings, court records, regulatory guidance, and peer-reviewed research — not just to other blog posts.
Review and update cadence: Outdated financial information is an E-E-A-T red flag. Display last-reviewed dates and update content when regulatory or market conditions change.

JSON-LD Schema for Financial Services

{
  "@context": "https://schema.org",
  "@type": "FinancialService",
  "name": "White Oak Intelligence",
  "url": "https://whiteoakintel.com",
  "areaServed": { "@type": "State", "name": "North Carolina" },
  "serviceType": "Quantitative Modeling and Data Consulting"
}

Core Web Vitals Targets

LCP (Largest Contentful Paint) < 2.5s. INP (Interaction to Next Paint) < 200ms. CLS (Cumulative Layout Shift) < 0.1. On a static HTML site, these are achievable without a CDN by serving optimized images, deferring non-critical scripts, and reserving space for dynamically loaded elements.

Read the full article with complete technical implementation →

Beyond MAPE: Four Metrics That Actually Reveal Forecast Accuracy

White Oak Intelligence — Thu, 14 May 2026 00:00:00 +0000

Mean Absolute Percentage Error (MAPE) is the default forecast accuracy metric in most business forecasting contexts. It is also deeply flawed: it explodes when actuals approach zero, it is asymmetric (overforecasting and underforecasting by the same absolute amount produce different MAPE values), and it provides no baseline comparison — a model with 15% MAPE might be excellent or terrible depending on what a naive forecast would produce.

The Four-Metric Stack

import numpy as np
from scipy import stats

def forecast_evaluation(actual, forecast):
    n = len(actual)
    errors = actual - forecast

    # MAPE — use only where actuals are safely nonzero
    mape = np.mean(np.abs(errors / actual)) * 100

    # RMSE — penalizes large errors; same units as the series
    rmse = np.sqrt(np.mean(errors**2))

    # MASE — scaled against naive (lag-1) forecast; > 1 means worse than naive
    naive_mae = np.mean(np.abs(np.diff(actual)))
    mase = np.mean(np.abs(errors)) / naive_mae

    # Theil's U — ratio to naive forecast RMSE; < 1 means better than naive
    naive_rmse = np.sqrt(np.mean(np.diff(actual)**2))
    theils_u = rmse / naive_rmse

    # Ljung-Box — tests whether residuals are white noise (p > 0.05 = no autocorrelation)
    lb_stat, lb_pvalue = stats.acorr_ljungbox(errors, lags=[10], return_df=False)

    return {
        'MAPE': mape,
        'RMSE': rmse,
        'MASE': mase,
        "Theil's U": theils_u,
        'Ljung-Box p-value': lb_pvalue[0]
    }

A complete forecast evaluation reports all five outputs. MASE and Theil's U below 1.0 confirm the model outperforms a naive baseline. A Ljung-Box p-value above 0.05 confirms residuals are white noise — meaning the model has extracted all available signal and is not leaving systematic patterns unmodeled.

Read the full article with interpretation framework and regime-switching analysis →