For MLOps teams
MLOps for Clojure teams, and the decisions underneath it
Getting a model served is a solved engineering problem, and if your team is in Clojure we have a library for it. What stays unsolved is everything the serving does not answer: when to retrain, which candidate to promote, whether the next experiment is worth its cost, how much labelling to buy before the answer stops improving. Those are decisions under uncertainty, and most teams make them by convention because nobody has priced the alternative. We build the tracking underneath them, and then we model the decisions themselves.
The substrate
chachaml
If your machine-learning work lives in Clojure, usually because the surrounding decision system does, you have had two options: bolt MLflow on through a foreign-function bridge, or go without experiment tracking, a model registry and reproducibility. Both are bad, and we lived with both before we wrote the third.
-
Experiment tracking from the REPL
Plain maps and dynamic vars, no ceremony and no separate service to stand up before you can record a run.
-
A model registry and artefact store
Runs, artefacts and models kept together, so a result from three months ago can still be reproduced. Recognising it is not the same thing.
-
A web UI, an MCP server and chat-with-data
The same history readable by a person in a browser or by an agent over MCP, which matters more every month.
What it is
- Licence
- MIT
- Version
- v0.7.0
- Published
- GitHub + cljdoc
- Evidence
- In production
Where it is the wrong tool
chachaml is a tracking and operations layer. It is no kind of modelling framework: it does not train models for you, and its scikit-learn interop depends on libpython-clj2. It is Clojure-native by design. Teams standardised on a Python-only stack will find MLflow a more natural fit, and we would rather say so here than discover it with you in week three.
The decisions underneath
The decisions underneath the pipeline
Tracking tells you what happened. It does not tell you what to do next, and the choices that follow are where the money is. Each is made repeatedly, under uncertainty, usually on a rule of thumb that somebody set two years ago and nobody has priced since.
-
When should this model be retrained?
On a calendar, on a drift alarm, or when the expected cost of staleness exceeds the cost of a retrain. Only the third is a decision. The first two are habits that happen to be defensible.
-
Which candidate gets promoted?
A metric improvement on a held-out set is not the same as a better decision in production. What matters is the change in downstream outcome, and whether it survives the way the model is used.
-
Is the next experiment worth running?
Experiments cost compute, time and attention. Some of them cannot change any decision you would make afterwards, and those should not be run at all, however interesting they are.
-
How much labelling should you buy?
Labelling improves the answer with diminishing returns against a fixed budget. That is an allocation problem with a known shape, and it has an answer.
-
What does drift cost?
A drift alarm without a loss attached is a notification. Priced against the decision it degrades, it becomes something you can act on proportionately.
How we engage
How an engagement runs here
We do not arrive with a platform. We start by finding whether a decision is worth improving at all, and prove the value on your own data before anyone commits to building a system to sustain it.
1. Audit
Find the decision that pays
A Decision Opportunity Audit runs on one model or pipeline, establishes the baseline and the economic stakes, and ends with a candid recommendation, including the possibility that no system is needed.
2. Proof
Test it against your baseline
If the value is there, a proof of value tests the method on your own history before it is trusted, measured against the rule you run today, with calibration reported. Our standard for what counts as evidence is set out in how we validate.
3. Build
Build what proved out
Only what proved out gets built into something durable and owned. Find, Prove, Build keeps each stage honest, so evidence sets the scope.
How you can check us
How to check us
Anyone can show you the experiments that came out well. The research on this site carries an evidence status on every entry (idea, reproduced, backtested, formally proved, field-tested, in production, negative result), and the negative ones stay published instead of quietly disappearing.
That is the same standard we would hold your models to. It is the only good reason to take a method seriously: not that it always works, but that you can see where it does not.
Who this is for
- Clojure or JVM teams whose ML work is stranded outside the language.
- Teams with models in production and no measured basis for retraining them.
- Data-science groups whose notebooks never became an operable system.
- Anyone who wants the decision priced as well as the pipeline built.
When we are a fit
- Your ML sits inside a Clojure or JVM system and the tooling fights you.
- Models are in production and the retrain cadence is a habit nobody has priced.
- Someone can act on the answer once it exists.
When we are not
- You are standardised on a Python-only stack and happy with MLflow.
- You want a modelling framework. chachaml does not train models.
- There is one model, changed rarely, with little riding on it.
FAQ
Questions from MLOps teams
What is chachaml, exactly?
A REPL-first MLOps library for Clojure: experiment tracking, artefact storage, a model registry and reproducibility, in plain maps and dynamic vars, with no foreign-function bridge to MLflow. It is MIT-licensed, published to cljdoc and on GitHub, and it shipped v0.7.0. It also carries a web UI, an MCP server and chat-with-data, so an agent can read your experiment history as easily as you can.
What does chachaml not do?
It is a tracking and operations layer. It does not train models for you, and its scikit-learn interop depends on libpython-clj2. It is Clojure-native by design. So if your team has standardised on a Python-only stack, MLflow is the more natural fit, and the audit will say so. Selling you a migration is a business other people are in.
Why would an MLOps problem need a decision-systems firm?
Because most of what is called an MLOps problem is a decision problem wearing infrastructure clothes. When to retrain, which model to promote, whether an experiment is worth running, how much labelling budget to spend before the answer stops improving. Each is a choice under uncertainty with a cost attached, and each is usually made by convention. Measurement rarely comes into it, and the pipeline turns out to have been the easy half.
Do you have an ML case study?
Not a client one written up, and we are not going to invent one. What is public is the library itself, the research note behind it, and the negative results we publish alongside the positive ones. Judge us on code you can read and a method you can check, because a testimonial would tell you less than either.
Can you work in Python?
Yes. Our own tooling lives in Clojure, and that is where we are unusual, but the engineering work is language-led by the problem. Preference does not come into it. chachaml exists because a client system was Clojure and the MLOps tooling assumed otherwise. That is a fact about one client and not a belief about the world.
Start with the decision
Bring us one model
One model in production, with its retrain cadence, its promotion rule and its labelling budget. A short audit run by a partner will say what the current convention costs against a measured alternative. The fee is fixed before we start.
Who you deal with
The senior people who frame the problem build it and stay accountable afterwards. Work is confidential and unattributed by default, and the clients named on this site are there because those owners agreed to it. References will tell you plainly what did not work.