Showing posts with label system. Show all posts
Showing posts with label system. Show all posts

The curious life of a clever slime mold

Mike's Notes

Slime Moulds are one cell, yet perform tricks of memory. From Knowable Magazine.

This example from nature is one of the many reasons why Pipi is modelled on how biological cells work.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Knowable Magazine
  • Home > Handbook > 

Last Updated

10/09/2026

The curious life of a clever slime mold

By: Tim Vernimmen
Knowable Magazine: 11/02/2026

Tim Vernimmen: Tim Vernimmen is a freelance science writer based near Antwerp, Belgium. For this article, he was hoping to interview Physarum itself, but scientists are still working out how to do that.

...

In its quest to feed, avoid nasty substances and just generally live its life, the brainless, one-celled Physarum polycephalum performs some impressive tricks of learning and memory

...

Sixteen years ago, a brainless, unicellular organism blew our human minds. And it continues to fascinate and surprise researchers to this day.

Scientists had known that some slime molds of the species Physarum polycephalum consist of one giant, pulsating cell that keeps changing shape as it moves around and branches out to access food and avoid unpleasant things like salt or light. But it took a 2010 experiment led by Japanese biologist Toshiyuki Nakagaki of Hokkaido University to reveal the depths of its sophistication. When Nakagaki placed the oat flakes that Physarum likes in a pattern mimicking the cities surrounding Tokyo, the slime mold’s branches almost exactly reproduced the efficient transport connections between them that humans had taken years to develop.

From the center of a petri dish, the slime mold Physarum polycephalum extends branches to find food in this time-lapse video.

CREDIT: © DUSSUTOUR / CNRS

To Karen Alim, a theoretical physicist starting a postdoctoral project at Harvard University at the time, that study was a revelation. “I was like, ‘Wow, this is so crazy.’ A single cell that solves complex tasks appealed very much to me as a physicist.” Perhaps, Alim thought, she could apply her training to make sense of this clever creature with its network of contractile tubes and constantly pulsating currents.

So Alim and colleagues grew Physarum on a jelly-like substance called agar and carefully watched and recorded its behavior under the microscope. They measured the strength and direction of the fluid flow in its network of tubes. Then they simulated what they’d seen in mathematical models.

The result? Through studies like this, as Alim recounts in the Annual Review of Condensed Matter Physics, she has become convinced that the flow of fluid can be a way of transmitting information, and she’s working to understand the underlying mechanisms. Other researchers, meanwhile, are continuing to uncover new, intriguing behaviors in Physarum, a creature that appears able to learn, remember and make decisions — all without a brain.

Photograph of Karen Alim holding up a petri dish on which a slime mold is growing.

Researcher Karen Alim (right) and her colleagues grow Physarum polycephalum in petri dishes containing a nutrient-rich agar medium.

CREDIT: STEFAN WOIDIG / TUM

The flow of memory

Though Physarum is a single cell, the large body it forms can often be easily seen by the naked eye, growing to more than a foot in diameter under favorable conditions. It looks like a central blob from which a network of vein-like tubes emanates — larger tubes, then smaller tubes that fan out from them. Inside those tubes, cytoplasmic fluid is rhythmically flowing back and forth, supplying all parts of the cell with what they need. In nature, the slime mold is found in damp, dark spots like forest floors and decaying logs.

Many of the studies revealing Physarum’s unexpected skills revolve around its most important concern: finding food. Whenever Physarum encounters something edible, the outer wall of tubes near the food become soft. As a result — due to the pressure of the constantly moving fluid inside its tubes — that part of the body spreads out like a fan. This fan then slowly morphs into a network of even tinier tubes. Under the microscope, this looks like a river delta network of yellow slime feeding into the larger tubes of Physarum’s body.

How does it happen? Alim, who now works at the Technical University of Munich in Germany, figured out that encounters with food lead to an increase in local fluid flow within the tubes. This exerts greater shear force on the tube walls. The walls in that region grow thinner, allowing the tubes to expand.

Inside the slime mold Physarum polycephalum’s branching, pulsating body, currents of fluid flow back and forth to transport food and other molecules. These currents are key to the organism’s ability to move, change its shape and learn.

CREDIT: DELESCLUSE & DUSSUTOUR / CNRS

The opposite happens when Physarum encounters something awful like salt or light that it wants to get away from. In response to a repellent, the tube walls stiffen and contract, which redirects fluid flow elsewhere.

In sum, researchers now understand that where the flow is stronger, the tubes expand, and where the flow is weaker, they shrink. This interplay of shrinking and expansion in different areas of the body is what reorganizes the shape of Physarum’s tube network, causing it to approach food and avoid things like salt.

