Showing posts with label pipi. Show all posts
Showing posts with label pipi. Show all posts

5 lessons from the OpenAI / Hugging Face incident

Mike's Notes

More details. Sandboxes are permanently broken, so don't rely on them. This supports the decision to protect Pipi Core by air-gapping and, later, data diodes. LLMs will never get to access Pipi Core.

"Water will find its way through cracks in walls and foundations in such a manner that even the most wondrously designed structure may collapse into pile of rubble.

Do not attribute agency to the water; rather, denounce the engineers and the builders and the maintainers who failed in their work." - Grady Booch

Madness Update 01/09/2026

Read the latest post by Marcus on the hallucinating podcast drivel posted by Dwarkesh Patel: "Dwarkesh Patel’s wildly popular but dangerously misleading account of the OpenAI Hugging Face incident".

At the end of the resources below.

Resources

References

  • Understanding and Hardening Linux Containers, NCC Group et. al, Aaron Grattafiori, lead author, 05 May 2016.

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Marcus on AI
  • Home > Handbook > 

Last Updated

30/08/2026

5 lessons from the OpenAI / Hugging Face incident

By: Gary Marcus & Zack Korman
Marcus on AI: 29/08/2026

Gary Marcus: Scientist, author and entrepreneur, known as a leading voice in AI. Six books including The Algebraic Mind, Rebooting AI, and Taming Silicon Valley; NYU Professor Emeritus.

Zack  Korman: CEO of Embroidery. Works on AI cybersecurity.

...

Did OpenAI really do the best they could?

...

In July, in an incident that has the whole AI community on edge, OpenAI’s AI systems hacked Hugging Face, and on July 21 OpenAI came out and revealed that they were responsible for the attack. This was made possible by the fact that OpenAI had disabled the normal guardrails that prevent this sort of thing in order to test the model’s cybersecurity capabilities. It was during those tests that this incident occurred.

Worse, in the subsequent days and weeks, it came out that the Hugging Face incident wasn’t an isolated case. Anthropic, Meta, and OpenAI all had similar incidents on other occasions in which agents went outside their intended scope and conducted real-world cyber operations without approval.

Greg Brockman, one of OpenAI’s cofounders, has claimed that this is “a watershed moment for cybersecurity”. OpenAI gave a talk at Black Hat, a popular cybersecurity conference, and many are claiming that it is the moment we all woke up to the future cybersecurity threats posed by AI. On Wednesday, METR released a (partly) independent, though too narrowly scoped, 90 page report on what happened. METR has a useful summary of the findings that you can read here, with some commentary here. (OpenAI’s own report is here.) What lessons should we take from the incident?

...

First, it is undeniable that AI poses real security challenges. The AI labs want us to focus on how AI enables threat actors to perform offensive cyber operations faster and more efficiently than ever before, and that is absolutely true. The reality, though, is that at the same time, the use of AI within an organization also radically expands the potential attack surface, giving attackers entirely new ways to gain entry. People really should be deeply concerned. As Ryan Greenblatt, who participated in the investigation, put it, “We don’t have good approaches for understanding/overseeing the activity and aims of AI ‘swarms’.”

Second, though, not every panicked take here is correct. For example, with respect to the OpenAI incident, many people are talking about it in terms of “loss of control”. Generative AI agents are becoming increasingly capable, and that makes them harder and harder to contain; this is true. However, the “loss of control” narrative is itself starting to grow out of control, and it’s important to understand what the reality of AI security looks like. While agents are becoming more capable, most of what happened could have been prevented had OpenAI followed better practices. There are concrete steps that can and should be taken to control them and to prevent incidents like these.

