Showing posts with label workspace. Show all posts
Showing posts with label workspace. Show all posts

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.

Having a Data Centre changes the roadmap

Mike's Notes

This is the revised Pipi roadmap now that the data centre is running. The recent Ajabbi Research report, "The Workspace Issue," has also been revised to reflect these changes.

Update 25/03/2026

A very nice chap from Google contacted me to assist with applying to join one of the Google AI Accelerators. I started the application, then stopped when I realised that the 2 years of support and generous free credits started as soon as it was approved. I need to complete all Stage 1 steps in the roadmap below, and the Stage 2 IaC connection to the GCP free tier to deploy Pipi open-source before applying, to make the best use of the opportunity.

I'm requesting support from Google DeepMind to experiment with connecting Pipi via MCP to DeepMind Gemini and to find a way for Pipi closed-core to use Google TPU. Stage 3 will be highly experimental with unexpected results.

Pipi is a non-generative multi-agent system with no tokens. It doesn't need tokens to work and its 27 layers deep so far and counting. I expect it to get very barnacled and crusty over time.

Update 31/03/2026

Setting up data centre automation has revealed that workspace deployments need to be performed in this order of account types due to the permissions cascade.

  • Agent Accounts (to admin Pipi)
  • Researcher Accounts (to edit UoM, ontologies and physical laws)
  • Developer Accounts (to create enterprise workspaces)
  • Personal Accounts (to sort out personal profiles - UI fonts, etc)
  • Enterprise Accounts (to test and use the system for work)
  • etc

Update 17/04/2026

Containers, named Pipi Nest, were created to deploy Pipi.

Resources

References

  • Reference

Repository

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

Last Updated

17/04/2026

Having a Data Centre changes the roadmap

By: Mike Peters
On a Sandy Beach: 27/02/2026

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

Having a separate Pipi Core Data Centre changes everything. This has a direct impact on what is possible and on the best path forward. 

This is the revised working Deployment Roadmap for Pipi. The sequence is roughly correct; the timing is just a guess.

Stage 1

Production foundations to enable automation and rapid use.

When Task Detail
February 2026 Migration ✔ Separate networks for the isolated Pipi Core Data Centre and the Ajabbi Office.
March - April 2026 Pipi Nest ✔ Pipi deployment container
April 2026 Mission Control ✔ Telemetry on the Data Centre.
April 2026 AutomationPipi Core running autonomously in a Pipi Nest 24x7x365, with a x10 increase in productivity.
May 2026 Data Centre Admin Agent Workspace rendered by the CMS Engine with no errors.
May 2026 Workspace Workspaces containing 15,000 web pages are rendered by the CMS Engine with no errors.
2026 Workspace Workspace UI Menu rendered without errors.
2026 Workspace Draft in-context help & learning material generated for each workspace without errors.
2026 Workspace Module-based UI forms and data grids rendered with sample data without errors.
2026 Workspace Complete HTML workspace demo with connected initial developer documentation rendered without error
2026 Workspaces for Agents & Developers Workspaces are deployed in the Data Centre for production use by System Admin and DevOps, with a x10 increase in productivity.
2026

2026

2026
2026
2026

Stage 2

Automate Pipi deployment across every available cloud platform, with a free tier.

When Task Detail
2026 IaC Deploy infrastructure on the AWS Free Tier.
2026 IaC Deploy infrastructure on the Azure Free Tier.
2026 IaC Deploy infrastructure on the Digital Ocean Free Tier.
2026 IaC Deploy infrastructure on the GCP Free Tier.
2026 IaC Deploy infrastructure on the IBM Free Tier.
2026 IaC Deploy infrastructure on the Oracle Free Tier.
2026 IaC Deploy infrastructure on the Wasabi Free Tier.
2026
...

Stage 3

Deploy to any platform when admitted to its startup program that offers lots of credits to enable experimentation and scaling with early customers.

When Task Detail

IaC Deploy infrastructure on every non-free part of the platform.