More recently, Alim and colleagues discovered just what creates a tube network as efficient as Tokyo’s transport links. It ties into something crucial about the fluid flow in Physarum’s body: Tube walls respond to changes in flow with some delay. First the flow increases. Then, slightly later, the tube expands in response, causing the flow to decrease. This causes the tube to shrink, again with some delay.

The result, Alim found, is that the best-positioned tubes will grow larger and larger and receive more and more flow, while others will fade away — and hence, over time, a super-efficient network of links will form.

Put another way, Alim adds, you could say that the shape of the network (and its underlying fluid flow dynamics) helps Physarum to remember. Appropriately sizing its branches in accordance with food sources it has encountered recently makes for a simple but effective way to recall where food can be found.

Recent work in Alim’s lab suggests it’s not just the shape of the network that helps Physarum remember, but also how, when and where it contracts the walls of its branches. For example, she says, putting food in a certain location leads the slime mold to respond with a certain pattern of contractions and move toward the food. Between experiments, the contraction pattern diminishes, but if food is put in the same spot, it reappears, more quickly than before. In one experiment, a persistent wave of contractions caused a slime mold to keep crawling in one direction for hours to get away from a light source, long after the light had been switched off, which suggests it still remembered it.

Like all of us, Physarum polycephalum has its food preferences, as this time-lapse video shows.

CREDIT: © DUSSUTOUR / CNRS

Salt and slime

The finding is reminiscent of a study by Audrey Dussutour, a biologist working on the same species, now at the National Centre for Scientific Research in France. In 2019, Dussutour had reported something interesting: After a few attempts, Physarum took less time to cross a nasty salty patch inside its dish while moving toward a food source — implying some kind of learning. The effect remained even after the slime mold had spent time in the dormant state it adopts under stressful conditions.

Since the slime mold absorbed and retained some salt, it’s possible that this lowered the shock of encountering it again and allowed it to move faster, says Dussutour. So in a recent experiment, as yet unpublished, she used light as the repellent instead. Physarum still shaved down its travel time with repeated exposures, even though light isn’t retained the same way salt is. Dussutour suspects that contraction patterns may persist and store information “similar to the way waves of activity in our brain can store information,” she says.

In addition to the information stored in the layout and contractions of its tubes, says Dussutour, Physarum has another way to “remember”: the trail of slime it leaves wherever it goes. “Avoiding slime is a convenient way to make sure it’s exploring new places rather than retracing its own trail,” she says.

In the wild, Physarum polycephalum is often found on dead plant material, as shown in this time-lapse video.

CREDIT: © DUSSUTOUR / CNRS

Dussutour was also able to show that slime molds can learn about each other: They are sensitive to aspects of each other’s behavior. “They will approach others that have access to food, and avoid ones that are starving or stressed,” she says. “Remarkably, they also prefer to approach young individuals.”

Older slime molds become very slow and fragile, she adds. “We have some in the lab that are now 5½ years old…. We hardly dare to use them anymore. But intriguingly, when they go through dormancy, or fuse with a younger individual, it’s as if they’re young again.”

For a better understanding of the slime molds’ mysterious ways, it would be very helpful to find out what exactly they’re up to in the wild, says behavioral ecologist Tanya Latty of the University of Sydney. “Almost everything we know about their behavior is based on experiments done in a lab,” she says — experiments that focus on the large, multi-nucleus forms of the creatures, not the single-nucleus, microscopic amoeba state in which they spend most of their lives.

So Latty’s research group has been collecting wild slime molds to investigate. “They’re often found on rotting logs, but we’ve also found them in the leaf litter just in front of our building. People have also found them on house plants. They’re everywhere,” she says.

Latty suspects that the large form, with its various ways of learning, allows Physarum to consume a lot more food in preparation for making the spores it needs to spread. Physarum may be far less clever in its microscopic form, she adds, if its surprising behavior really depends on its ability to branch and contract its tubes. “But who knows? We didn’t think they were capable of anything when we started to study them.”

10.1146/knowable-021126-1

Jessica Kerr on Symmathesy

Mike's Notes

I was watching "A Learning System Made of Learning Parts" on Still Burning, an episode of Kent Beck's video blog.

Jessica Kerr joins Kent by the fire to argue that AI didn't take the programmer's job; it split it in two. The part we loved, crafting code by hand, has been commoditised like IKEA furniture. What's left is harder and more human: understanding what to build, proving it works, and stewarding the living "symmathesy" of people, code, and agents all learning from each other. They get into accelerated learning, why play is a signal you're learning, the loop that "becomes a noose," and choosing excitement over fear while the ground keeps shifting."

Resources

