aubrika - Blog

jiujitsu is a manifold

2026-11-04T00:00:00+00:00

beginnings</h2>
When I first started martial arts at 17 at a little aikido dojo, I was not very coordinated. Having never done sports in any significant way, my body had some catching up to do and it felt like a long process. By the time I got to college and started training at the college judo club, I was a little more coordinated, but I still felt completely clueless about how to throw or pin anyone. I failed a lot. All I knew was that I had seen old black and white videos of Kyuzo Mifune doing beautiful judo, weighing even less than I did at the time, and I wanted to do that too.
When I was a sophomore I added Brazilian Jiujitsu to my training rotation and I was hooked for life. It gave my judo a larger game to live in, and I split my time between both sports for years. I approached judo like a kickboxer studying boxing: on the judo mat I was trying to sharpen specific tools for use in the bigger game of jiujitsu which had captured my imagination.
In those early days I still often had no idea why I succeeded or failed out on the mat, but I was learning. In my mind I started building models of what I was doing, and asking myself how best to understand such an expansive sport. My coach likens this initial state of trackless bewilderment to snow blindness, where a person is temporarily blinded by reflected light after walking out onto snow-covered terrain. Only in time and gradually do your eyes adjust and a landscape resolves around you.

the ladder</h2>
Early in my training, someone said to me: jiujitsu is like a ladder. You can climb a rung to a better position, or go down a rung to a worse position. It is important, therefore, to understand which positions are better or worse, and how to “climb” the ladder. In the most basic sense you have to orient yourself towards a better position: pinning someone, rather than being pinned, for example.

The problem with this, I eventually realized, is that the rungs were not arrayed in a sequence: you could and did travel from one rung to several other rungs that seemed to be nearby. So I thought: jiujitsu must be something like a tree.
a garden of many paths</h2>
When I had just started aikido, I thought that a specific attack (a karate chop to the side of your head, for example) had some single best response—or, at least, might have one. I didn’t know what the best thing to do there was (I got karate-chopped in the head plenty of times), but clearly there were several options, since my sensei showed us tons of different blocks, throws, dodges, all kinds of things. I figured in time I would know which one to pick out of the big lookup table containing all the aikido moves: if they did this, I would do this. Easy. I just had to figure out why to do one thing over another, after I figured out how to make the thing work in the first place.

I carried this concept with me into judo and jiujitsu and I began to slowly figure a few things out: if they are moving forwards, you throw them forwards, but if they are moving backwards—well, you throw them backwards. You choose the branch of travel that makes the most sense, costs the least effort, and has the greatest effect. The problem, of course, is that sometimes your opponents also move sideways, or up, or down, or roll, or stand up, or sit down—and they can do this from a number of starting positions. So I thought: jiujitsu must be something like a graph.
a subway map of many stations</h2>
Eventually in math I found an analogy I tried to hold over jiujitsu like a lens: the directed graph. A directed graph is a kind of network of nodes (also called vertices), connected by edges (also called arcs) representing the paths or connections between them. I thought the various named positions of jiujitsu—like back mount, side control, or half guard—must be like the nodes, and things like sweeps, transitions, turnovers, or takedowns must be like the edges you could travel between them.

I started building a kind of transit map in my head of all the different places you could go or be, and all the different things you could do to move between them. There seemed to be dozens, maybe hundreds, of positions—I wasn’t sure how to count them, how to divide up what often seemed like a continuous flow into meaningful discrete pieces. There were definite patterns, but also important differences between apparently similar positions. Many defied classification.
To make matters worse, there seemed to be a near-infinite number of ways to travel between named positions, and many of those paths concealed important intermediate arrangements, while the “stations” I had labeled contained their own detailed internal geography. My subway map started feeling coarse and patchy, and I could never quite draw it in two dimensions to my satisfaction. I saw that every notable jiujitsu position had two inhabitants with very different reviews of the position in question: where one was having a great time and the other really wasn’t.
Even if I couldn’t number the stations, or the routes, or tell you where the center is, it was still true that some positions were “closer” to others in kind of an adjacent way, and it was likewise somehow true that every peak of advantage on the landscape was also a valley of disadvantage for the other player. So I thought: jiujitsu must be something like a manifold.
a surface of many dimensions</h2>
A manifold is a kind of “surface”: you can think of it as a landscape or a terrain—with the caveat that a surface as we usually understand it has only two dimensions while a manifold can have many dimensions. The surface of an N-dimensional ball, for example, is an (N-1)-dimensional manifold.
In jiujitsu if you are holding someone in side control, we say you have the “top-side” position, while if you are the one being held down beneath the other person, we say you are in the “bottom-side” position. In the manifold model the top-side player occupies a peak, while the bottom-side player is constrained in the basin that peak describes when seen from the other side of the terrain. Your peak is their valley.

