Showing posts with label model. Show all posts
Showing posts with label model. Show all posts

Biological Brains Inspire a New Building Block for Artificial Neural Networks

Mike's Notes

Back propagation is based on a flawed model of how the brain works. This model is based on a more current understanding of how the brain works.

I'm impressed by the work of the Flatiron Institute in New York. It would be great for Ajabbi Research to collaborate with.

Resources

References

  • A Logical Calculus of the ideas Imminent in Nervous Activity. By Warren McCulloch, Walter Pitts and Walter Pitts. 1943. University of Illinois at Chicago.
  • On Computable Numbers by Alan Turing. 1936. Proceedings of the London Mathematical Society.

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Announcements From the Simons Foundation
  • Home > Ajabbi Research > Library > Authors > Alan Turing
  • Home > Ajabbi Research > Library > Authors > John von Newmann
  • Home > Handbook > 

Last Updated

14/02/2026

Biological Brains Inspire a New Building Block for Artificial Neural Networks

By: 
Simons Foundation: 26/01/2026

.

While artificial intelligence systems have advanced tremendously in recent years, they still lag behind the performance of real brains in reliability and efficiency. A new type of computational unit developed at the Flatiron Institute could help close that gap.

New research is exploring how to improve neural networks using components more like those in real brains. Alex Eben Meyer for Simons Foundation

While artificial neural networks are revolutionizing technology and besting humans in tasks ranging from chess to protein folding, they still fall short of their biological counterparts in many key areas, particularly reliability and efficiency.

The solution to these shortcomings could be for AI to act more like a real brain. Computational neuroscientists at the Simons Foundation’s Flatiron Institute in New York City have drawn lessons from neurobiology to enhance artificial systems using a new type of computational component that is more akin to those found in real brains. The researchers presented their work at the annual conference of the Association for the Advancement of Artificial Intelligence (AAAI) in Singapore on January 23.

“Artificial intelligence systems like ChatGPT — amazing as they are — are, in several respects, inferior to the human brain,” says Dmitri “Mitya” Chklovskii, a group leader in the Center for Computational Neuroscience (CCN) at the Flatiron Institute. “They’re very energy- and data-hungry. They hallucinate, and they can’t do simple things that we take for granted, like reasoning or planning,” he says. Each of these individual issues may trace back to one larger problem, he says: The foundations of these systems differ significantly from “the foundations on which the brain is built.”

The current building blocks of artificial neural networks are deeply rooted in a previous era. During that time, “the people who wanted to understand how the brain works and the people who wanted to build artificial brains or artificial intelligence were either the same people or close colleagues and collaborators,” Chklovskii says. “Then, sometime in the ’60s and ’70s, those two fields divorced and basically became fields of their own,” he says. That divergence has also led to artificial networks that are based on an outdated understanding of how biological brains function.

In the new work, Chklovskii and his colleagues revisit the fundamentals of artificial neural network architecture. For more than 10 years, Chklovskii had been on a quest for an alternative to the decades-old neural network building blocks used in machine learning. Through years of research, learning from real animal brains and innovation, Chklovskii and his team cracked the problem and found the solution he’d been dreaming of, one rooted in our modern understanding of the brain.

He and his team built a biologically inspired multilayer neural network made up of a new type of fundamental computational unit called rectified spectral units, or ReSUs. These ReSUs extract the features of the recent past that are most predictive of the near future. The ReSUs are self-supervised, meaning they control their own training of how they process data based on the information they receive, rather than relying on external instructions. ReSUs are designed to learn from constantly changing data, just as our brains learn from the real world.

This is in stark contrast to the current standard units, which are called rectified linear units (ReLUs). ReLUs, which have roots in a 1943 paper, were popularized about 15 years ago. In that paper, researchers presented “a very simple, but very primitive, model of a neuron,” Chklovskii says.

Building on that earlier model, researchers developed ReLU-based networks, which are commonly trained using a concept known as error backpropagation. This method calculates the contribution to past mistakes of each individual neuron in an artificial network, enabling the network to adjust and perform more accurately in the future. “But standard error backpropagation, as used in deep learning, is widely viewed as biologically implausible, and there is no evidence that the brain implements it in that form,” Chklovskii says.