References

  • Symmathesy — A Word in Progress Proposing a New Word that Refers to Living Systems. Nora Bateson. Nora Bateson Foundation

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Still Burning
  • Home > Ajabbi Research > Library > Authors > Kent Beck
  • Home > Handbook > 

Last Updated

02/08/2026

Jessica Kerr on Symmathesy

By: Jessica Kerr
Jessitron: 15/04/2018

Jessica Kerr manages the Developer Relations team at honeycomb.io, because observability is one way our teams learn from our software. In speaking and teaching, Jess works across languages and communities, spreading cheerful deep thoughts. Code, tools, and people are not separable; all form the team that operates useful software.

Symmathesy is a term coined by filmmaker and systems theorist Nora Bateson in 2015 to describe a learning system made of learning parts, emphasising mutual learning that occurs within and between living contexts. Derived from the Greek roots sym (together) and mathesi (to learn), it serves as a response to mechanical, rigid frameworks by shifting the focus from individual elements to the dynamic relationships that generate evolution and adaptation.

In a symmathesy, learning is not an isolated process of acquiring information; it is an ongoing, multi-contextual process of mutual adjustment and calibration.

Collective problem solving in music, art, science, and software

A Learning System Made of Learning Parts

How function diversity scales, from cells to companies

Mike's Notes

Fascinating work. Something to test Pipi against using long-cycle simulations.

Resources

References

  • Scaling laws for function diversity and specialization across socioeconomic and biological complex systems. Authors: Vicky Chuqiao Yang, James Holehouse, Hyejin Youn, José Ignacio Arroyo, Sidney Redner, Geoffrey B. West, and Christopher P. Kempes. PNAS (February 12, 2025). DOI: 10.1073/pnas.2509729123

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Parallax
  • Home > Handbook > 

Last Updated

04/05/2026

How function diversity scales, from cells to companies

By: Santa Fe Institute
Parallax: 18/02/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

A mystery novel, a history book, and a fantasy epic may have little in common in plot or style. But count the words inside them and a strange regularity appears: many new words show up early, then fewer and fewer as the author reuses what has already been introduced.

That pattern, known as Heaps’ law, turns out not to belong to books alone. A new study in PNAS finds that the same rule also describes the growth patterns in many complex systems, from living cells and corporations to universities and government agencies — and could even be used to predict how they will change in the future.

The study, led by scientists at the Santa Fe Institute and MIT, doesn’t just document this regularity; it introduces a mathematical model that quantifies how different systems diversify and specialize. It finds that, while systems vary in how much they invest in creating entirely new functions, once those functions exist, their subsequent growth follows a remarkably universal rich-get-richer process.

“What’s striking is that these systems weren’t designed to follow the same rules,” says SFI Program Postdoctoral Fellow James Holehouse, who co-led the study with Vicky Chuqiao Yang, a former SFI Omidyar Fellow now at MIT. “Yet when you look at how they grow, you see the same trade-off between adding something new and building on what already exists.”

“It is remarkable that cells, bureaucracies, and companies, despite obvious differences, all grow their function repertoire with a similar pattern.”

In the study, researchers focus on what they call “distinct functions” — the different kinds of work a system performs. In a cell, that might mean different proteins. In an organization, it could mean different kinds of jobs. As systems grow, they do add new kinds of work, but they do so more and more slowly over time.

Using their model, the team analyzed dozens of bacterial and microbial cells, more than a hundred U.S. federal agencies, thousands of companies and universities, and hundreds of metropolitan areas. Across most of these cases, the same pattern appeared: as systems got bigger, the pace at which they added new functions steadily slowed, growing sublinearly.

In practical terms, sublinear growth means that doubling the size of a system does not double the number of functions inside it. Instead, growth increasingly comes from expanding what already exists. A growing organization hires more people into established jobs before creating new titles. A cell produces more of the proteins it already uses instead of evolving entirely new ones.

“It is remarkable that cells, bureaucracies, and companies, despite obvious differences, all grow their function repertoire with a similar pattern,” says Yang, an assistant professor at MIT Sloan and the Institute for Data, Systems, and Society. “This suggests that the regularity discovered in Heaps’ law applies not only to what humans create, like books, but also to human organizations themselves.”

Cities, however, follow a different version of the same trend. They still add new kinds of jobs as they grow, but they do so much more slowly, following a logarithmic pattern rather than the power-law pattern seen in other systems. Even as populations soar, genuinely new job types become increasingly rare.

That difference reflects a deeper structural divide. Cells, firms, and agencies behave like organisms, with clear boundaries and unified goals. Cities, by contrast, resemble ecosystems shaped by the independent choices of individuals rather than centralized control.

