The Gmail moment for supply chains
I learned long ago that the most stubborn forms of legacy are not lines of code; they are mental models. In the early 2000s, corporate email “fought spam” by offering knobs. You could compose your own filters, maintain blocklists, tweak thresholds and, when all else failed, ask every employee to manage their own safe/blocked senders. The proposition was empowering on paper and exhausting in practice. It promised control but delivered maintenance.
Gmail made that entire feature set irrelevant in one stroke. The day it arrived, spam filtering ceased to be a user problem. Expectations were elevated; the baseline changed. That shift is the closest analogue I know to what Lokad brings to supply chain.
Remembering the pre‑Gmail era
Corporate anti‑spam started with blacklists and rules. Gateways queried DNS‑based blocklists (RBL/DNSBL) to decide whether to accept or reject a message at all. On top of that, administrators layered content rules—subject contains X, headers look like Y—while users curated their own safe and blocked senders to rescue false positives that inevitably accumulated. It was a patchwork that mixed infrastructure‑level reputation with mailbox‑level tweaks, and it required constant gardening.
To its credit, the field did not stand still: Bayesian techniques and scoring engines such as Apache SpamAssassin blended heuristics (headers and body cues) with statistics and external signals (DNSBLs). This was progress, yet the operating model remained the same: a configurable apparatus that each company had to tune locally and babysit daily. The burden of making the system “good enough” was shouldered tenant by tenant.
The hardware and services market grew around this burden. Gateways and appliances—Postini, Brightmail and their peers—promised relief, but still revolved around rules, signatures and quarantine workflows, all curated per customer. They worked, but their very value proposition reinforced the assumption that quality hinged on vigilant, ongoing configuration.
What Gmail changed
On April 1, 2004, Gmail surfaced a different stance: centralize the intelligence, collect global feedback, and let the machine do the work. Instead of distributing knobs to billions of users and millions of admins, it gave a single bit of feedback—“Spam / Not spam”—and learned across the network effect of everyone’s mail. The rest was table stakes: the model updates were Google’s job, not yours.
Critically, this was not merely architectural elegance; it reset outcomes. Google has been explicit for years: Gmail’s AI‑powered defenses block more than 99.9% of spam, phishing and malware, intercepting on the order of 15 billion unwanted messages per day. Users didn’t become anti‑spam experts; the system simply stopped asking them to be. The “feature” of DIY rule management lost its meaning once a reliable, unattended service existed.
The lesson for supply chains
Most supply‑chain software remains in that pre‑Gmail posture. It celebrates configurability—thousands of parameters, dozens of toggles per SKU, intricate rule palettes for safety stocks, min/max levels, lead‑time calculations, sourcing priorities. The implicit theory is that better planning equals a better user interface for the same old heuristics. The outcome is familiar: fleets of planners export to spreadsheets, rules drift, and performance depends less on the tool than on the stamina of the people orbiting it.
Lokad was created to break this posture. Our stack is built around probabilistic forecasting and stochastic optimization, designed to output ranked, executable decisions—what to buy, where to place it, when to move it, at what price—under your explicit constraints and financial drivers. The emphasis is not on “giving you more knobs,” but on encoding your economics once and letting a decision pipeline run unattended, with human attention reserved for supervision and structural change.
If you need a label, think of Lokad as your AI pilot for supply chain. The intent is unapologetically robotic: to robotize the mundane, high‑volume decisions that consume human hours and invite inconsistency. People think; machines work. The machine, in our case, is a probabilistic optimizer continuously fed by your data and continuously improved on our side. The point is not to eliminate planners; the point is to stop asking them to handcraft thousands of rules that a machine can enact more consistently and more quickly.
There is a second lesson from Gmail’s model: central improvements should accrue to everyone without new projects. Lokad’s domain‑specific language, Envision, was designed so that platform‑level advances (including automated script rewrites when the language evolves) propagate without clients having to manually refit their configurations. When our algorithms improve, your decision pipeline benefits without a retuning ceremony. That is the supply‑chain equivalent of model updates landing in Gmail without each mailbox owner editing their filters.
Once you accept this posture, the traditional buying criteria make less sense. RFPs that compare the number of screens, the quantity of parameters, or how many ways a safety stock can be “configured,” are evaluating for a world in which planners must write their own anti‑spam rules. In a decision‑centric world, the relevant questions are different: Can the system generate unattended, auditable, financially‑prioritized decisions every day? Can it digest constraints as they actually are, rather than as a UI checkbox would like them to be? Can it keep learning and improving without staging a consulting exercise each quarter? These are the questions that separate a robotized pipeline from a nicer cockpit for manual flight.
Let me be clear about what Lokad is not. It is not an APS, and not even a “better APS.” APS tools were conceived to orchestrate human workflows and to expose configuration to planners. Lokad’s aim is to collapse the distance between data and action: encode the economics upstream, emit decisions downstream. Our materials elaborate this perspective at length—the decision‑driven approach, the insistence on probabilities rather than points, the end‑to‑end automation that still remains fully auditable. If this seems radical, that is because the prevailing mental model is still pre‑Gmail.
What, then, becomes of the planner? The same thing that became of the email user. They stop firefighting and start supervising. They own business logic and outcomes, not buttons and toggles. They correct the machine by clarifying objectives and constraints, not by authoring another exception rule. This is a more demanding role intellectually and a far more effective one economically. It is also the only role that scales when your network explodes in complexity and volatility—exactly the scenario where rule jungles fail and probabilistic automation thrives.
Gmail did not win by offering a better rule editor. It won by making rules someone else’s problem, and by proving that centralized, learning systems outperform bespoke, local tuning at scale. Supply chains deserve the same relief. If you still evaluate planning software by how gracefully it lets you maintain parameters, you are measuring a horse for a car race. The baseline has moved. Lokad exists to make the old criteria—and the busywork they enshrine—irrelevant.