Unlike the ReLUs, the novel ReSUs “actually care about the history of the input” they receive, says Shanshan Qin, a former CCN research scientist who is now an assistant professor of computational neuroscience and biophysics at Shanghai Jiao Tong University in China and lead author of the article that accompanied the AAAI presentation. That alternative setup, which doesn’t involve backpropagation, means ReSU networks are far closer analogs of what actually happens in the brain, he says.

The team’s ReSU neural network succeeded in a proof-of-principle test. The researchers created videos comprised of photographic images that drift in different directions, which were then used to train the network. “Imagine you are sitting on a train looking out the window. The trees, mountains, and houses outside appear to ‘slide’ horizontally across your vision. That sliding movement is a ‘translation,’” Qin says.

They demonstrated that a network trained on these videos exhibited learned two key features that resemble components of the fruit fly (Drosophila) visual system. The first feature is temporal filters, which sift through the input history that real or artificial neurons receive. These filters select certain signals to emphasize and others to ignore based on when the signals were received and other patterns that emerge within the system. Motion-selective units are the second key feature. These units only fire when movement occurs in a certain direction.

Instead of the researchers needing to directly instruct the system through coded rules, “we gave the network a blank slate,” Qin says. “We showed it the ‘train window’ videos (translating scenes). The network realized on its own: ‘To make sense of this data, I must remember what happened a split-second ago (temporal filters), and compare neighbor to neighbor (motion selection),” he says.

If the approach can be successfully scaled up, it could perform more complex computational tasks using rules similar to those that govern how neighboring neurons learn together. The approach may also excel in situations where the program lacks supervision and is using raw data that hasn’t been labeled or given additional context, Qin says.

The work not only brings AI closer to biology, but it also helps explain how biological systems operate, Qin says. “We can explain a lot of existing experimental data in fruit fly visual systems using this architecture,” he adds.

In the future, Chklovskii, Qin and colleagues hope to build on this work by developing ReSU-based neural networks based on different sensory systems — such as those responsible for smell and hearing — in animals ranging from fruit flies to humans. Such work would help reveal how those systems operate in nature and could reveal new ways of designing neural networks, Qin says.

OntoUML/UFO Catalog

Mike's Notes

Alex told me about OntoML. Another great resource that can be used in future. Pipi uses Ontologies as constraints.

Resources

References

  • Reference

Repository

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

Last Updated

31/12/2025

OntoUML/UFO Catalog

By: 
GitHub: 31/12/2025

OntoUML Meta Model

The FAIR Model Catalog for Ontology-Driven Conceptual Modeling Research, commonly referred to as OntoUML/UFO Catalog, is a structured and open-source catalog that contains OntoUML and UFO ontology models. It was conceived to allow collaborative work and to be easily accessible to all its users.

The goal of the OntoUML/UFO Catalog is to support empirical research in OntoUML and UFO, as well as for the general conceptual modeling area, by providing high-quality curated, structured, and machine-processable data on why, where, and how different modeling approaches are used.

The catalog offers a diverse collection of models, created by modelers with varying modeling skills, for a range of domains and different purposes. The models are available in machine-readable formats (JSON and Turtle) and are accessible via permanent identifiers.

The catalog has two data services through which we store and publish its content: this Git repository for data storage, and a FAIR Data Point (FDP) for data discovery. While we outline the FDP in this document, the focus of this documentation is on the catalog’s repository.

An overview of the catalog is provided by a dashboard at the persistent URL http://w3id.org/ontouml-models/dashboard.

Table of Contents

  • OntoUML/UFO Catalog
    • Table of Contents
    • Catalog’s Content
      • Data Organization
      • Catalog Releases
      • Data Schemas
        • OntoUML Metamodel
        • OntoUML Schema
        • Models in Linked Data
      • Metadata
      • FAIR Data Point: The Data Discovery Service
    • Catalog's Persistent URLs
    • How to Contribute
      • Contribute by Submitting an Ontology
      • Other Ways to Contribute
    • Relevant Associated Works
    • Catalog administration
    • How to Cite this Catalog
    • Acknowledgements
    • License disclaimer