Geoffrey West, a co-author and Santa Fe Institute Shannan Distinguished Professor, adds, “There are underlying regularities shaping how complexity builds, even in systems that look completely different on the surface.”

This material is based upon work supported by the U.S. National Science Foundation under Award No. 2526746

The Neural Harness: The new CPU

Mike's Notes

Some deep insights here from Will Schneck. Asking more questions than he answers. Especially deterministic vs probabilistic. Where does emergence emerge? 😎😎

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > The Focus AI
  • Home > Handbook > 

Last Updated

03/05/2026

The Neural Harness: The new CPU

By: Will Schenk
The Focus AI: 01/05/2026

I am a father, entrepreneur, technologist and aspiring woodsman.

My wife Ksenia and I live in the woods of Northwest Connecticut with our four boys and one baby girl. I have a lumber mill and all the kids love using the tractor.

I’m currently building The Focus AI, Umwelten, and Cornwall Market.

"Coding agents will build their own tools and their own agents. Agents will be used by non-engineers to manage other agents to manage parts of the org chart."


I'm on my second Claude Max plan. That's in addition to Cursor, Codex, Gemini, and a healthy Amp habit. Not to mention a Jetson AGX Thor I'm about to plug in at the office — more on that one later.

Overnight jobs parsing financial deal structures, ops stuff, research, monitoring logs, responding to events, all the little background things. The first plan tapped out, I added another, that one tapped out too, and now I'm provisioning a third the way you'd add a build runner. Mundane.

A new entry in an old list

Look at the paragraph I just wrote. Overnight jobs parsing financial deal structures, ops stuff, research, monitoring logs, responding to events. Half of those words are themselves names of native units of computing. Logs — log aggregators. Events — event streams. Research — search indexes. Ops — schedulers, orchestrators, deployment systems. Jobs — queues. The lede is already a list of older units I'm wiring into.

Computing has been accreting native units forever, and the way you build the next layer is by composing the units underneath it.

You combine adders and accumulators to make a CPU. You combine CPUs and memory and a bus to make a machine. You combine logic gates and clocks to make registers. You combine Boolean functions and a process model to make an operating system. You combine lexers and parsers and code generators to make a compiler. You combine source files and a compiler to make a program. You combine programs and a network stack to make a service. You combine services and a database to make an application. You combine applications and a queue to make a pipeline. You combine pipelines and a stream processor to make a real-time system. You combine streams and a log aggregator to make observability. You combine logs and a metric and an anomaly model to make a monitor. You combine all of it and a scheduler and you have a system that runs without you watching it.

Flat-color treemap of the computing stack: small blocks for adders, clocks, registers, cpu, memory, bus growing diagonally up and to the right through machine, os, compiler, program, service, application, pipeline, stream, observability, monitor — culminating in a large block for scheduler.

Each layer is just the layer below, composed. That's what a native unit is — the thing you stop writing yourself, the thing you wire to. You don't write a compiler. You don't write a Postgres. You don't write a Kafka or a Kubernetes or a Lucene or a git. You pick the unit, you combine it with other units, you build on top.

Now look at that list again. Everything on it is sitting on top of Boolean logic. Silicon, gates, arithmetic, state machines, if/then. Numbers, types, queries, schedules, indexes — all of it is deterministic logic resolving down to ones and zeros. You can climb that stack pretty high, but you don't get out of it.

19th-century geological cross-section: layered strata of fossilized circuit traces — gates, clocks, registers, CPU, OS, compiler, program, service, application — opening into a newly excavated neural floor below, soft coral and cream tones, neuron tendrils threading up into the rock. The new floor under the old stack.

Neural nets aren't more of that. They're a different kind of logic. Pattern, association, similarity, fuzzy matching, generation. The thing silicon-and-Boolean was bad at, that we kept failing to solve with cleverer rules, the neural net does natively. We added a new floor — GPUs, TPUs, the Cerebras inference fabric, the Jetson on my desk — and a new kind of computation running on it that doesn't reduce to if A and B then C.

By themselves these things predict tokens. They don't loop, they don't read files, they don't remember. To get computation out of one you wrap it. A loop, some tools, file access, a shell, a way to manage context. That wrapper is the harness. The harness is the unit that turns "predicts the next token" into "does the work" — and lets the new kind of logic compose with the old kind.

The neural harness is to neural nets what the compiler was to source code. New entry on the list, joining the family rather than replacing it. The work I'm running on these two-going-on-three Max plans is mostly the harness wiring into the older units — tailing logs, querying state, watching streams, kicking off jobs, hitting indexes. New unit, old units, composed.

That's why the second Max plan isn't weird. The bill scales with how much work you're doing in the new unit. I'm doing a lot of work in the new unit.