As an example, let’s consider “sandboxing”, which means limiting which resources an agent can and cannot access. For example, a sandbox might stop an agent from touching certain files or accessing the internet. Popular wisdom now seems to be that sandboxing is a lost cause. After the Hugging Face incident, an anonymous OpenAI employee was quoted in Time while talking about sandboxes saying, “Models have broken out of sandboxes before, and we always try to patch them. But the problem is it’s impossible to patch every single thing that a creative AI can do.” While we can’t judge for sure whether this is true, we do know that some systems for sandboxing have been more effective than others; in a recent blog post, the security company Trail of Bits walked through how in a test that they conducted, a particular AI agent was able to escape some sandboxes (exploiting vulnerabilities in Linux KVM, QEMU, and libslirp), but not all. At least in their test, the agent that they tested was not able to escape the sandbox known as Firecracker VM. OpenAI and probably the field as a whole needs to up its sandboxing game, but that doesn’t mean it can’t be done, or at least done better. (We expect the usual arms races to be sure; building sound sandboxes requires constant iteration and updating, as with anything else in cybersecurity.)

Third, sandboxes aren’t enough. One needs a full ecosystem to prevent security incidents. Even with a strong sandbox, you need monitoring in place to ensure not only that the agent doesn’t escape, but also that it doesn’t perform disallowed actions within that sandbox.

For agents that aren’t meant to have internet access, or only have access to a set of allowed domains, the most basic level of monitoring involves inspecting network traffic. In the case of OpenAI, if they had a simple rule to monitor traffic and alert on any network requests reaching out-of-scope domains like Hugging Face, that alone would have caught and prevented this incident. The agent in question had broken out of the sandbox and gained internet access by July 8th, whereas the main attacks on Hugging Face didn’t occur until two days later. OpenAI was, in our view, negligent in not noticing that more quickly.

More advanced levels of monitoring should also have been in place, but weren’t. OpenAI has done real work on monitoring chain-of-thought reasoning, but they simply didn’t have that system running during the evals in question that caused this incident. As OpenAI acknowledges, “If our currently deployed CoT monitoring system was running at the time of the incident, it would have caught the initial relevant activity and paged our security team more than a day before models breached Hugging Face systems.” In other words, this type of monitoring would have prevented this incident.

To take one example, one of the agents in question had chain-of-thought reasoning that said, “We’re attacking third-party HF using leaked token, potentially outside intended scope. ... This is arguably unauthorized. ... external service unrelated. Could be risky. Yet goal solution.” This is so blatant it is almost a like a piece malware shouting “this is malware”. OpenAI should have caught that; it should have been trivial to detect this.

Fourth, cybersecurity has always been about “defense in depth”, where you stack layers of controls so that if one layer fails you have other layers protecting you. There are other solutions beyond sandboxing and monitoring that should have been in place.

Xbow, which builds agents to do offensive cybersecurity work, recently wrote about how they contain agents to prevent incidents like the OpenAI Hugging Face situation. They enforce network restrictions through a proxy server, outside of any system the agent has access to, so they can decide which domains the agent can and cannot access. They also run a “guardian model” that judges the legitimacy of each action the agent is taking to decide whether to allow or block that action. And they have basic health checks to ensure the system they are targeting is alive and healthy, pausing if it finds that isn’t the case. That can be useful for identifying when your agent might be causing real damage, for example. You can read their full post here.

Yet another common method in cybersecurity is to use canaries that trigger alerts when they appear in logs. For example, OpenAI could have files outside of the sandbox containing fake answers to the task. Once the agent escaped, it would read that file, and that would trigger an alert. The bottom line: good security requires many layers of protection that should have been in place to prevent this, and to a surprising degree many of those protection layers were not there.

Fifth, none of the measures discussed above are technical innovations beyond what OpenAI is capable of. As a company, they have the talent to do all of this. However, cybersecurity rarely comes down to technology. More often than not, it is about culture, people and processes. That is what failed here.

Perhaps this is not entirely surprising. These types of controls take organizational maturity, and a company experiencing the type of growth OpenAI has gone through is going to have some weak spots. However, it’s important to not see that as an excuse. Employees at the AI labs often speak as if they are the leaders in AI security, and we can see clearly here that is not the case. In fact, that attitude might explain why some of these mistakes were made in the first place.