IaC BoxLang VM containing Pipi Open-Source, deployed via IaC.
  MCP, A2A, Skills Pipi > LLM > Pipi
  Working Demo Fully working demo workspaces available for customers and developers to try out.
  Customer Deployments Ajabbi Personal, Developer, and Enterprise account Workspaces are available.
  Customer Deployments Ajabbi Researcher and SME account Workspaces are available.
  Scientific Workflows TPU
 
 

Stage 4

At a certain threshold, Pipi 10 will come into being, creating many more possibilities.

Using Google Blogger API v3

Mike's Notes

On a Sandy Beach is a publication of Ajabbi Research.

Changes needed

Enable other people at Ajabbi Research to also contribute to On a Sandy Beach using the Workspaces for Research UI.

It looks very straightforward. This job will be done once the Workspaces for Research are available for researchers to use.

Preparation

Last year, all existing blog posts were reformatted.

New setup

The Pipi CMS Engine (cms) will format, store in a database, and export content to On a Sandy Beach, hosted on Google Blogger, using the Blogger API ver 3.

Either XML/Atom or JSON can be used.

Steps

  1. Import the existing blog posts into the CMS Engine via the Blogger API
  2. Reformat every post (see 4th resource link below)
  3. Store in the CMS database
  4. Render posts
  5. Export back to Blogger via the Blogger API.
  6. All future posts will be created by a human using a workspace, transferred to the CMS Engine, processed, and then published to Google Blogger.

Notes

Here are some initial notes taken from the Google Blogger API documentation and other sites, tweaked using Gemini and rewritten by Grammarly.

These notes will be presented using slides at tomorrow night's online Open Research Group meeting.

Resources

References

  • Reference

Repository

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

Last Updated

09/02/2026

Using Google Blogger API v3

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

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

Blogger supports manual import and export of blog content via the Blogger dashboard or the Blogger API. The export file format for both methods is Atom, an XML-based format that includes all posts and comments. 

Blogger API for Import/Export

Developers can use the Blogger API (v3 is the current version) to programmatically manage blog content. The export file generated via the manual process uses the same Atom format as the API's feed requests. 

Key Points for API Use

  • Authentication: All operations for private data (including import/export) require authentication, typically using OAuth 2.0.
  • Format: The API uses REST APIs and JSON for standard operations. The specific import/export functions rely on the raw XML/Atom format described in the developer guides.
  • Functionality: The API allows retrieving, creating, updating, and deleting posts, comments, and pages, enabling the creation of custom import/export tools. For example, you can use API clients for Python, Java, or Node.js to manage content programmatically.
  • Custom Import Scripts: Developers can write scripts (e.g., in PHP or Python) to import content from other sources into Blogger via the API, which involves parsing the source data and making POST requests to Blogger API endpoints. 

For detailed API documentation, refer to the Blogger API Developer site.

REST

The Blogger API is a RESTful interface provided by Google that allows developers to integrate Blogger content and functionality into their own applications. It enables programmatic access to resources such as blogs, posts, comments, pages, and users via HTTP requests and JSON. 

Key Features and Concepts

  • Resources: The API revolves around five core resource types:
    • Blogs: The central container for all content and metadata.
    • Posts: The primary published content items, meant to be timely.
    • Comments: User reactions to specific posts.
    • Pages: Static content (e.g., about me, contact info).
    • Users: Represents a non-anonymous person interacting with Blogger, as an author, admin, or reader.
  • Operations: Developers can perform various operations on these resources, including list, get, insert (create), update, patch, and delete.
  • Authentication:
    • Public Data: Requests for public data (e.g., retrieving a public blog post) only require an API key.
    • Private Data: Operations involving private user data (e.g., creating a post, editing a comment) must be authorised using OAuth 2.0 tokens.
  • API Version: The latest recommended version is Blogger API v3. Support for the older v2.0 API ended on September 30, 2024, so applications must be updated to continue functioning. 

How to Access the API

Google recommends using their client libraries, which handle much of the authorisation and request/response processing for you. Libraries are available for a variety of programming languages: 

  • Go
  • Java (get started with the Java client library)
  • JavaScript
  • .NET (install the Google APIs NuGet package)
  • Node.js
  • PHP
  • Python (install the client library using pip install google-api-python-client)
  • Ruby 