How it shows up in a day

It really has stopped being a tool I reach for; its just the tool.

When I'm coding, I'm in a harness. When I'm reading a PDF I needed to read anyway, the harness is the thing reading it. Operations folder — SOWs, invoices, content ideas, project status — that's a harness. Parsing 20 financial deal docs and writing me a summary while I sleep — harness. Family infographics, fasting tracker, oura ring trends — harness, harness, harness. Different work, same unit.

Small-multiples grid: the same harness icon repeated across sixteen everyday domains — code editor, PDF reading, invoice, SOW draft, content ideas, project status, financial deal, overnight job, log monitor, email triage, family infographic, fasting tracker, Oura trends, calendar, research note, ops dashboard. One unit, many domains.

Coding was just the first place this paid off, because the feedback loop is tightest. Compile or don't, test or don't, the world tells you you're wrong inside a second. So that's where the harness got tuned first. That's why the unit is called a "coding agent" right now. But "coding" is vestigial. The thing isn't a coding agent. It's a harness around a model, and what runs in it is whatever you have tools for.

Rick Blalock said it in AI Engineering Miami — coding agent as universal software primitive. A 60-year-old in Texas replaced a $10k/month HubSpot bill by pointing one of these at the problem for three months. A 24-year-old window cleaner in Florida runs marketing, sales, and estimating off the same primitive. Both of them bought MacMinis. Tim Cook didn't have that on his bingo card.

The model question is below the harness question

Here's something I noticed about my own behavior: I'm mainly on Claude. Have been for months. I dip in and out of GPT and Grok and Gemini, but just sort of end up back here. Not because I reasoned out a model strategy — because Claude Code defaults to it and now I'm on Opus all day every day. Amp has its opinion and I try to set Cursor to super max mode, but really the model picked itself by way of the harness picking it for me.

So the perennial "Opus vs GPT-5 vs Gemini 3" argument is pitched one floor below where the action is. It's not model-vs-model. It's harness-with-default-model vs other-harness-with-default-model. The harness drives the model choice, often without telling you.

And underneath that, there's a whole zoo. Frontier reasoning models. Cheap fast models. Code-specific fine-tunes. Local models that run on the GPU you already own. Cerebras-fast inference at 1,200 tokens/sec, a different regime entirely. And the inside-the-harness thing: Tejas Bhakta at Miami called it "everything is models" — a compaction model running every two seconds, a code-search model at 80k tokens/sec, a frontier model doing only the heavy reasoning, all stitched together. Software 3.5, he called it. The harness picks all of that for you, or doesn't, depending on which harness.

Da Vinci anatomical-plate: a single mechanical harness apparatus on top labeled HARNESSIS — UNITAS SUPERIOR with four tool-attachments (LEGERE, SCRIBERE, IMPERARE, ITERARE), and below it a labeled menagerie of seven model 'species' — Frontier, Velox, Codicis, Localis, Compactionis, Quaerens, Cerebras — drawn as small mechanical creatures on aged parchment.

Which means the harness is a model strategy. Picking a harness on purpose means picking which models do which jobs inside it.

So which harness?

A separate post coming soon — each one deserves its own treatment and the conversation moves week to week. The shape of it:

You can build your own in a weekend. About 50 lines gets you the loop. Highly recommend, even if you never use it. Claude Code is the one everyone uses, and — by Anthropic's own model on Anthropic's own benchmark — the worst Claude harness on offer. (Niels Rogge posted Terminal-Bench 2: same Opus 4.6, Claude Code last, ForgeCode and Capy at 70-75%. Twenty-five points of accuracy from picking a different harness.) Picode is Mario Zechner's minimal, self-modifying one — four tools, the agent writes its own extensions, hot-reloads in the session. The most fun one to play with right now. Amp is the one I'm most fascinated with — though to be clear, I'm editing this post in Cursor. The multimodel thing actually works now. In January I wrote that Amp "should be better, but, you know, isn't." Four months later: it is.

Tufte-style horizontal bar chart of Terminal-Bench 2 scores on the same Opus 4.6: ForgeCode 74%, Capy 71%, Picode 62%, Amp 55%, Claude Code 49% — outlined in vermilion. Annotation on the right: 25-point gap from picking a different harness.

The point of this post is the unit, not the catalog.

What I'm still circling

Da Vinci notebook spread with marginalia: a Jetson AGX Thor on a small workbench labeled MACHINA LOCALIS, a brass token-cost gauge labeled STIPENDIUM TOKEN — quanto?, a half-configured harness with question marks labeled HARNESSIS CONFIGURATA — UNITAS NAVIS?, and a small chart of a rising line labeled LINEA NOVA IN STATU FINANCIALI. Sepia ink on parchment, inkwell and quill in the corner.