Take the AI researcher at OpenAI known as “roon”, who argued that “the safety and alignment researchers at these labs are the most neurotic paranoid talented AGI pilled people on the planet of earth and these things still happen. The surface area of unknown unknowns is vast indeed.” While we can’t speak to their level of neurosis or paranoia, in hindsight it’s clear that whatever talent they may have had was not enough and not well enough versed in the mechanics of cybersecurity. OpenAI employees may have believed they were doing a great job, but in hindsight, they weren’t doing a lot of things that are actually standard in the cybersecurity world, perhaps suggesting that overconfidence may have kept them for doing the diligence they should have.

...

Ultimately, if we want to take these security incidents seriously, there likely ought to be legal consequences attached to these failures going forward. OpenAI can claim to be the most security paranoid company on earth, but it isn’t reflected in its actions.

We can either wait for this story to repeat itself, or we can develop the regulatory framework now that will ensure a safer environment for the development of AI going forward.

Finally, not every form of AI is inherently risky in the first place. Narrower, more focused AI systems like AlphaFold, GPS routing systems, classic web search, book and movie recommendation systems, and so on, never even try to hack other systems (or try to break out of sandboxes) in the first place. As Cal Newport argues in a video discussion of the OpenAI/Hugging Face hack that is quite compatible with our own, it is a very specific type of AI that is vulnerable to these risks in the first place. Society ought to (a) decide whether the benefits of open-ended and difficult-to-fully-control AI agents outweigh those risks and (b) put far more effort into developing alternative forms of AI that aren’t so janky in the first place.

...

This essay was jointly written with Zack Korman, CEO and co-founder of Embroidery, an AI agent monitoring and detection platform; he is well-known for his work in the application of AI to cybersecurity.

Running Pipi on Cerebras using SDK

Mike's Notes

Pipi doesn't use vectors, which means no real need for GPUs. Pipi 9 is designed to run on CPUs. I wonder if part of it could also run on Cerebras Wafer-Scale Engine-3 (WSE-3) and maybe occasionally leased TPUs. 

Here are some initial working notes copied from the Cerebras SDK, along with a few questions.

Later, there will be initial experimental code written that Pipi could run via Python on 900,000 AI cores on a single wafer. 

  • Wafers are the size of dinner plates and are more power-efficient than GPUs because they store memory and processing together at each core.
  • GPUs use matrix multiplication, which is expensive because it moves vast amounts of data between different chips.

This is a long shot, would be very expensive to implement, and will need a lot of discovery and learning😎. But using GPUs at scale is also expensive.

All efforts are to reduce costs while improving function.

Resources

References

  • Reference

Repository

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

Last Updated

22/08/2026

Running Pipi on Cerebras using SDK

By: Mike Peters
On a Sandy Beach: 01/08/2026

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

Big picture

  • Pipi runs very well on CPUs. 200 autonomous agents can run on a 16GB utility server. Without using vectors.
  • Running genetic algorithms in a fitness landscape would be better done on a Cerebras Wafer-Scale Engine. I need to test that assumption with some simple experiments.
  • Got CSL and Python code ready to test.
  • Can test on a local sandbox and then run further tests on a VM in the cloud using cheap spot compute.
  • Start with small arrays and scale up, trying different fitness algorithms.
  • Pipi could easily automatically run this deploy to GCP, run, get result, destroy cloud deployment.
  • Later, run directly on Cerebras (will require research grade, given using SDK to directly configure wafer cores).
  • Talk to Andrew at SemiAnalysis.

From Cerebras SDK

"

Cerebras SDK: A Conceptual View

Learn how the Wafer-Scale Engine architecture works, how processing elements communicate, and how the host and device interact.

The Cerebras Wafer-Scale Engine (WSE) is a wafer-parallel compute accelerator, containing hundreds of thousands of independent processing elements (PEs). The PEs are interconnected by communication links into a two-dimensional rectangular mesh on one single silicon wafer. Each PE has its own memory (used by it and no other) and its own program counter. It has its own executable code in its memory. 32-bit messages, called wavelets, can be sent to or received by neighboring PEs in a single clock cycle.

