Research
The research library
Each entry carries its evidence status, its method and its limitations, and several are negative results. We do not file anything here as simply validated, because in our experience almost nothing ever is, and a library that says otherwise is not telling you about its standard.
RSS · Ideas, backtests, proofs, field tests and negative results — kept honestly distinct.
Looking for formal papers and the proofs of concept behind them? Those live in the Lab.
Reading the labels
What each evidence status means
Every entry carries one of seven, and they are ordered: each rung says what has been shown and, by omission, what has not. The label is chosen before the writing, so it cannot be talked upwards afterwards.
- Idea
- A formulation we think is right, with no result behind it yet. It is the label we use most, and a frontier looks like that from the inside.
- Reproduced
- Someone else's published result, rebuilt here and obtained again. It says the method works as described, and nothing about whether it helps your business.
- Backtested
- Run against history the model never saw, and measured against an agreed baseline. A backtest is evidence about the past, and the next rung exists for that reason.
- Formally proved
- A property machine-checked over every admissible input, with its assumptions written down. It covers the stated property, and says nothing about the rest of the system.
- Field-tested
- Run forward on live decisions, against the way the decision was being made before, with the test fixed before the data was opened.
- In production
- Operating inside a business now, with someone accountable for running it. The strongest label here, and the one fewest entries carry.
- Negative result
- A candidate that failed the test set for it, kept and published. It stays here so that the next person with the same idea finds out for the price of a page.
Two habits sit behind the labels. The test that would falsify a result is written down before the result is opened, so a disappointing run cannot be relabelled as a promising one. And every entry states where it stops applying, in its own words, under limitations. If you only read one line of an entry, read that one. How we validate counts how the whole library falls across these seven, including how often the lowest grades get used.
The ROI of AI coding tools survives or dies on rework
More code shipped is not more value delivered. The economic question is what the accepted, un-reworked, in-production fraction of AI-assisted output costs, and earns.
The decision beneath the feature request
The most valuable software projects rarely begin with a feature list. They begin with a repeated decision the business cannot yet make well.
What a piece of evidence is worth
Before you pay to gather more data, there is an exact number for how much a better answer could improve the decision it feeds, and often it is zero.
Which broken thing to fix first
When remedial capacity is smaller than the problem, the order of repair is a decision worth optimising, against downstream loss, contractual exposure and customer value, not just severity.
Why we publish negative results
A method that fails a pre-registered test is a result worth keeping, because it stops the next team from spending on the same dead end.
Scheduling when the durations are uncertain
When durations and arrivals are uncertain, the useful schedule is the one that stays good across scenarios, not the one that looks tidy on the plan that will not happen.
A 1,200-line kernel that proves operations-research algorithms
Rainbow machine-checks OR algorithms against a tiny trusted dependent-type kernel: the full 222-algorithm catalogue is now proved.
What a plan-versus-reality gap is for
The gap between what a team planned and what it delivered is only useful if it changes a decision, reallocation, rescoping or renegotiation, while there is still time.
Forecasting a project's cost-to-complete before finance can see the loss
A lognormal accelerated-failure-time model with MCMC diagnostics estimates when, and how confidently, a delivery will overrun, while intervention is still possible.
Operations research as compositions of a few higher-order functions
A zero-dependency Clojure library shows optimisation, sequential decision-making and validation are compositions of a small set of higher-order-function patterns.
MLOps for teams who work in Clojure
chachaml tracks experiments, models and pipelines from the REPL, a web UI or an LLM agent: a first-party MLOps substrate for teams doing machine learning in Clojure.
A book that argues operations research is a handful of functions
Applied Higher Order Functions catalogues about 480 optimisation, decision and validation algorithms and shows they are compositions of a small set of higher-order-function patterns.
Engineering writing
104 more articles from the years of building
The typed research above is the newest, most carefully labelled work. Behind it sits a deep archive of engineering writing, Clojure, data-oriented systems, MLOps, formal methods and delivery, being migrated into this library.
Clojure & functional programming
Why Functional Programming Makes Complex Systems Easier to Build
Big systems get complicated fast. Features + changes tangle code → tough updates.Functional programming keeps code solid: predictable, clear, reusable. Easier to read, test, debug, extend. It helps teams stay coordinated and lets developers spend more time building new things—not just untangling…
Engineering practice
Why Most Developers Make Algorithms More Complicated Than They Need to Be
Most developers don’t write tangled algorithms because they lack skill. The problem may start before they write a single line. Most developers don’t create complicated code because they lack skill. It often starts with how they approach the problem. A simple idea can slowly turn into nested…
AI & machine learning
From Prototype to Production: The Business Case for Chachaml Part 3
This is the final article in our series, Clojure Meets Production MLOps: How chachaml Delivers AI-Native Workflows. If you’re joining here, you may want to start with the earlier posts: In this final article, we’ll focus on the business side.
AI & machine learning
Inside chachaml: Core Capabilities for AI-Native Workflows in Clojure Part 2
This is Part 2 of our series, Clojure Meets Production MLOps: How chachaml Delivers AI-Native Workflows. If you missed Part 1, Why Machine Learning Projects Fail in Production—and How chachaml Solves the MLOps Gap, we covered a common issue in machine learning.
AI & machine learning
Clojure Meets Production MLOps: How chachaml Delivers AI‑Native Workflows ( Part 1)
This is the first article in our three-part series, Clojure Meets Production MLOps: How chachaml Delivers AI-Native Workflows. In this article, we look at a problem many ML teams run into.
Clojure & functional programming
Building Data-Heavy Systems in Clojure Without Losing Simplicity
As data volumes grow, complexity tends to grow with it, but Clojure offers a different approach using simple, data-centric architectures.
AI & machine learning
Data Pipelines for Machine Learning: From Ingestion to Training (2026 Guide)
Most of what decides whether a machine-learning system works is the data pipeline behind it, not the model on top.
AI & machine learning
MLOps in 2026: What Is It and Why Should You Care?
MLOps is the operational framework that ensures machine learning models are built, deployed, and run efficiently at scale.
Clojure & functional programming
New Era for Clojure: Infix Syntax!
Flexiana open-sources Infix, a library that brings natural infix notation to Clojure while compiling to standard prefix forms with zero runtime overhead.
Also: our engineering handbook — practical notes on running teams, productivity and delivery.