This invertibility of perspective gives the manifold model an involution: the operation of swapping the two players’ perspectives. An involution returns you to where you started when applied twice, like negating a number twice returns the original number. So the same occupied area within the whole available configuration space of every way two people can be tangled up together can be a position of either advantage or disadvantage, depending on whether you’re viewing the terrain from above or from below.
At any time you and your opponent occupy a mere sub-region of the vast landscape of possible configurations, but the whole terrain may seem to be turned inside-out in an instant, as if the smaller region you currently inhabit passed through the manifold to the other side. This happens whenever you swap sides of the same position, like when a turnover from bottom side control places you on top of that same side control position. You stayed in the same region—you just changed which side of the landscape you were on by swapping sides with your opponent.

When you are occupying a peak—for example, mount, top-side side control, or back mount—you can imagine an area stretching across that peak that’s as large as your available space of decisions. There’s a lot you can do from the top of a mountain that still keeps you on it. Your opponent, on the other hand, is on the other side of the terrain from you—in the underworld, the upside-down, and likely having a much worse time than you. And because on that side they occupy a basin—some kind of pit they have to climb or dig their way out of—their range of available motion and decisions is accordingly constrained. Their space of available decisions is constrained by the walls of that pit.
The goal of decisive victory via submission in jiujitsu is analogous to reducing your opponent’s space of available decisions until they are left with only one: giving up. You may do this by gradually reducing the volume they inhabit on their side of the terrain, steepening the walls they are forced to climb, until you compress the area surrounding them and all they can still do to a single point.
At that point, your victory and their defeat become one.
involution</h2>

Once upon a time, in a temple nestled in the misty end of south hill, lived a pair of monks. One old and one young.
“What are the differences between Heaven and Hell?” the young monk asked the learned master one day.
“There are no material differences,” replied the old monk peacefully.
“None at all?” asked the confused young monk.
“Yes. Both Heaven and Hell look the same. They all have a dining hall with a big hot pot in the centre in which some delicious noodles are boiled, giving off an appetising scent,” said our old priest. “The size of the pan and the number of people sitting around the pot are the same in these two places.”
“But oddly, each diner is given a pair of meter-long chopsticks and must use them to eat the noodles. And to eat the noodles, one must hold the chopsticks properly at their ends, no cheating is allowed,” the Zen master went on to describe to our young monk.
“In the case of Hell, people are always starved because no matter how hard they try, they fail to get the noodles into their mouths,” said the old priest.
“But isn’t that the same thing that happens to the people in Heaven?” the junior questioned.
“No. They can eat because they each feed the person sitting opposite them at the table. You see, that is the difference between Heaven and Hell,” explained the old monk. </blockquote>
(source</a>)
What else is like this?

On autonomic computing and Planarian

2026-11-02T00:00:00+00:00