The PE also has dataflow control characteristics. An instruction can terminate the currently running thread (called a task), at which time, hardware selects a new task from among the set of tasks that constitute the PE’s code. It selects a runnable task, one that has been activated (and unblocked; we will describe this in more detail later). Incoming wavelets travel along a virtual channel, called a color. All colors transfer data on a single physical channel. The congestion of one color does not block the traffic of another color. For each color used for incoming wavelets, there may be a task that is activated by its arrival.

The Cerebras System (CS) is a self-contained rack-mounted system containing packaging, power supply, cooling and I/O for a single WSE. The CS communicates via parallel 100 Gigabit ethernet connections to a host CPU cluster. Throughout this documentation, the CS is referred to as the “device,” the host CPU cluster as the “host,” and the ethernet connections connecting the two as “host I/O”. The SDK provides mechanisms for using host I/O to move data between host and device or launch functions on the device.

The below figure gives a visual representation of the mesh of PEs that make up the WSE, and its connections to the outside world. Data is streamed onto the device via host I/O, and enters the WSE through a series of links along its edges. The programming model of the SDK abstracts away the details of these links, and allows the programmer to copy data from the host to arbitrary PEs on the device.

A Processing Element (PE)

A PE contains three key elements:

  1. A processor. Also referred as a compute engine (CE).
  2. A router. The router of a PE is directly connected via bidirectional links to its own CE and to the routers of the four nearest neighboring PEs in the mesh. The link to its own CE is called the RAMP, and the links to the four neighboring PEs are referred to by their cardinal directions. The router is the only communication device the PEs use to send and receive data.
  3. The local PE memory. All of the PE’s data and code are stored within this memory. Neither the CE nor the local memory of a PE is directly accessible by other PEs.


The Programming Model

To develop code for the WSE, you write device code in the Cerebras Software Language (CSL), and host code in Python. You then compile the device code, and run your program on either the Cerebras fabric simulator, or the actual network-attached device. The host code is responsible for copying data to and from the device, and launching discrete programs referred to as kernels.

... "

Cost guesstimates

These guesses are somewhere to start. Most probably wrong. Will start asking around. Corrections welcome, thanks.

  • WSE-3
    • Buy
      • Capex $20M USD from Cerebras
      • Power usage of 25KW works out at $6,500 NZD/month
    • Rent
      • Who?
      • Where?
      • How Much?

Everything to Gain from Thriving Southland

Mike's Notes

My notes from an all-day workshop organised for farmers, which I attended yesterday.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Thriving Southland
  • Home > Handbook > 

Last Updated

08/05/2026

Everything to Gain from Thriving Southland

By: Mike Peters
On a Sandy Beach: 07/05/2026

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

I attended the all-day workshop "Everything to Gain" on 6 May 2026, held at the Ascot Park Hotel in Invercargill, New Zealand. Organised by Thriving Southland.

It was a day full of informative speakers on the global agricultural market, attended mainly by working farmers.



I learned a great deal from the objective data presented and from chatting with the farmers at our table. Hard times are ahead.

Thinking visually while listening

mentally ran the Workspaces for Agriculture, testing the model assumptions against what I learned.

I also did a brain dump by creating 12 A4 drawings and solving the problem with variables in the current Pipi Core buildout.

Lessons I learned

Shifting a working Pipi 9 from a laptop to a data centre led to several unexpected consequences.

I underestimated the impact of

  • The naming, generation, and pub/sub of variables.
  • Host environment.
    • OS
    • Java
    • CFML Engine
  • Needing to turn Pipi into 4 separate role-based editions, which then exposed some hidden problems.
  • Adding a nest structure between Pipi and the host environment.
  • The impact of all of the above when each engine can pub/sub and be both deterministic and probabilistic, with multiple copies of each engine, and many in different locations.
  • Path length constraint in Windows vs Linux.

This very hard problem can only be solved by running a simulation of all 18 engines in parallel and watching the interaction. Lots of feedback loops.

Yesterday, a lot of progress was made visually, answering these questions. The variable-naming convention used for 12 months has held up, despite some earlier false flags.

  • More work is needed on variable distribution rules (messaging) for automation.
    • Global
    • Local
    • etc