What's the unit of shipping? Ben Davis's claim in Miami was that it's becoming a directory of skill files plus a coding-agent runtime. That feels right. But the runtime is also moving — picode's bet is that it should be malleable inside the session, so you can't pin it. Maybe the unit is even smaller. Maybe the unit is the harness, configured.

What about the Jetson on my desk. The other thing the bill is about to teach us is that some of this work shouldn't be paying a subscription at all. Local models on local hardware — gpt-oss, Qwen, MiniMax, whatever's frontier-enough for the job — running on the GPU you already own, or the Jetson, or the laptop. Cheap as electricity. No data leaving the building. The harness doesn't care which model it's calling. The bill cares a lot. I think a real chunk of what's running on the second Max plan ends up local by the end of the year.

When the bill becomes a real line item — and it will — what does that conversation sound like? "Cloud spend" took ten years to become its own column on the financial statement. "Token spend" might take less. We're paying for a unit of computation, not for software. Different shape entirely.

I'll get the third Max plan tomorrow. There's another job.

20 Engines

Mike's Notes

While I finish off testing the Pipi System Engine (sys), here is the plan for the next stage.

Update 27/04/2026

Today, I have also been setting up some new twin 27" monitors to help with coding. I need larger 16pt Arial or Noto Sans font sizes these days.😎 Hopefully, better visuals will mean I will not get so tired.

Update 03/05/2026

The list has been pruned to 18 engines now, not 20.

Update 23/05/2026

Two more engines were added to the list, bringing the total back to 20.

Update 27/05/2026

Nest Engine (nst)  renamed as Nestspace Engine (nst)

Update 17/06/2026

DevOps Engine (dvp) added, bringing the total to 21. The order has also been changed. Going very well. This fix alone will speed up development 10x.😎

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

17/06/2026

20 21 Engines

By: Mike Peters
On a Sandy Beach: 26/04/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Project

The project is to import the 18 20 engines necessary for Pipi to run in deterministic mode, and self-manage with a minimal set of internal features, no adaptation or self-evolution. That will come later, when many more engines are imported, contained inside other engines, and probabilistic behaviour begins.

Variables

All of these engines have worked for years (some with origins dating back 26 years) and are mature and stable, but have been migrated from a laptop to a data centre, where the host environment differs. I forgot to sort that out first. 😎 The Nestspace Engine (nst) was rapidly invented to solve that problem, but the variables generated by the Nestspace are also causing name clashes.

Process

Each engine needs the same minor tweak upon import. I'm also carefully checking all spelling in each engine. Completing descriptions for future self-documentation.

Logs

Each engine is then left running while I watch the logs. Once the log engine is imported, logs can be visualised in Mission Control using third-party open-source tools. This will speed things up a lot. Eventually, the logs will feed feedback loops as this beast scales.

System Engine (sys)

The System Engine (sys), on its own, is like the empty skin of an elephant, to be stuffed and used in a museum exhibit. It looks like an elephant, but it is not alive.

The System Engine has intrinsic properties. It is designed to contain all other engines. As the engines are added and interact, the System Engine will come to life.

It's the whole that is greater (George Ellis) or lesser (Terrence Deacon) than the sum of the parts.

21 Engine import list

In this order.

  1. System Engine (sys)
  2. Nestspace Engine (nst)
  3. JVM Engine (jvm)
  4. CGI Engine (cgi)
  5. Namespace Engine (nsp)
  6. Data Engine (dta)
  7. Code Engine (cde)
  8. Variables Engine (var)
  9. Versioning Engine (ver)
  10. DevOps Engine (dvp)
  11. Render Engine (rnd)
  12. Template Engine (tem)
  13. Log Engine (log)
  14. Configuration Engine (cnf)
  15. Conductor Engine (cnd)
  16. Directory Engine (dir)
  17. Node Engine (nde)
  18. CMS Engine (cms)
  19. Core Engine (cor)
  20. Factory Engine (fac)
  21. Page Engine (pge)

Pipi is the IDE

I built Pipi using Pipi, so I'm stuck in chicken-and-egg land at the moment. The more engines are imported, the easier this will get. I have a rough idea of the import order, and luckily, I can use Synethesia to run simulations, which are usually very fast and accurate. After all, it's how I build everything.

Pipi Editions

Each engine is like a different kind of Lego brick, and each Pipi is built out of hundreds of these bricks. The 4 Editions are built with the same bricks, combined in different ways. The Instances of any Edition are built exactly the same way, but their databases, with the same data models, will store different histories, weights, parameters, etc., as they adapt and evolve.

DevOps Engine (dvp)

