Workspace trial causes engine modifications

Mike's Notes

Changes triggered by the recent successful workspace trial. I slept on this for a few weeks, just to be sure. 😇

Most done already. A lot better.

Resources

References

  • Reference

Repository

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

Last Updated

5/12/2026

Workspace trial causes engine modifications

By: Mike Peters
On a Sandy Beach: 5/12/2025

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

Some Pipi 9 agent engines are getting minor modifications as a result of lessons learned from the recent successful stress-test trial involving 15,000 generated web pages and directories in a workspace website UI. It took creating a massive static mockup for volunteer testers to explore freely and identify gaps.

After these simple modifications, Pipi 9 will automatically render in about 50 seconds, another static mockup of a huge workspace website for testing. If that stress test is 100% successful, the next stage will be rendering a live version.

Pipi 9 will then automatically generate much larger custom live workspaces without error. And on demand.

The necessary minor modifications will change the deployment-workspace hierarchy previously described on this engineering blog.

The previous workspace settings from 2018, stored as structured training data, also need to be edited. The test results indicate that everything can now be significantly simplified, resulting in a performance boost.

Deployment Engine (dpl)

A Deployment Type has been added to create a simple separation of functions and to drive URL pattern creation.

  • Applications a/
  • Customer c/
  • Global g/
  • Settings s/

Workspace Engine (wsp)

A new Module Entity has been added to store each workspace module's attributes. They are all inherited from a library of predefined Domain Model Objects.

The revised hierarchy is

User Account

A User Account has three or more Deployments.

  • Applications
  • Customer
  • Settings
An Enterprise Account can also have Global Deployments to share properties.

Deployment

A Deployment is a container for one or more Workspaces. A deployment has these properties;

  • ID
  • Code Name
  • Name
  • Description
  • One language (eg English)
  • One User Account
  • One Deployment Class (type of tenancy)
  • One Deployment Type (type of container)
  • Those properties are inherited by all workspaces.

Workspace

A Workspace is a container for one or many Modules. A workspace has these properties;

  • ID
  • Code Name
  • Name
  • Description
  • One inherited language (eg English)
  • One inherited User Account
  • One inherited Deployment
  • One pre-built Domain Model (eg, Screen Production).
  • One Domain Model Template (eg, Feature Film, Documentary, Live Broadcast), These templates can be customised and shared.
  • Main menu (Ribbon, etc)
Those properties are inherited. This means each Workspace/Domain Model comes with its own set of prebuilt Security Roles and Security Profiles.

Module

A Module is a container for nil, one or more modules in a nested tree hierarchy. Modules can be rearranged in the Workspace UI via drag-and-drop. They are all semantically linked. A module has these properties;

  • ID
  • Parent Module ID
  • Code Name
  • Name
  • Description
  • Sort order
  • One inherited language (eg English)
  • One inherited User Account
  • One inherited Deployment
  • One inherited Workspace
  • One pre-built Domain Model Object (eg, Task, Runway, Locomotive, Film Set, Medical Device).
  • Set of prebuilt Security RolesSecurity Profiles.
  • Context menu (Ribbon, etc)
  • Learning objects
  • Contextural help
  • Attached
    • Tools
    • Workflows
    • State
    • Code
    • Data

No comments:

Post a Comment