Learning as a First-Class System
Everything I build teaches me something, and most of it is gone a week later. So I am going to study that learning as a system, with cybernetics, a game and a small lab.
I write a lot of prompts in a day, and since August I keep every one of them. A small ledger catches each prompt I type in the tools I use most, and writes a digest of the day into my journal. Each one is a small piece of thinking: what I believed about the system, what I asked for, what I tried when the first answer was wrong. And that is where it stops. The prompts are kept and almost nothing learns from them. The thing works, I move on, and what I learned on the way sits in a file I will never read back.
Everything I do requires learning. A fix at work, a chapter of Ashby, a new level in a game, a migration on the blog. If I want to take anything permanent away from all of it, the learning I build as I go is the valuable part, and it does not seem smart to keep treating it as a side effect, kept or not. I think it should be studied for its own sake, as a system, and treated the way second-order cybernetics treats a system that steers itself: recursively, with the one doing the watching inside the thing being watched.
Part of why it slips away is that learning hides once it works. Practicing with my left hand in the notebook, I noticed it about my right: "You forget how hard and how much training it took when you've done it for so long." The skill stays and the learning that built it disappears from view.
So I am building a system to hold it.
The idea
In software, a first-class thing is one the system can hold, name, pass around and reason about. Most of the time learning is not that. It happens, it leaves a trace in my head and maybe a note, and the system I was working in never knew it took place. I once wrote a line about a different part of my life that fits here too: "Knowing isn't a system. Knowing is the easy part. The system is what you build for the moment knowing isn't enough."
Making learning first-class means giving it what any other part of a running system gets: its own state, its own record, its own tests, and a loop that acts on what the record says. Something has to watch what I did and keep it, guess what I know before it asks, and come back later to see whether it held. That is a regulator in Ashby's sense, and the thing it regulates is me learning.
A regulator needs a goal it did not choose for itself. I set the goals, the engine steers toward them, and the goals get looked at again, because a goal that is never questioned turns into a habit.
It also cannot make me learn anything. Maturana's point about living systems is that what happens to them is decided by their own structure: an outside push can only disturb them, and they answer in their own way. So the engine sends questions and invitations, not instructions, and what I take from them is mine. No teacher I have had could put anything in my head either.
The recursive part is what makes it interesting. The regulator is learning too. Its model of me can be wrong, so it has to commit to a prediction before it asks, and the prediction gets scored the way my answer does. The same loop that tests what I know tests what it believes about me. The question underneath all of it:
Can a system that lives inside ordinary work notice what the work teaches, keep it, test whether it lasted, and get better at doing that, including at watching itself?
It happens in conversation
Most of what I learn now, I learn in conversation. This post came out of one, a long exchange with a chat assistant that started as a plan to study Kubernetes and ended in the drawing below. The engine was built in conversations with coding agents. My handwriting gets read by two models and then by me, and the three of us disagree until the page is right. Even the notebook is a conversation. Sitting in the sun with it, I wrote that the exercise itself is "an effort toward true conversation with thinking self."
Listening to a primer on Gordon Pask one Sunday, I caught myself in it:
As I'm listening to the primer on conversation theory aside from finding an audio bug to be fixed (screen captured time) I just had the insight that what would occur in my work with frontier models between my prompt input and the final output which I review as well as the constant dialogue of output by reading and responding to and my stream of consciousness as input based on gut feeling and intuition and as I actively review the work produced and reflect back this all seems very much like Paskian conversation theory where I seek to reach agreement with my cognitive partner. Arguing and agreeing.
That is from Arguing and Agreeing, and it changed how I see this whole project. In Pask's theory, conversation is where understanding is made and where it can be shown: you understand something when you can teach it back. If that is right, the conversations are where the learning is, and they belong in the record. The prompts I keep and never read are evidence going to waste.
Whether a model can take part in a conversation in Pask's full sense is a question I want the system to test, not one I want to assume. Paul Pangaro, who studied with Pask, has given much of his work to designing for conversation, and my reading of it is that a conversation shows itself in what gets agreed and what gets done afterward. Fluent replies are not enough. So the record keeps what was said, what was agreed, and what I did afterward, and lets the later checks decide what the conversation was worth.
I wrote this in the notebook too: "only if recorded and told would you know that some expanse of time has passed." It is the same with learning. Without the record, the change cannot be seen.
The architecture
This is the whole picture, drawn the old way so every word in it can be read and checked.
LEARNING AS A FIRST-CLASS SYSTEM
CYBERNETICS
Feedback · Conversation · Regulation
|
v
+-------------------------------------+
+----->| REAL ACTIVITY |
| | Read · Build · Play · Discuss | +--------------+
| | Conversations, prompts, notes |--->| THE RECORD |
| +------------------+------------------+ | |
| | | evidence |
| | goals I set | kept as it |
| | and revisit | arrived |
| v | |
| +-------------------------------------+ | each entry |
| | COMPLEXENCE ENGINE |<---| names who |
+----->| Model · Predict · Ask · Adapt |--->| observed it |
| | its model of me, open to me | | |
| +------------------+------------------+ | |
| | | |
| | questions, | |
| | invitations | |
| v | |
| +-------------------------------------+ | |
| | TEST IN PRACTICE |--->| |
| | 7HELM · FIDELITRON · a study | | |
| | teach-back · real work | | |
| +-------------------------------------+ | |
| | |
| +-------------------------------------+ | |
| | WHAT CHANGED? |<---| |
| | Understanding · Retention | +--------------+
| | Capability · Effort |
| | checked later, not by the model |
| +------------------+------------------+
| |
+-------------------------+
slow feedback: what lasted, to me and to the engine's rules
fast feedback: each answer, through the record, to the next question
Cybernetics sits on top because it is where the words come from. The work sits at the top of the loop, because the work is where learning happens whether I watch it or not. The goals come down from there too, from me, and get revisited. The record stands to the side and everything passes through it. Observations go in from all of the work, a practice test, a conversation, a book, a session in the engine, each one saying who observed it. The engine reads the record, keeps a model of me, and writes its predictions back into the record before it asks, so they can be scored like my answers. The tests run in the labs, 7helm and Fidelitron, in a study or in real work, and what they show goes into the record too. That is how the game and the engine become one connected model without either reaching into the other. What changed is read from the record later, and not by the model that chose the question. The feedback runs at two speeds: fast, each answer through the record to the next question, and slow, what lasted, back to me and to the engine's own rules.
A few rules hold the shape together. They are the engineering part of how I think about any system I want to trust, checked against the people who first thought hard about systems like this one:
- Observations are the only input. What arrives is kept exactly as it arrived. Everything else, the events, the views, the model, is derived from it and can be thrown away and recomputed. If a view is wrong, the evidence is still there.
- Every observation names its observer. "Anything said is said by an observer," in Maturana's words. A score from a test, my own sense of an answer and the engine's reading of me are three different observers, and the record says which is which.
- A fact and an interpretation never share a field. "I answered it without help" is a fact. "It clicked" is how it felt, and it goes in beside the fact, never instead of it. "The agent understands me" is a claim, made later, with its standing marked.
- A model predicts before it acts. A guess written down first is the only kind that can be wrong in a way anyone can check, the engine's guesses about me included.
- The learner can read the model and argue with it. Pask's test of understanding runs both ways. If the engine's model of me is wrong, I can say so, and saying so is evidence too.
- Nothing grades itself. The part that chose a question never scores it. The check comes later, from the record, by a measure fixed beforehand. Stafford Beer kept an audit channel in his model of an organization for the same reason, and he left a rule I want over the door: the purpose of a system is what it does. If the engine produces streaks instead of learning, then streaks are its purpose, whatever I meant.
- Name the limits. Ashby built his regulators around essential variables, the few things that have to stay within bounds. Here they are effort and my will to keep going; retention is what the whole loop steers, not a limit on it. When a limit breaks, the engine changes the rules that pick the questions, as well as the next question.
- Two loops, two speeds. A fast loop steers the session from what I just did. A slow loop learns from whether it lasted, days later. Wiener wrote about how a feedback loop with a delay in it overshoots and hunts, and learning is all delay, so the fast loop is never allowed to overrule the slow evidence.
- Variety to match. Ashby again: a regulator can only hold its goal if it has at least as many ways to respond as the world has ways to disturb it. Scheduling the next card is one move. Explaining it another way, switching worlds, handing me a real problem, asking me to teach it back, and stopping for the day are others.
- Systems share contracts, never code, apart from one small shared file for random numbers that the game and the engine both use. Each part can be down without breaking another. The engine plays offline with everything else dead; the log takes nothing it was not handed.
- The loops are separate from the content. The math is the engine's; the nouns belong to whatever world I am studying. A new subject is a new world, not new machinery.
- Everything replays. A match or a run can be played back exactly, so a claim about it can be checked by someone who was not there.
- The question comes before the data. Each experiment has a protocol, written down and frozen before the first trial, and a trial that names a protocol the system does not know is refused.
- Private by default. My own study and play stay on my machines. What goes public goes as a deliberate snapshot, and the diff is the record of what was shared.
What runs today
The engine
The Complexence engine is built, it runs today on my own machines, and I use it. It is one engine with several worlds, each world a subject I am studying turned into a place to play.
Inside it, a stack of small loops does the regulating. One senses every answer. One judges how warm or cold each area of a subject is. One steers what the next session should be. Others handle difficulty, coverage across days, and how what I knew fades if I leave it alone. Mastery is a set of boxes that cards climb and fall through, so a card I keep missing comes back more often.
An early version of it carried me through a certification this summer, on paper as much as on screen, alongside practice tests and long conversations with a model about what to study next. It worked, and I cannot tell you which part did the work. That is the itch the rest of this is built to scratch, and it is why observations from outside the engine count as much as the ones from inside it.
The lab
The engine runs as a container on a small Kubernetes cluster on the laptop that is always on, reached only over my private network. Beside it sits a ledger, the one writer of the learning log. The engine hands it the whole of my learning state every few minutes; the ledger keeps the evidence once, derives events from it in one shared shape, and computes its views when they are asked for, never storing them. A send that fails is healed by the next one, because each send is complete. One of the views puts every idea on the cybernetics map beside my practice on it, which is close to what Pask drew as the structure of a subject: the topics and how each one leans on the others.
The watchers
The loops around it report a heartbeat when they run, and a missed one reaches my phone; the rest join as they are built. It is the plainest version of the alarm Beer wanted in every viable system, the signal that skips every layer and goes straight to the person who can act. This month taught me why: a loop that fails quietly into a log file is no loop at all, which I wrote up in the thirty-day update on the loop essay.
7helm
7helm is a game I built, live on the web, and a match in it is its setup plus every intent each player sent, so it replays exactly without the players present. That makes it a laboratory for behavior: a small world with rules I wrote, where understanding can be watched forming or failing. The agents that will play in it, acting only through intents so their play replays the same way and carrying what they predicted beside the replay, are designed and not built yet.
Fidelitron
Fidelitron is the other lab, for engineering questions: the smallest world that still tells the truth, run against the real thing when it can be. Its first experiments took apart Kubernetes reconciliation loops.
What comes next
Not all of the drawing is built yet. Today the engine steers from its own saved state and hands the record a copy, and that copy is the only thing the record receives: practice tests, books, the labs and my conversations, which sit in their own ledger, never reach it. The engine does not yet write down a prediction before it asks, it does not yet show me its model of me, and its loops all run at one speed; nothing comes back days later to check whether what I learned held. The protocols are written, but nothing yet takes in a trial and refuses one that names the wrong protocol. Teach-back is an experiment on paper. And the model of me waits until the record has a couple of weeks in it worth modelling. Those are the first things to build, because each one closes a gap between the picture and the parts.
Then I plan to deploy the engine the way 7helm is deployed, for research, and connect the two. 7helm becomes a place where experiments can be run, watched and joined, working directly with the learning engine as one connected model: what happens in the game feeds the engine, and what the engine asks shapes the game.
What I want to measure
How I learn, how fast, how well, and how it feels. The feeling counts. Some of what I am after is the work getting lighter as an idea settles, the load easing, and I want that on the record beside everything else, marked as what it is: one observer's report, and a noisy one.
The harder measure comes later. An explanation that finally clicked today is a good sign and nothing more. The test is a new problem, days later, that I solve without help. If it lasts and carries over to something new, I learned it. Streaks do not count.
Why a game
My first pass at all of this was a study plan for Kubernetes, and it bored me. What I wanted was something Pask and Wiener would have enjoyed, so I turned to 7helm.
The early cyberneticians built machines to show behavior rather than describe it: Grey Walter's tortoises wandering toward the light, Ashby's homeostat settling itself, Pask's Colloquy of Mobiles talking among themselves. A game is the nearest thing I have to that.
The first experiments are small on purpose. An opponent that tries to predict what I will do, and has to say so before it acts, so its guess can be checked against the replay and it can be wrong in a way I can see. Later, two agents that have to invent a way to signal each other with nothing agreed in advance, and then one of them leaves and I take its place. Whether I can understand it, and teach it back, is Pask's test of understanding.
Watching the watcher
On a warm October afternoon I wrote in the notebook observe the observer, place the system itself onto the system. Months earlier it came out shorter: "Being and creating in the present moment both actor and observer" (Writer Forgets the Writing). That is my place in this. I am the designer, the participant and the one reading the results, and the protocols written ahead of time guard against that some, and only some.
The engine is an observer too. If it asks me about something, I study it, and its prediction about me comes true partly because it made it. In the first experiments that is something to control for. In the later ones it is the subject. It is true of this post as well: writing the question down has already changed what I will notice.
Where it goes
None of this has shown yet that it improves how anyone learns, including me. I am participant one, and will be for a while. The questions and the method can be public; my own study and play stay mine. 7helm stays an experiment rather than a business, and right now hardly anyone knows it is there, which suits the beginning. Someday I would like to open the engine so others can take part, once I have shown myself something worth sharing.
It is a lot when I look at all of it at once, the conversations, the worlds, the labs, the loops watching the loops. It is also the most exciting thing I have worked on, and it starts small: the prompts I already keep start feeding the record instead of sitting in a file.
I am learning cybernetics as I build this, and much of it is new ground for me. If you study learning, or cybernetics, or adaptive systems, or you build systems like this one, I would like to hear from you, especially if you see an assumption here that is wrong or know earlier work I should read. Write to me at hello@joshuaayson.com.
Related reading: Complexence, the idea this loop belongs to. A Loop Is a Path That Closes, on why a decision and what came of it are worth writing down. Germane Friction, the effort that builds you and the effort that only taxes you. Level Up the Game, on keeping what a hard session teaches. What 7helm Is Made Of, the game the lab grows out of.