Alternatively, you can interact with the API directly using RESTful HTTP requests. The Google APIs Explorer tool lets you test API calls in your browser. 

  • Pipi API Engine (api)  using CFML
  • BoxLang API using BX

For full documentation and developer guides, visit the official Blogger API documentation site on Google for Developers. 

Older Data API (v1/v2) Format: Atom XML 

The previous versions of the Blogger API relied heavily on the Atom Publishing Protocol (AtomPub) and Google Data API feeds for managing blog content. The API used standard HTTP methods (GET, POST, PUT, DELETE) to transport Atom-formatted XML payloads. 

Important: Support for the v2.0 Google Data API ended on September 30th, 2024, so applications must use the latest version to continue functioning. 

Exporting and Accessing Feeds via XML

Blogger still uses Atom XML for blog syndication and content backup: 

  • Public Blog Feed: Every Blogger blog has a public Atom feed, typically at an address like yourblogname.blogspot.com/feeds/posts/default or://yourblogname.blogspot.com.
  • Content Backup: Users can back up their blog's posts and comments as a single .xml file from the Blogger dashboard.

    • Sign in to Blogger.
    • Select your blog.
    • Go to Settings > Manage Blog.
    • Click Back up content and Download XML file. 
    • This downloaded file is in a specific Atom format for import and export. 

REST in the Blogger API

The supported Blogger operations map directly to REST HTTP verbs, as described in Blogger API operations.

The specific format for Blogger API URIs are:

  • https://www.googleapis.com/blogger/v3/users/userId
  • https://www.googleapis.com/blogger/v3/users/self
  • https://www.googleapis.com/blogger/v3/users/userId/blogs
  • https://www.googleapis.com/blogger/v3/users/self/blogs
  • https://www.googleapis.com/blogger/v3/blogs/blogId
  • https://www.googleapis.com/blogger/v3/blogs/byurl
  • https://www.googleapis.com/blogger/v3/blogs/blogId/posts
  • https://www.googleapis.com/blogger/v3/blogs/blogId/posts/bypath
  • https://www.googleapis.com/blogger/v3/blogs/blogId/posts/search
  • https://www.googleapis.com/blogger/v3/blogs/blogId/posts/postId
  • https://www.googleapis.com/blogger/v3/blogs/blogId/posts/postId/comments
  • https://www.googleapis.com/blogger/v3/blogs/blogId/posts/postId/comments/commentId
  • https://www.googleapis.com/blogger/v3/blogs/blogId/pages
  • https://www.googleapis.com/blogger/v3/blogs/blogId/pages/pageId

The full explanation of the URIs used and the results for each supported operation in the API is summarised in the Blogger API Reference document.

Examples

List the blogs that the authenticated user has access rights to:

  • GET https://www.googleapis.com/blogger/v3/users/self/blogs?key=YOUR-API-KEY

Get the posts on the code.blogger.com blog, which has blog ID 3213900:

  • GET https://www.googleapis.com/blogger/v3/blogs/3213900?key=YOUR-API-KEY

REST from JavaScript

You can invoke the Blogger API from JavaScript using the callback query parameter and a callback function. When the browser loads the script, the callback function is executed, and the response is passed to it. This approach allows you to write rich applications that display Blogger data without requiring server-side code.

The following example retrieves a post from the code.blogger.com blog, after you replace YOUR-API-KEY with your API key.

<html>
  <head>
    <title>Blogger API Example</title>
  </head>
  <body>
    <div id="content"></div>
    <script>
      function handleResponse(response) {
        document.getElementById("content").innerHTML += "<h1>" + response.title + "</h1>" + response.content;
      }
    </script>
    <script     src="https://www.googleapis.com/blogger/v3/blogs/3213900/posts/8398240586497962757?callback=handleResponse&key=YOUR-API-KEY"></script>
  </body>
</html>

Data format

JSON (JavaScript Object Notation) is a common, language-independent data format that provides a simple text representation of arbitrary data structures. For more information, see json.org.

Blogger API operations

You can invoke a number of different methods on collections and resources in the Blogger API, as described in the following table.