Catalog’s Content

Data Organization

This repository contains OntoUML and UFO models and all their distributions, serving as our de facto data storage service. We describe below the catalog's repository structure and the files it contains:

/ontouml-models
|--- catalog.ttl
+--- /models
|     +--- /"model-directory-1"
|          |--- ontology.vpp
|          |--- ontology.json
|          |--- ontology.ttl
|          +--- /original-diagrams
|          |    |--- "diagram-1".png
|          +--- /new diagrams
|          |    |--- "diagram-1".png
|          |--- metadata.ttl
|          |--- metadata-vpp.ttl
|          |--- metadata-json.ttl
|          |--- metadata-turtle.ttl
|          |--- metadata-png-o-"diagram-1".ttl
|          |--- metadata-png-n-"diagram-1".ttl
+--- /shapes
     |--- Resource-shape.ttl
     |--- Dataset-shape.ttl
     |--- Catalog-shape.ttl
     |--- SemanticArtefact-shape.ttl
     |--- Distribution-shape.ttl

  • catalog.ttl: the Turtle file that contains all metadata about the catalog in linked data format.
  • /models: the directory containing all cataloged models.
  • /"model-directory-1": a directory containing a single model and distributions that materialize it. Most model directories' names are composed of information about the model itself, such as the name of the first author, the year of publication, or the name of the model.
  • ontology.*: the file generated by the modeling tool used to create or reproduce the model. The modeling tool in question must be able to serialize the model in JSON format in conformance with the Ontouml Schema (e.g., the Visual Paradigm UML CASE, .vpp extension, with the OntoUML Plugin for Visual Paradigm).
  • ontology.json: the JSON serialization of the model in conformance with the Ontouml Schema.
  • ontology.ttl: the Turtle serialization of the model in linked data format described with the OntoUML Vocabulary. This file is automatically generated after the JSON serialization.
  • /original-diagrams: the directory containing all diagrams of the model in PNG format. These diagrams are either (i) created from the original file generated by the modeling used, or (ii) extracted from the source where the model was published (e.g., screenshots from the original publication).
  • /new-diagrams: the directory containing all diagrams of the model in PNG format.
  • metadata.ttl: the Turtle file that contains all metadata about the model in linked data format.
  • metadata-vpp.ttl: the Turtle file that contains all metadata about the model file, the ontology.vpp distribution, in linked data format. This file is automatically generated.
  • metadata-json.ttl: the Turtle file that contains all metadata about the model's JSON serialization file, the ontology.json distribution, in linked data format. This file is automatically generated.
  • metadata-turtle.ttl: the Turtle file that contains all metadata about the model's Turtle serialization file, the ontology.ttl distribution, in linked data format. This file is automatically generated.
  • metadata-png-o-"diagram-1".ttl: a Turtle file that contains all metadata about one of the model's original diagrams, a /original-diagrams/"diagram-1".png distribution, in linked data format. A file is automatically generated for each original diagram.
  • metadata-png-n-"diagram-1".ttl: a Turtle file that contains all metadata about one of the model's new diagrams, a /new-diagrams/"diagram-1".png distribution, in linked data format. A file is automatically generated for each new diagram.
  • /shapes: the directory containing the SHACL shapes used in the validation of metadata schemas.
  • Resource-shape.ttl: the Turtle file that contains the SHACL shape used to validate metadata about resources of type dcat:Resource.
  • Dataset-shape.ttl: the Turtle file that contains the SHACL shape used to validate metadata about resources of type dcat:Dataset.
  • Catalog-shape.ttl: the Turtle file that contains the SHACL shape used to validate metadata about resources of type dcat:Catalog.
  • SemanticArtefact-shape.ttl: the Turtle file that contains the SHACL shape used to validate metadata about resources of type mod:SemanticArtefact.
  • Distribution-shape.ttl: the Turtle file that contains the SHACL shape used to validate metadata about resources of type dcat:Distribution.