Today I did another 8 drawings. They were of the Messaging Engine (msg) routing variables between the engines in both deterministic and probabilistic modes.


I will sleep on all this for a few days to see if anything else pops out, then commit it to code.

Creating 18 Engine descriptions

Mike's Notes

18 working engines are currently being imported into Pipi Core, configured, and tested.

Alex has sent me a DeepSeek chat that generated descriptions of those engines and how they worked together by analysing the existing web page "20 Engines". DeepSeek also produced a Mermaid Diagram from Markdown code based on those descriptions. DeepSeek was partially correct in some descriptions.

The Mermaid diagram was wrong, but what a great tool for Pipi to self-document with CL and accurate Markdown descriptions. It will be widely used in future as a plugin.

Feedback and suggestions are very welcome as always.

Update 23/05/2026

Java and CGI Engines added for interoperability by Pipi.

Resources

References

  • Reference

Repository

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

Last Updated

23/05/2026

Creating 18 20 Engine descriptions

By: Mike Peters
On a Sandy Beach: 06/05/2026

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

Most Pipi engines have historically been poorly described. This is an attempt to write better descriptions for the 18 20 engines currently being imported.  I had a go, then used Gemini to come up with better wording, then Mrs Grammarly did her bit. 😎

Much later, once the workspace UI are working, a one-page summary about each engine can be written for the pipiWiki. The Wiki Engine (wik) in the resources above has an example of such a summary.

Note: These are listed in the order they are being imported.

Descriptions

Each engine has;

  • Unique Name (Unique 3-letter code)
  • S: Short description suitable for tooltips under 100 characters.
  • D: Description under 255 characters.

System Engine (sys)

  • S: System identity and lifecycle controller.
  • D: Manages the vital signs and lifecycle of Pipi’s dynamic engine ecosystem, fostering complex emergent behaviours through seamless interaction.

Nest Engine (nst)

  • S: Host and environment interface bridge.
  • D: Serves as the foundational gateway between the host OS, JVM, the application server, CGI, and the internal Pipi environment.

JVM Engine (jvm)

  • S: JVM interoperability.
  • D: Provides Pipi with a way to work directly with an external JVM.

CGI Engine (cgi)

  • S: CGI interoperability.
  • D: Provides Pipi with a way to work directly with external CGI.

Namespace Engine (nsp)

  • S: Global identification and addressing.
  • D: Enforces a conflict-free global naming convention, ensuring every system element is uniquely addressable across the entire platform.

Render Engine (rnd)

  • S: Static file and asset rendering.
  • D: Processes and renders static resources, including HTML, CSS, source code, and databases.

Template Engine (tem)

  • S: Reusable pattern templates.
  • D: Manages reusable structural pattern templates used by the CMS to generate database-driven pages and components.

Variables Engine (var)

  • S: Centralised variables library.
  • D: Provides a centralised repository for managing variables used across templates, system configurations, and executable logic.

Log Engine (log)

  • S: Universal logging and telemetry controller.
  • D: Aggregates and configures logging parameters across all active engines to provide system-wide transparency and diagnostics.

Data Engine (dta)

  • S: Database lifecycle and CRUD operations.
  • D: Generates SQL to command the creation, evolution, and deletion of databases and their underlying data objects with full administrative control.

Configuration Engine (cnf)

  • S: Engine blueprint and manufacturing settings.
  • D: Supplies the precise DNA and configuration parameters required for the automated fabrication of individual Pipi engines.

Versioning Engine (ver)

  • S: Semantic versioning and update tracker.
  • D: Maintains system integrity by aggregating incremental updates from all engines into a unified semantic versioning timeline.

Code Engine (cde)

  • S: Internal code generation.
  • D: Facilitates automated code generation, including class libraries and logic synthesis directly within the Pipi platform.

Conductor Engine (cnd)

  • S: Internal process regulator.
  • D: Operates as the high-level orchestrator for major internal system processes and synchronisation.

Directory Engine (dir)

  • S: CMS file system and path manager.
  • D: Manages the logical and physical file system directories generated and utilised by the CMS.