Operation Description REST HTTP mappings
list Lists all resources within a collection. GET on a collection URI.
get Gets a specific resource. GET on a resource URI.
getByUrl Gets a resource, looking it up by URL. GET with the URL passed in as a parameter.
getByPath Gets a resource by looking it up by its path. GET with the Path passed in as a parameter.
listByUser Lists resources owned by a User. GET on a user owned collection.
search Search for resources, based on a query parameter. GET on a Search URL, with the query passed in as a parameter.
insert Create a resource in a collection. POST on a collection URI.
delete Deletes a resource. DELETE on a resource URI.
patch Update a resource, using Patch semantics. PATCH on a resource URI.
update Update a resource. PUT on a resource URI.

The table below shows which methods are supported by each resource type. All list and get operations on private blogs require authentication.

Resource Type Supported Methods
list get getByUrl getByPath listByUser search insert delete patch update
Blogs N Y Y N Y N N N N N
Posts Y Y N Y N Y Y Y Y Y
Comments Y Y N N N N N N N N
Pages Y Y N N N N N N N N
Users N Y N N N N N N N N

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.

This copy of the issue will be updated with additional information as it becomes available. Check the Last Updated date given below.

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

31/03/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-2026)

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 containing static HTML web pages for testing. Each workspace had a ribbon menu and used iframes to organise navigation and content. Testing is successful.

The  industry-based enterprise workspaces created for testing were:

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

