The Workspace Issue

Mike's Notes

This is a copy of the January issue of Ajabbi Research.

It is a historical overview of the effort to create a workspace-based UI for Pipi.

Ajabbi Research is published on SubStack on the first Friday of each month, and subscriptions are free.

Each issue is a broad historical overview of a research topic, serving as an index to dozens of previously posted related articles. There are now over 600 articles/posts.

Eventually, each issue will be reused on the separate Ajabbi Research website as an introduction to a research area comprising multiple research projects.

Resources

References

  • Reference

Repository

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

Last Updated

6/02/2026

The Workspace Issue

By: Mike Peters
Ajabbi Research: 02/01/2026

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

This is the story of how Pipi got a workspace-based User Interface (UI). The steps taken have been part of Pipi's development since 2007, spanning 5 versions.

The NZERN Pipi 2003-2005 Development Plan started it all.

Pipi 4 (2005-2008)

The story starts with Pipi 4. It was a big, successful system that supported community-driven Ecological Restoration in NZ. Here is a history of that Pipi version.

Due to very rapid scaling, a no-code approach was required to build the UI.

NetSuite was the original inspiration. A database-based framework was constructed to store user interface components, and another database to store the information being displayed and edited.

Recently, an archive of Pipi 4 help documentation was discovered and is now available for viewing. It is incomplete, but it gives an idea of how it worked.

Pipi 6 (2017-2019)

When Pipi was rebuilt from memory, the monolithic architecture was refactored into loosely coupled modules. Many new modules were created to support a rich UI. Each module had its own database.

Pipi 7 (2020)

Pipi was converted to microservices. Pipi could self-document. Static HTML mockups of workspaces were created as experiments. They were generic and could be applied to any subject domain, e.g., space, health, film, or experiments.

Pipi 8 (2021-2022)

System-wide namespaces were introduced, making Pipi headless, and the microservices were converted into autonomous agents (Engines). Self-documentation broke as a result.

More agents were created to manage each other. Some were merged, and others split. These agents are large, with 10,000 lines of code common, and they maintain internal, complex databases, messaging, and workflows, all of which maintain state. None of them is stateless.

Pipi 9 (2023-)

Many of the internal engines were aggregated into complex systems. Some contained up to 20 different engines, all operating independently and interacting. These systems were then combined into more extensive systems, etc. So far, there are 300+ different engines (with multiple copies), and Pipi 9 has emerged.

Key problems needed to be solved to enable a workspace-based UI to emerge from Pipi. These included;

  • Ontology-driven constraints
  • Domain modelling
  • Model-driven UI to provide automatic accessibility
  • Self-documenting
  • Structured learning
  • i18n for every human language and writing system.
  • Design system
  • Security and permissions
  • Useful URL patterns
  • Naming conventions
  • Ribbon menu

Ontology-driven constraints

The Ontolog Forum was a great help. BORO was hacked to run in reverse. This drives the system-wide constraints. The BORO Engine (bor) can also autonomously run forward if needed, similar to the KREB's cycle. This means ontologies can be imported into Pipi by the Ontology Engine (ont) to help provide world models based on primitives supplied by the Physical Law Engine (plw).

In the Reductionist System (red), the Domain Engine (dmn) and Module Engine (mod) create data models using Domain-Driven Design (DDD) from ontologies.

Model-driven UI

The User Interface Description Language (UIDL) was an EU-funded project that was abandoned in 2010 after 10 years of excellent work. It was to enable accessibility on different screens and devices. The research results were reverse-engineered to build a User Interface Engine (usi) that would run in reverse to generate accessibility solutions for Pipi. The CSS Engine (css) replaced some redundant components of the UIDL project. Additional engines for localisation and personalisation were created.

Self-documenting

With the help of Alex Shkotin from the Ontolog Forum, templates were designed for the Wiki Engine (wik) and Docs Engine (doc) to automatically populate and generate system documentation from hundreds of agents and thousands of processes. There are some test examples to look at.

Structured learning

IEEE Learning Objects were an inspiration for the Learning Object Engine (lob). This engine was used to structure learning materials using Diataxis to address users' diverse learning needs. The Help Engine (hlp) takes the same material to provide in-context help in the UI.

i18n for every human language and writing system

Using SIL and Unicode naming conventions, the Language Engine (lng) stores UI translations in multiple languages and writing systems, enabling Pipi capable of supporting all 7,000 known languages. Then the Locale User Interface Engine (lui) creates localised UI.

Design System

A Design System Engine (dsg) was built to handle multiple design systems, including a default one for the initial workspace UI. The design system includes UI components and design tokens.

Security and permissions

Role-based Access Control (RBAC) was implemented to manage security and user permissions. This applies to different types of user accounts and to finer-grained access.

Useful URL patterns

Clear URL patterns were established.

Naming conventions

A naming convention was adopted for output directories and filenames based on simple predictive rules.

Ribbon menu

A ribbon navigation menu (Tab Group) outline was created that could also be a non-ribbon navigation. One source, many formats.

Workspace Version 1 (October - November 2025)

A roadmap was first created to provide focus and clarity.

Batch processes created 15,000 files and directories to form workspaces that contain static HTML webpages for testing. Each workspace had a ribbon menu and used iframes to organise navigation and content. Testing is successful.

The Workspace Version 1 trial revealed that the UI is a thin wrapper around Pipi.

Workspace Version 2 (December 2025 - February 2026)

Changes to Workspace Version 2 include;

Additional role-based user account types were added.

Changes to the workspace engine model.

Changes to deployment naming convention.

Documentation for standard Enterprise workspaces.

Documentation for customer support.

Documentation for account settings.

Documentation for Developer Account.

Documentation for Agent Account.

The Render Engine (rnd) then uses a database to create workspaces made of static HTML web pages.

  • Test
  • Feedback

Workspace Version 3

The Render Engine (rnd) uses a database to generate workspace ribbon menus as static HTML web pages.

  • Test
  • Feedback

Workspace Version 4

The Render Engine (rnd), Learning Object Engine (lob) and Help Engine (hlp) use databases to generate workspace user in-context documentation as static HTML web pages.

  • Test
  • Feedback

Workspace Version 5

The Render Engine (rnd) and Form Engine (frm) use databases to generate workspace forms as static HTML web pages. See the Pipi 4 example, which will also be used here.

Then

The process of making the workspaces live for logged-in users will begin.

By ,
Tags ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)