How UNI Relates to Python-Based Active-Inference Tooling
Most working code in active inference today is written in Python. UNI is written in Elixir. That is a stack choice, not a claim of superiority, and it matters less than the science the two stacks share. Here is where the ecosystems meet, where they diverge, and why we treat the Python tooling as a companion, not a competitor.
The Python ecosystem, honestly summarised
The reference Python library is pymdp, an open POMDP active-inference toolkit that encodes generative models as categorical A, B, C, D matrices and computes variational free energy over discrete state spaces (Class E, per the pymdp paper by Heins, Millidge, Demekas and colleagues, 2022). Around it sit SPM style MATLAB DEM demos, the newer bayesian-flow-networks line of research, and a growing set of PyTorch and JAX notebooks aimed at scaling inference over continuous states. Books in the same orbit, Parr, Pezzulo and Friston (2022) chief among them, ground the math (Class E).
This is a healthy ecosystem, with real code you can run, and it teaches the equations well. If your team already lives in Python, that is the natural door in.
A complementary course, not a rival
The Themesis course Building Active Inference in Python is a hands-on Python walk through generative models, KL divergence, and free-energy minimisation, taught by AJ Maren (Class E). We link to it because it is a good on-ramp for practitioners who want to write the math themselves in the ecosystem where most of it already runs. Different stack from our Elixir workbench, same underlying science, and the two do not conflict. This is a factual pointer to a public course, not an endorsement of UNI by Themesis or of Themesis by UNI. Each project stands on its own receipts.
Where UNI diverges: BEAM, not batches
UNI's workbench runs on Elixir and the BEAM virtual machine. The reason is operational, not aesthetic. Active inference in the field is a control loop: perceive, update the posterior, act, observe, repeat, forever, across many concurrent agents that occasionally have to be restarted without taking the world down (Class C). BEAM was built for exactly that shape of workload, with cheap processes, supervisor trees, and hot code loading. The Precision Lab, Echo Lab, Loop Lab, Heart Lab, and Cell Lab on this site are each a long-lived process tree, not a script that computes once and exits.
Python remains excellent for the paper-writing side of the work: derive the update, plot the belief, publish the notebook. UNI does that side too, but our production surface is a supervised BEAM process rather than a Jupyter kernel (Class C). Choose the stack that fits the shape of the load.
What we borrow, what we test, what we publish
We borrow the discrete-time POMDP formulation from Parr, Pezzulo and Friston (2022) and keep the vocabulary common: generative model, Markov blanket, variational free energy, policy precision, expected free energy (Class E). We do not host their code, we cite it.
We test our own implementations in the open. The Cell Lab is a pre-registered falsification benchmark: five claims written with their falsifiers before any run, three losses recorded as plainly as the wins (Class E, benchmark on the Science page). Anyone reproducing the setup in Python is welcome, and if a Python controller beats ours on a family we lose, that is exactly the disconfirmation the benchmark is designed to surface.
Framing, without the salesmanship
UNI is a working hypothesis on an attainable path toward General Natural Intelligence: a natural, active-inference approach whose evidence is growing, evidence-classed, and tested in the open. Do not take the claim on faith. Test the build, inspect the gates, and help us find where it fails.
The Python tooling is doing the same work in a different language. Treat both as instruments, not tribes.