Catalog Releases

The catalog also offers releases comprising all its data and metadata compiled into a single Turtle file. Releases are tagged after the following nomenclature <YYYY><MM><DD> and can be accessed via the permanent identifier https://w3id.org/ontouml-models/release/<release_tag>.

Data Schemas

The cataloged OntoUML and UFO models are documented in two different formats, referred to as data schemas: the OntoUML Schema and the OntoUML Vocabulary. Both formats are build upon an implementation-independent metamodel, the OntoUML Metamodel, and are equivalent in terms of the content being represented and are automatically generated by software, but tailored for their individual use cases.

OntoUML Metamodel

The OntoUML Metamodel allows its specialization on implementation-specific metamodels to be used as manipulation and exchange of OntoUML models by software agents focused on the UML features relevant to OntoUML. It covers several features of the UML metamodel related to its class diagram language, however, simplified to meet the needs of OntoUML.

OntoUML Schema

Designed to support the development of model intelligence services in OntoUML, the Ontouml Schema specializes the OntoUML Metamodel to specify how to serialize OntoUML models in JSON. In this format, OntoUML can be easily exchanged between clients and servers communicating over HTTP, with extensive support from all major tech stacks, including easy processing within browser applications.

The JSON is a format better suited for manipulation within software code than linked data formats. It supports the exchange of models between modeling tools and the OntoUML server, providing model intelligent services (e.g., model verification and transformation).

Models in Linked Data

While JSON offers a suitable solution for exchanging and manipulating models with software, the ability to query models is extremely useful for analyzing them. This is even more pronounced in the context of a catalog of models, where the significant size of the catalog enables, for example, the generation of statistical reports and the detection of recurrent patterns. The serialization of OntoUML models in a linked data format allows us to feed them to a knowledge graph and perform complex analysis using the SPARQL querying language, all with no need for additional software.

Metadata

metadata-schema

The catalog’s schema, depicted in the image above, reuses classes and properties from the following RDF/OWL vocabularies:

  • Data Catalog Vocabulary (DCAT): The central vocabulary in our metadata schema, DCAT was “designed to facilitate interoperability between data catalogs published on the Web”.
  • Dublin Core Terms (DCT): A vocabulary that defines properties to describe basic metadata of resources on the web.
  • Friend of a Friend (FOAF): A vocabulary that offers terms to describe people, groups, companies, and other types of agents.
  • Metadata for Ontology Description and Publication (MOD): A vocabulary that defines properties to describe the metadata of ontologies and other semantic artefacts.
  • Simple Knowledge Organization System (SKOS): A vocabulary for representing and linking knowledge organization systems.
  • vCard: A vocabulary to describe contact information (e.g., email, phone number).

As we could not satisfy the metadata needs of our stakeholders using the existing vocabularies alone, we complemented them with one of our own authorship, the OntoUML/UFO Catalog Metadata Vocabulary.

The OntoUML/UFO Catalog Metadata Vocabulary was created to satisfy the metadata needs of the OntoUML/UFO Catalog, complementing the catalog's schema with properties to improve the findability and reusability of the catalog and its models. The vocabulary's content can be accessed thgrough the following links:

  • Vocabulary's complete textual specification
  • Vocabulary's GitHub repository
  • Vocabulary's formal specification in Turtle syntax

The OntoUML/UFO Catalog Metamodel Vocabulary's elements are identified below by the prefix ocmv.

FAIR Data Point: The Data Discovery Service

The OntoUML FAIR Data Point is a deployment of the FAIR Data Point (FDP) reference implementation, which is a FAIR-compliant platform designed to expose semantically rich metadata of FAIR digital objects. Deployed as a web server, the FDP provides important features to the catalog, including the generation of global unique IDs, the generation of webpages for each resource in the catalog based on their semantic annotations, and the search of resources based on textual information or user-defined SPARQL queries. The FDP is automatically synchronized with the data storage, service serving as the data discovery service for the catalog.