Why autonomic computing?</h2>
When I was in undergrad, half my life ago and hours away from my parents, I served as their remote tech support whenever anything went amiss with their computers. At the time I was studying philosophy, but having grown up using computers, I still knew my way around them better than my parents did. They needed the help, to be sure, but I often found myself wishing we were talking about something else. I wished their computers would just fix themselves. I think a system that makes that kind of self-repair a reality for ordinary users would be a genuinely pro-social thing to build, and an accessibility aid for many.
This is not a new idea in computer science. In 2001, IBM named it autonomic computing, after the autonomic nervous system: computer systems that configure, heal, and protect themselves without being asked. Many have explored or implemented some vision of the self-healing, self-maintaining computer system since. Finding myself now at a time in my life where I am capable of sustained independent effort on more ambitious projects, I have decided to make my own attempt.
Why Planarian?</h2>
Anthropic’s AI, Claude, helped me compose an initial answer to this question, currently up on the Planarian repository</a>, but in my own words: I want computers to be safe and useful even if you don’t fully understand their inner workings or all the different ways they may go off the rails. I want this kind of assurance both for less-technical human users and for less-capable on-device AI agents. I want to be able to hand a computer, or a set of networked computers, to someone who might—through unfamiliarity, accident, or even malice—place that system in an undesirable state and watch the system self-correct to a known-good state that reflects the considered intent of the users.
In a time of accelerating complexity and capability, we all stand to become that person for whom the operations of the computer system are ultimately mysterious. Though we have long utilized code we do not personally write, in the form of trusted libraries and applications, never before have we been faced with such a dizzying volume of available, functional software—much of which no human eyes have read. How can we trust it?
Trust</h2>
There is a lot of talk these days about formal verification as a response to this problem: the idea that while we may not have written the code ourselves or while it may be too complex, dense, or alien in its structure to be practical to read, we can yet evaluate and audit it on the functional level via the exhaustive logical verification of various desired properties, guarantees, or invariants. Though this method is not a panacea and there remains much to be mindful of, I believe this approach has great promise and therefore this kind of assurance is one of the foundations of Planarian’s design.
The map over the territory</h2>
A finite state machine, or finite state automaton, is a functional representation of a system which moves between a finite number of known states along a finite number of known paths. Planarian doesn’t try to map every state a computer can be in; that space is far too large. Instead, it applies this idea to change itself. Every change to the system moves through a small, finite state machine, and the rule that decides which changes are allowed is proven correct. This layer sits on top of what is called the trusted computing base, the parts of the system we rely on without proving them, and offers an interface of operations that are few, checkable, and reversible. Around that, Planarian checks the machine against its declared configuration, so it knows when you have “fallen off the map,” and where you might encounter the dragons of unexpected computer behavior—ideally shortly before Planarian places you back into known territory, reserving the wilderness of the computational frontier to more deliberate explorers.
The vision</h2>
Planarian starts small: it is a homeostat and reference monitor for NixOS, meaning it is a program that runs on a particular operating system and performs various repairs. Eventually, extending the assurances and safety of the system will likely involve shipping a specific NixOS configuration, or something which might count as its own Linux distribution. Once Planarian is showing benefits for singular computers, I want it to be able to extend those same protections to various network topologies, possibly even automating aspects of device discovery to unfold into a fleet of coordinated machines from a single seed node—this would ideally let you pool and coordinate the resources of all your personal machines for various useful tasks, while still trusting that they’ll stay within desired behavior.
The method of development</h2>
Planarian is my first attempt at larger-scale swarm-based agentic engineering. None of the line-by-line code has been (so far) written by me: I have only directed its development via design, steering, and specification. The spec was written in dialogue with Claude Fable 5.1, and the vast majority of the code has been written and initially reviewed by Claude Opus 5.5, with some adversarial review also provided by ChatGPT Sol 6.1. One of my core assumptions regarding the agents working on Planarian is that they will make mistakes, bad calls, omissions, and ignore important things. I am therefore trying to build a reliable system out of unreliable components (a problem John von Neumann posed in almost those words in 1956), via a development layer which is essentially non-deterministic in specific instances but which in aggregate converges on correctness. I assume Planarian simply starts out wrong, and I intend to make it progressively more accurate through adversarial review, user testing, and formal verification. It’s already paying off: tests on full NixOS virtual machines caught a bug</a> that, on one version of systemd, hid every login session from Planarian on every machine, and an independent review agent found eight contradictions in a draft of the specification before any of it became code (the resulting fixes</a>). The boundaries of trust and confidence are meant to be legible, both to me and to any possible user.
We live in amazing times, and while this is a new way of building, much of it can still benefit from the application of classic principles in computing and process engineering. I am learning as we go, and I ultimately hope to build something that helps people navigate our future.