Workspace Version 2 (April 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
Setting up data centre automation has revealed that workspace deployments need to be performed in this order of account types due to the permissions cascade.
  • Agent Accounts (to admin Pipi)
  • Researcher Accounts (to edit UoM, ontologies and physical laws)
  • Developer Accounts (to create enterprise workspaces)
  • Personal Accounts (to sort out personal profiles - UI fonts, etc)
  • Enterprise Accounts (to test and use the system for work)
  • etc

Workspace Version 3 (May 2026)

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

  • Test
  • Feedback

Workspace Version 4 (June 2026)

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 (July 2026)

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.

Workspace Version 6

The Render Engine (rnd), Form Engine (frm) and Docs Engine (doc) use databases to generate a complete HTML workspace demo with connected initial developer documentation rendered without errors.

  • Test
  • Feedback

Workspaces for Pipi & Developers

Working Workspaces for System Admin and DevOps use are deployed in the Pipi Core Data Centre. This will speed up development and production x10.

Then

The process of providing cloud workspaces for customers will begin.

Whaikaha Access Activator

An application to attend the 8-week Whaikaha Access Activator 2026 May intake is being submitted to kick this off. Using the Govt.UK Design System as an example, a simple paper-based process to design and test workable UI templates for;

  • Autism
  • Colour-blind
  • Irlen
  • Dyslexia
  • Physical or Motor Disability
  • Epilepsy
Blind and deaf folks will be catered for with later separate projects.

Workspaces for Agents

Mike's Notes

This is where I will keep detailed working notes on creating Workspaces for Agents. Eventually, these will become permanent, better-written documentation stored elsewhere. Hopefully, someone will come up with a better name than this working title.

This replaces the coverage in Industry Workspace dated 13/10/2025.

Testing

The current online mockup is version 3 and will be updated frequently.If you are helping with testing, please remember to delete your browser cache so you see the daily changes. Eventually, a live demo version will be available for field trials.

Learning

(To come)

Why

(To come)

Resources

References

  • Reference

Repository

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

Last Updated

2/01/2026

Workspaces for Agents

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

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

Open-source

This open-source SaaS cloud system will be shared on GitHub and GitLab.

Dedication

This workspace is dedicated to the life and work of ??.

Person

Source:

" - Wikipedia


Change Log

Ver 3 includes config and tools.

Existing products

Features

This is a basic comparison of features in alternative software.

[TABLE]

Data Model

words

Database Entities

  • Facility
  • Party
  • etc

Standards

The workspace must comply with all applicable international standards.

  • (To come)

Data Centre Variables

Source: Krobar.ai simulation model (beta)

Node Name Type Estimates / Formula
Potential Customers Input Variable discrete_normal distribution
Server density per rack Input Variable discrete_normal distribution
Agreement conversion rate Input Variable beta distribution
Racks per agreement Input Variable discrete_normal distribution
Customer provisions virtual servers Calculation Step binomial(round(max(0,average(Market demand,Potential Customers))),average(Provider evaluation rate,Evaluation Rate,Evaluation rate))
Total revenue Calculation Step Server lease cost
Networking revenue per server Input Variable Normal(μ=200.0, σ=60.790273556231)
Evaluation Rate Input Variable beta distribution
Agreement Conversion Rate Input Variable beta distribution
Average Servers per Rack Input Variable discrete_normal distribution
Racks per Agreement Input Variable discrete_normal distribution
Monitoring & support Calculation Step Servers installed * Monitoring hours per server
Lease agreement conversion rate Input Variable beta distribution
Networking cost per server Input Variable Normal(μ=65.0, σ=21.27659574468085)
Average Racks per Agreement Input Variable discrete_normal distribution
Market demand Input Variable Normal(μ=2750.0, σ=3335.8549916376046)
Servers per Rack Input Variable discrete_normal distribution
Power costs Calculation Step Servers installed * Power cost per server + Fixed power costs
Storage revenue per server Input Variable Normal(μ=175.0, σ=75.98784194528875)
Evaluation rate Input Variable beta distribution
Servers per rack Input Variable discrete_normal distribution
Space and power provisioned Calculation Step round(max(0, Lease agreement signed) * average(Racks per agreement,Average Racks per Agreement,Racks per Agreement))
Lease agreement signed Calculation Step binomial(round(max(0, Customer evaluates providers)), average(Lease agreement conversion rate,Agreement Conversion Rate,Agreement conversion rate))
Cooling costs Calculation Step Servers installed * Cooling cost per server + Fixed cooling costs
Provider evaluation rate Input Variable beta distribution
Storage cost per server Input Variable Normal(μ=70.0, σ=30.3951367781155)
Total operating cost Calculation Step Power costs+Cooling costs+Monitoring & support+Server lease cost
Customer evaluates providers Calculation Step binomial(round(max(0, average(Market demand,Potential Customers))), average(Provider evaluation rate,Evaluation Rate,Evaluation rate))
Networking revenue Calculation Step Customer provisions virtual servers*Networking revenue per server
Server lease cost Calculation Step Servers installed * Depreciation cost per server
Networking cost Calculation Step Customer provisions virtual servers*Networking cost per server
Profit (pre-tax) Calculation Step Total revenue-Total operating cost
Storage revenue Calculation Step Customer provisions virtual servers*Storage revenue per server
Storage cost Calculation Step Customer provisions virtual servers*Storage cost per server
Fixed power costs Input Variable Normal(μ=12500.0, σ=11119.516638792014)
Fixed cooling costs Input Variable Normal(μ=9000.0, σ=8895.613311033612)
Backup revenue per server Input Variable Normal(μ=175.0, σ=185.32527731320025)
Backup cost per server Input Variable Normal(μ=27.5, σ=33.35854991637604)
DR revenue per server Input Variable Normal(μ=350.0, σ=370.6505546264005)
DR cost per server Input Variable Normal(μ=85.0, σ=96.36914420286412)
Average Power Consumption per Server Input Variable Normal(μ=0.425, σ=0.2594553882384803)
Power Cost per kWh Input Variable Normal(μ=0.13, σ=0.07413011092528009)
Hours per Period Input Variable discrete_normal distribution
Average Cooling Cost per Server per Period Input Variable Normal(μ=25.0, σ=22.239033277584028)
Server Purchase Cost Input Variable Normal(μ=5000.0, σ=4447.806655516806)
Server Useful Life (Periods) Input Variable discrete_normal distribution
Monitoring Hours per Server per Period Input Variable Normal(μ=2.25, σ=2.5945538823848033)
Renewal Rate Input Variable beta distribution
Lease cost per server per period Input Variable Normal(μ=1250.0, σ=1111.9516638792015)
Depreciation cost per server Input Variable Normal(μ=1100.0, σ=1334.3419966550418)
Monitoring hours per server Input Variable Normal(μ=55.0, σ=66.71709983275208)
Renewal rate Input Variable beta distribution
Power cost per server Input Variable Normal(μ=1100.0, σ=1334.3419966550418)
Cooling cost per server Input Variable Normal(μ=550.0, σ=667.1709983275209)
Servers installed Input Variable discrete_normal distribution
Depreciation Cost per Server Input Variable Normal(μ=1900.0, σ=1630.862440356162)
Monitoring Hours per Server Input Variable Normal(μ=55.0, σ=66.71709983275208)
Power Cost per Server Input Variable Normal(μ=800.0, σ=593.0408874022407)
Fixed Power Costs Input Variable Normal(μ=30000.0, σ=29652.04437011204)
Cooling Cost per Server Input Variable Normal(μ=400.0, σ=296.52044370112037)
Fixed Cooling Costs Input Variable Normal(μ=17500.0, σ=18532.527731320024)
Backup revenue Calculation Step Customer provisions virtual servers*Backup revenue per server
Backup cost Calculation Step Customer provisions virtual servers*Backup cost per server
Disaster recovery revenue Calculation Step Customer provisions virtual servers*DR revenue per server
Disaster recovery cost Calculation Step Customer provisions virtual servers*DR cost per server
Review and renew/cancel Calculation Step binomial(round(max(0, Lease agreement signed)), Renewal rate)

Simulation notes


Support

(To come)

Workspace navigation menu

This default outline needs significant work. The outline can be easily customised by future users via drag-and-drop and tick boxes to toggle features on and off.

  • Agent Account
    • Applications
      • Agent
        • ajx
        • alg
        • api
        • apl
        • aui
        • bor
        • brs
        • cde
        • cfg
        • cgi
        • cmd
        • cms
        • cnd
        • cnf
        • cny
        • cor
        • cpt
        • cpx
        • css
        • cte
        • ctx
        • cui
        • dao
        • dmn
        • dob
        • doc
        • dom
        • dpl
        • dsg
        • dta
        • dvp
        • eml
        • eng
        • fac
        • ffg
        • fil
        • fld
        • fnt
        • ftp
        • fui
        • int
        • iot
        • ips
        • kwd
        • lng
        • lnk
        • lob
        • loc
        • log
        • lop
        • lui
        • mim
        • mle
        • mod
        • mpg
        • msg
        • mta
        • mtr
        • nde
        • nsp
        • nte
        • obj
        • ont
        • oop
        • par
        • pge
        • phl
        • pkg
        • pln
        • plt
        • plu
        • plw
        • prm
        • pub
        • pui
        • rbn
        • rgn
        • rle
        • rls
        • rnd
        • scl
        • scr
        • sgp
        • spt
        • ssn
        • sta
        • sys
        • tem
        • tra
        • trn
        • tsk
        • udt
        • usa
        • usi
        • usp
        • usr
        • var
        • vct
        • ver
        • vfy
        • wai
        • wbs
        • wfl
        • wki
        • wsp
      • As a Platform
        • Cloud Platform
          • Alibaba Cloud
          • AWS
          • Azure
          • Cloudflare
          • Container Hosting Service
          • Couchbase
          • DigitalOcean
          • Google Cloud
          • Hetzner Cloud
          • IBM Cloud
          • JFrog
          • Linode
          • Netlify
          • OpenShift
          • Oracle Cloud
          • OVHcloud
          • Render
          • Salesforce
          • Tencent Cloud
          • Vercel
          • Wasabi
          • Zeabur
      • Data Centre (v2)
        • Cooling
        • Fire
        • Power
          • Supply
          • UPS
        • Security
      • Mission Control
        • Status
    • Customer (v2)
      • Bookmarks
        • (To come)
      • Support
        • Contact
        • Forum
        • Live Chat
        • Office Hours
        • Requests
        • Tickets
      • (To come)
        • Feature Vote
        • Feedback
        • Surveys
      • Learning
        • Explanation
        • How to Guide
        • Reference
        • Tutorial
    • Settings (v3)
      • Account
      • Billing
      • Deployments
        • Workspaces
          • Modules
          • Plugins
          • Templates
            • Mission Control
            • Researcher
            • Librarian
            • Training
          • Users