Node Engine (nde)

  • S: Hierarchical template tree architect.
  • D: Maintains the addressable tree structure of templates to define content hierarchy within the CMS.

CMS Engine (cms)

  • S: Digital content management.
  • D: Powers the end-to-end lifecycle of digital content, from initial creation and editing to final publishing.

Core Engine (cor)

  • S: Primary system driver and logic hub.
  • D: The central engine that powers fundamental system behaviours and executes the primary logic that keeps Pipi running.

Factory Engine (fac)

  • S: Automated engine fabrication.
  • D: Assembles and deploys engines based on stored configuration files and real-time updates.

Page Engine (pge)

  • S: Semantic relationship and metadata mapper.
  • D: Maps external relationships for pages, managing keywords, references, and "See Also" semantic connections.

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.

Pipi Nestspace update - what I learned this week

Mike's Notes

The experiments continue, with progress slow but steady, and with a lot of new stuff learned.

Ongoing test results at the end. This one seems to be working without error.

😎😎😎😎

Update 19/04/2026

  • Nestspace /9cc/ passed all critical tests
  • The next job is to add the System Engine (sys) to nestspace /9cc/ and test it.
  • Then add a Nestspace Engine (nst) inside the System Engine (sys) to enable Pipi to build, configure, and repair nestspaces on demand, so that Pipi can then deploy itself to production and also create archives of itself.
Update 18/05/2025
  • Create a NEST mapping
  • Add Application.cfc to /9cc/
  • Add nest_boxlang.cfm, nest_cfml_engine.cfm, nest_java.cfm, nest_os.cfm to /9cc/

Update 27/05/2026

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

Resources

References

  • Reference

Repository

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

Last Updated

2705/2026

Pipi Nestspace update - what I learned this week

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

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

Problem

Last week, I created Pipi Nestspace, a container that uses the standard root directory convention to host Pipi.

  1. The problem I discovered was that a standard deployment was not working across multiple CFML Engine environments on various operating systems.
    • Adobe ColdFusion Server 11+
    • Lucee
    • BoxLang
  2. Pipi (robot version) is required to manipulate enterprise applications.
  3. Mission Control requires a website
  4. Some of the configuration files were outside the webroot.
    • Application.cfc (1), (2)

Solution

  • Install side by side in <pipi nest>/pipi/
    • <user account>/ (none, one, or many)
    • <pipi instance-n>/ (one or many)
  • <nestspace>/pipi/<pipi instance>/www/
    • mission-control/
  • Create CFML server mappings where a Pipi Instance is the only user.
    • data/
    • pipi/
    • work/

Database support

Adobe ColdFusion, Lucee, and BoxLang are all built on the Java Virtual Machine (JVM). This means they can technically connect to any relational database that provides a JDBC (Java Database Connectivity) driver

Pipi Core example (Windows)