The DevOps log below is currently maintained manually, but will be generated automatically once the DevOps Engine (dvp) is back up and running. These logs will be automatically published on the Ajabbi Developer website using an interactive format with more detail.


DevOps log (edit)

A record of work done.

NZ DateTime Action Engine Status
2026-05-07 20:01 Edit 18 engines - short and long descriptions. Complete





Test System Engine (sys)





Create Nestspace Engine (nst) - Code for Linux vs Windows path delimiters.

Test Nestspace Engine (nst)




21/05/2026 12:35 Create JVM Engine (jvm) Completed

Edit JVM Engine (jvm) - configuration
21/05/2026 09:12 Edit JVM Engine (jvm) - variables Completed

Edit JVM Engine (jvm) - spelling

Test JVM Engine (jvm)




22/05/2027 11:17 Import CGI Engine (cgi) Completed
22/05/2026 18:46 Edit CGI Engine (cgi) - variables Completed

Test CGI Engine (cgi) - spelling

Test CGI Engine (cgi)





Test System Engine (sys)





Test Namespace Engine (nsp)





Test System Engine (sys)





Import Render Engine (rnd)

Edit Render Engine (rnd) - variables.

Edit Render Engine (rnd) - spelling.

Test Render Engine (rnd)





Test Render Engine (rnd) - run Nest Engine (nst) templates to create a nest.





Test System Engine (sys)





Import Template Engine (tem)

Edit Template Engine (tem) - variables.

Edit Template Engine (tem) - spelling.

Test Template Engine (tem)





Import Template Engine (tem) - import temporary nest templates





Test System Engine (sys)





Test Render Engine (nst) + Template Engine (tem) + Nest Engine (nst)





Test System Engine (sys)





Import Variables Engine (var)

Edit Variables Engine (var) - variables.

Edit Variables Engine (var) - spelling.

Test Variables Engine (var)





Test System Engine (sys)





Create Variables Engine (var) - quick & dirty CRUD editor.





Create Temporary web form UI for each engine

Test Temporary web form UI for each engine





Import Log Engine (log)

Edit Log Engine (log) - variables.

Edit Log Engine (log) - spelling.

Test Log Engine (log) - CRUD log file formats

Render Log Engine (log) - logs





Import Graphing library for logs

Create Embed visualisations on Mission Control web pages.





Test System Engine (sys)





Import Data Engine (dta)

Edit Data Engine (dta) - variables.

Edit Data Engine (dta) - spelling.

Test Data Engine (dta)





Test System Engine (sys)





Import Configuration Engine (cnf)

Edit Configuration Engine (cnf) - variables.

Edit Configuration Engine (cnf) - spelling.

Test Configuration Engine (cnf)





Test System Engine (sys)





Import Versioning Engine (ver)

Edit Versioning Engine (ver) - variables.

Edit Versioning Engine (ver) - spelling.

Test Versioning Engine (ver) - automatic versioning.

Render Versioning Engine (ver) - version logs





Test System Engine (sys)




























Testing the Pipi System Engine (sys)

Mike's Notes

The next long batch of work starts today. I'm working this out as I go, and I don't yet know how long this will take. The plan will likely change. I hope the start will be the hardest part, and then it will get easier. But I have been wrong before. 😎😎😎😎😎😎😎

Dwight D. Eisenhower’s philosophy on planning is best summarized by his famous quote,

"Plans are worthless, but planning is everything".

He emphasized that while rigid, written plans fail upon first contact with reality (or the enemy), the process of planning prepares leaders to adapt, coordinate, and react intelligently to unexpected emergencies. - Wikipedia

Big picture

I want to double-check everything as I go and complete or archive any unfinished work without doing upgrades.

Mrs Grammarly

And fix all my spelling mistakes. Some of this was built years before I had Mrs Grammarly and is only now being discovered. A lot of spelling mistakes. Oh dear!. 😎😎

Mrs. Grammarly's Last Request

Noisy, noisier, noisiest
Our teacher's last request
Before she took the plane
To somewhere warm in Spain
Because her nerves were broken
By words so loudly spoken
For twenty-five years without
A respite, there's no doubt
Just remember this rule please
She said with great unease
Drop the y and add an i
When comparing things whereby
You'll cheer this poor old teacher
And peace will finally reach her.
- Old Faithful

Speed is king

Go as fast as hell. Trust Pipi's ability to self-repair.

Update 22/04/2026

Again, as with the recent Pipi Nest update, progress is painfully slow but steady. I now strongly suspect that the changes I need to make to System Engine (sys) will apply to all engines. Once the necessary solution is found, every engine will be easily altered. So very slow at the beginning, then very fast.