Catalog's Persistent URLs

  • We created persistent URLs for the following resources:
  • FDP Catalog page: https://w3id.org/ontouml-models
  • GitHub repository: https://w3id.org/ontouml-models/git
  • OntoUML vocabulary: https://w3id.org/ontouml

Catalog's releases:

  • Latest release: https://w3id.org/ontouml-models/release
  • Specific release: https://w3id.org/ontouml-models/release/<release_tag>
  • <release_tag> must be substituted by a release tag string (e.g., '20230602')

Catalog Vocabulary TTL file: https://w3id.org/ontouml-models/vocabulary

Shape TTL files:

  • https://w3id.org/ontouml-models/shape/Catalog
  • https://w3id.org/ontouml-models/shape/Dataset
  • https://w3id.org/ontouml-models/shape/Distribution
  • https://w3id.org/ontouml-models/shape/Resource
  • https://w3id.org/ontouml-models/shape/SemanticArtefact

How to Contribute

Your contribution is fundamental to the catalog's success. We highly encourage authors to submit their models and tools to this catalog. With that, you will be supporting research in (ontology-driven) conceptual modeling, ontology engineering, software design, and several others.

We greatly appreciate your contribution to this project!

Contribute by Submitting an Ontology

The easiest way to contribute to this catalog is to simply send us the following:

  1. your ontology model project;
  2. the model's metadata information; and
  3. the model's associated bibliography (when available).

If you wish to contribute to this initiative by submitting your ontology, use the catalog's contribution form.

Note that anonymous ontologies are allowed in the catalog. So, if you do not want your name to be displayed in your ontology’s metadata, you just have to inform us and we will keep the model’s authorship anonymous. It is important that, in such case, you must be the owner of the ontology’s legal rights.

If you wish to contribute by submitting someone else's ontology, please chose one entry from the "Not Started" or "Started" sheets from the List of UFO and OntoUML Ontology Models. Ontologies in the Started sheet already have files available in a branch (informed in the spreadsheet), simplifying the collaboration process.

For providing high-quality data, submissions are required to comply with the defined rules to be accepted as part of the catalog. If you have any questions about submitting new models or reusing those available in this catalog, please create an issue.

Other Ways to Contribute

If you wish to contribute to this initiative by creating and reporting an application for the catalog, please inform us through the catalog's contribution form or create an issue.

If you find any problems in the repository or have ideas for its improvement, please let us know through the catalog's contribution form or by creating an issue.

Relevant Associated Works

The list of works that use the data provided by the OntoUML/UFO Catalog to test algorithms and perform other tasks grows over time. Instead of keeping a manual list in this document, we recommend you access its Google Scholar and ResearchGate citation lists to access an updated information.

Catalog administration

The OntoUML/UFO Catalog is maintained by the Semantics, Cybersecurity & Services (SCS) Group of the University of Twente, in The Netherlands. Its principal administrators are:

  • Pedro Paulo F. Barcelos [GitHub] [LinkedIn]
  • Tiago Prince Sales [GitHub] [LinkedIn]
  • Mattia Fummagali [GitHub] [LinkedIn]
  • Claudenir M. Fonseca [GitHub] [LinkedIn]

Feel free to get in contact with the administrators using the links provided. For questions, contributions, or to report any problem, you can open an issue at this repository.

How to Cite this Catalog

Please cite the OntoUML/UFO Catalog as:

  • Prince Sales, T., Barcelos, P. P. F., Fonseca, C. M., Souza, I. V., Romanenko, E., Bernabé, C. H., Bonino da Silva Santos, L. O., Fumagalli, M., Kritz, J., Almeida, J. P. A., & Guizzardi, G. (2023). A FAIR catalog of ontology-driven conceptual models. Data & Knowledge Engineering, 147, 102210. https://doi.org/10.1016/j.datak.2023.102210. Permanent URL: https://w3id.org/ontouml-models/.

For creating citations using different formats, refer to the webpage of the paper's publisher for getting the paper's complete information.