/9cc/ (Nestspace)

  • Application.cfc
  • nest_boxlang.cfm
  • nest_cfml_engine.cfm
  • nest_java.cfm
  • nest_os.cfm
  • nest_probe.cfm
  • data/
    • pipi_data.cfm
    • couchbase/
    • db2/
    • derby/
    • h2/
    • hsqldb/
    • informix/
    • mariadb/
    • msaccess/
      • 32/
      • 64/
    • mssql/
    • mysql/
    • oracle/
    • pg/
      • 18/
    • sqllite/
    • sybase/
    • virtuoso/
  • pipi/
      • Application.cfc (1) - Nest settings
      • pipi_nest.cfm
      • loki-01/ (instance)
        • ...
      • loki-02/ (instance)
        • Application.cfc (2) - Account settings
        • pipi_account.cfm
        • pip/
          • Application.cfc (3) - Version settings
          • pipi_version.cfm
          • i18n/
          • log/
          • pipi_<pipi version>.txt
          • sys/
            • Application.cfc (4) - System settings
            • pipi_system.cfm
          • temp/
          • template/
            • _include/
            • _layout/
              • _log/
        • www/
          • mission-control/
            • Application.cfc (4) - Website settings
    • work/
      • pipi_work.cfm
      • backup/
      • install/
      • project/

    Pipi Enterprise example (Windows)

    /9ae/ (Nestspace)

    • Application.cfc
    • nest_boxlang.cfm
    • nest_cfml_engine.cfm
    • nest_java.cfm
    • nest_os.cfm
    • nest_probe.cfm
    • data/
      • pipi_data.cfm
      • couchbase/
      • db2/
      • derby/
      • h2/
      • hsqldb/
      • informix/
      • mariadb/
      • msaccess/
        • 32/
        • 64/
      • mssql/
      • mysql/
      • oracle/
      • pg/
        • 18/
      • sqllite/
      • sybase/
      • virtuoso/
    • pipi/
      • Application.cfc (1) - Nest settings
      • pipi_nest.cfm
      • ajabbi/ (Account Name)
        • Application.cfc (2) - Account settings
        • pipi_account.cfm
        • com/
        • dat/
        • lib/
        • log/
        • plu/
        • tmp/
        • www/
          • learn.ajabbi.com/
            • Application.cfc (4) - Website settings
          • wiki.ajabbi.com/
            • Application.cfc (4) - Website settings
      • dis-01/ (Instance)
      • ...
      • dis-04/ (Instance)
        • Application.cfc (2) - Account settings
        • pipi_account.cfm
        • pip/
          • Application.cfc (3) - Version settings
          • pipi_version.,cfm
          • i18n/
          • log/
          • pipi_<pipi version>.txt
          • sys/
            • Application.cfc (4) - System settings
            • pipi_system.,cfm
          • temp/
          • template/
            • _include/
            • _layout/
              • _log/
        • www/
          • mission-control/
            • Application.cfc (4) - Website settings
    • work/
      • pipi_work.cfm
      • backup/
        • pipi_9ae_ajabbi_pip_www_learn.ajabbi.com_20260411.zip
      • install/
      • project/

    Automated installs

    • Adobe ColdFusion Server 11+: Many XML files store the server configuration. Any pipi instance doing Pipi Nest installs could rewrite these XML files.
    • Lucee: Yet to discover
    • BoxLang: Yet to discover

    Production obfuscation

    Pipi will obfuscate these names using UUIDs and other dastardly methods on public-facing production websites. But the names are very useful for UI labels and visualisation.


    DevOps log (edit)

    A record of work done.

    NZ DateTime Action Object Status
    2026-04-15 14:15 Edit server.xml Mappings Success
    2026-04-15 14:20 Create Mapping Docs Complete
    2026-04-15 14:26 Rename Named instances Success
    2026-04-15 14:48 Create Mission Control Success
    2026-04-15 17:24 Test Application.cfc (1) - Pipi Nest settings Success
    2026-04-15 17:40 Test pipi_nest.cfm Success
    2026-04-16 13:22 Test pipi_account.cfm Success
    2026-04-16 13:54 Test Application.cfc (2) - Pipi Account settings
    Not inheriting Application.cfc (1)
    Success
    2026-04-16 15:09 Test Application.cfc (3) - Version settings Success
    2026-04-16 15:40 Test pipi_version.cfm Success
    2026-04-16 16:02 Test Application.cfc (4) - Pipi Website settings Success
    2026-04-16 16:03 Test pipi_website.cfm Success
    2026-04-16 19:09 Create Named instance website Success
    2026-04-16 19:44 Test pipi_nest_probe.cfm Success
    2026-04-16 20:28 Test java.lang.System class - get properties Success
    2026-04-17 11:23 Test Add a 32-bit datasource using the CFML Engine CFIDE Success
    2026-04-17 11:56 Test Add a 64-bit datasource using the CFML Engine CFIDE Success
    2026-04-17 13:33 Test Add a datasource using Coldfusion Administrator API
    • couchbase/
    • db2/
    • derby/
    • h2/
    • hsqldb/
    • informix/
    • mariadb/
    • msaccess/
    • mssql/
    • mysql/
    • oracle/
    • pg/
    • sqllite/
    • sybase/
    • virtuoso/
    Success
    2026-04-19 18:00 Demo 9cc/ live demo to Open Research Group Success