Update 23/04/2026

Its definitly a problem with named variable clashes and variable scopes. Now I know what to fix.

Update 29/04/2026

I'm having a break while the mental simulations run.

Update 19/05/2026

Now I know exactly how to fix it. The variable scopes have boundaries, with translation between them. The Nest revisions will also enable auto-installs on VMs, Docker, Windows, and Linux servers. Variable naming is now 100% predictable and can be automated.

Update 27/05/2025

Nest Engine (nst) renamed as Nestspace Engine (nst)

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

27/05/2026

Testing the Pipi System Engine (sys)

By: Mike Peters
On a Sandy Beach: 21/04/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Anatomy 101

The Pipi System Engine (sys) is like the whole (hence the name "loki"). It has an outer boundary and is built from hundreds of other kinds of engines nested up to 27 layers deep. There can be many copies of each engine type. There are also hundreds more engines waiting to be imported from the Pipi 6, 7, and 8 archives.

Engine-Agent Duality

Every engine is also an autonomous agent.

  • Engines are deterministic
    • Stateful
    • Imprinted by the path taken
    • Formal Logic
  • Agents are probabilistic
    • No AI tokens
    • No prompts
    • Dialectical logic

Nestspace

The Nestspace is a container.

It acts as an interface between;

  • The external environment
    • Computer
    • O/S
    • Application Server
  • Pipi System Engine (sys)

The Nestspace has hidden internal NEST Variables like;

  • NEST_JAVA_EDITION
  • NEST_NEST_NAME
  • NEST_SYSTEM_OS

The only engine the Nestspace can communicate with is the Pipi System Engine (sys).

Test Process

It makes sense to move each engine one by one and check that messaging is working using the Pipi Variables.

The first Engine to test is the Pipi System Engine (sys). Once tested, it will be left running, with live logs for monitoring.

Down the rabbit hole

Its internal engines will then be added one by one for testing and commissioning.  Most engines should be good to go, but everything needs to be carefully checked.

Each engine consists of one or more engines. These engines can communicate with each other. There are internal structures that act as membranes and pathways. Each engine can also operate at reduced capacity if it is the only engine, which will help with staging and initial testing. Then watch the logs as more engines are slowly added.

Critical threshold

About 20 of these engines are necessary for emergent behaviour to become sufficiently dominant for self-management to operate reliably. Those are the engines I will start on first. Once a working system is back in place, they will be able to help speed up the import of the remaining engines via the Agent Workspace UI. A set of simple web forms should do it.

Engine Logs

Things that I have seen before to watch out for include

  • Power Laws
  • Fractals
  • Noise
  • and other crazy stuff 😎
It's Pipi's patterns of behaviour that fascinate me. Maybe it's from the feedback loops?

Mission Control

I need to find a light, open-source graphing tool that can visualise these logs and be embedded on web pages. Like Houston, there will be a big live screen monitoring everything. As progress is made, A video camera can point at the screen to live-broadcast on YouTube for anyone who's curious or for online talks. This maintains a physical network separation of the data centre from the internet.


DevOps log (edit)

A record of work done.

NZ DateTime Action Engine Status
2026-04-21 11:58 Import System Engine (sys). Complete
2026-04-22 11:44 Edit System Engine (sys) - Application.cfc. Complete
2026-04-22 13:24 Edit System Engine (sys) - reassign VARIABLE scopes. Complete
2026-04-22 13:31 Test System Engine (sys) - connect to Nest /9cc/. Success
2026-04-22 13:45 Edit Rename /pipi/pipi_system.cfm as pip/pipi_version.cfm. Complete
2026-04-22 13:48 Edit Add /sys/pipi_system.cfm. Complete
2026-04-22 18:13 Move Migrate databases. Complete
2026-04-22 18:47 Test System Engine (sys) - Consistent variable names by checking the Namespace Engine (nsp). Success
2026-04-24 10:55 Create Nestspace Engine (nst) Complete
2026-04-24 10:58 Import Namespace Engine (nsp) Complete
2026-04-25 17:19 Test Nestspace Engine (nst) - Accurate nest build definitions. Complete
2026-04-25 20:49 Create Nestspace Engine (nst) - Temporary templates. Complete
2026-04-26 07:44 Test Namespace Engine (nsp) Complete
2026-05-18 08:21 Edit Rename Nestspace files. Complete
2026-05-19 11:56 Edit Restructure Nestspace code. Complete
2026-05- Test Nestspace auto-install
2026-05- Test Namespace Engine (nsp) - Sync variable names.
2026-05- Edit Nestspace <> Instance <> Version <> System - Change variable outputs.
2026-05- Test Nestspace <> Instance <> Version <> System.