For obtaining the paper's complete BibTeX record, we recommend downloading this information on the same webpage or accessing it on the DBLP BibTeX record.

This paper reflects the state of the catalog as of June 2022.

Acknowledgements

We would like to thank all the contributors to the OntoUML/UFO Catalog, as well as all the modelers who shared their work and allowed us to include it here.

License disclaimer

The OntoUML/UFO Catalog is licensed under the Creative Commons Attribution-ShareAlike 4.0 International Public License.

Although the OntoUML/UFO Catalog is an open project with a permissive license, special attention must be given to the following licensing clauses:

  • The OntoUML/UFO Catalog is a noncommercial work created strictly for academic research purposes.
  • This license only applies to the catalog structure itself, not to the models included in the repository.
  • Information about licensing of individual ontologies included in the catalog can be found on their related metadata.yaml file.
  • The models included in the repository were obtained directly from the authors or academic sources using open or valid licensed access.
  • This license by no means overwrites the license of the models included in the repository, which maintain their original license.
  • All catalog ontologies that are without explicit licensing information on their associated metadata.yaml file must be interpreted as being private and having a restrictive license.
  • License holders sending their models to the OntoUML/UFO Catalog expressly agree that the sent content is going to be hosted and made available for other users in the terms of this license.
  • Whoever uses the OntoUML/UFO Catalog expressly understands and agrees with its licensing information.

Ontologies are going to be immediately removed from the catalog in case of a request by the original license holders. For content removal, please create an issue or report it through the catalog's contribution form.

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

Workspaces for Developers

Mike's Notes

This is where I will keep detailed working notes on creating Workspaces for Developers. 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


References

  • Reference

Repository

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

Last Updated

25/12/2025

Workspaces for Developers

By: Mike Peters
On a Sandy Beach: 25/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 Alan Turing.

Source:

"

" - Wikipedia

Change Log

Ver 3 includes config and tools.

Existing products

Features

This is a basic comparison of features in culture software.

[TABLE]

Data Model

words

Database Entities

  • Facility
  • Party
  • etc

Standards

The workspace must comply with all applicable international standards.

  • (To come)

Support

There will be extensive free documentation sets tailored for different users.

Every user account includes access to customer support when using these modules (which can be enabled or disabled in account settings). 

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.

  • Developer Account
    • Applications
      • Config(v.3)
        • API

        • Component Class 

        • Design System

        • Engine
          • 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
        • Entity Class 

        • Module 

        • Plugin
          • AddThis
          • Amazon Book
          • Apple Map
          • Apple Music
          • ArcGIS Map
          • Atlassian Analytics
          • Azure Map
          • CodePen
          • CodeSandbox
          • Confluence
          • Elfsight Weather
          • Flightradar24
          • FormBlock
          • GitHub-Embed
          • GitLab Snippet
          • Google Analytics
          • Google Calendar
          • Google Docs
          • Google Form
          • Google Map
          • Google Meet
          • Google Sheets
          • Google Slides
          • Instagram
          • IUCN Threat Status
          • Jira Advanced Roadmap
          • JSBin
          • Jupyter Notebook
          • MailChimp
          • Metservice Weather
          • Microsft Forms
          • NASA Spot the Station
          • NASA Worldview
          • NetSuite Case Form
          • NIWA CO2 Widget
          • NIWA Tide Widget
          • NIWA UV Widget
          • NIWA Weather Widget
          • Odoo Form
          • PDF
          • PostHog Analytics
          • Survey Monkey
          • Trello Board
          • Trello Card
          • TypeForm
          • Vimeo Video
          • Weather Widget
          • Wolfram Notebook
          • Yandex Map
          • Yandex Video
          • YouTube Video
          • Zoho Calendar
          • Zoho Form
          • Zoom Meeting
      • Tools
        • Build
        • Code
        • Deploy
        • Document
        • Feedback
        • Monitor
        • Operate
        • Plan
        • Release
        • Test
    • Customers (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
              • Solo
              • Team
              • DevOps
            • Users