Themelio compatibility reference. This page describes the retained Themelio implementation or its historical design. Check the parallel-operation guide before applying it to the current platform.

#Core Specifications

Version: 0.2 | Status: Under Review | Date: 2026-2-20

Project: Themelio / Daedalus

This page describes the Core Specifications based on the high-level write up of use cases written by Panos Louridas, and reviewed and commented by the technical staff of GRNET and NTUA teams involved in the project.

#Executive Vision

The Themelio software stack aims to bridge the gap between different layers of AI infrastructure and their operations. These environments are the High-Performance Computing (HPC) and Cloud-Native infrastructures, fundamentally used for different phases of AI and ML operations.

Read more about Themelio and the vision of Pharos AI.

#Core Requirements

People that use Artificial Intelligence today fall into different categories with corresponding different needs:

• Users that want to use existing models; typically, they will fine-tune a model, or even use it as it is, to run an experiment. The novelty lies in the use of the model, the dataset they will provide, and the experimental hypothesis.

• Users that want to build models; typically start from an existing architecture, or even an existing model, which will require extensive training. The novelty lies in the relative strength of the new model with respect to other models, where strength may be measured on standard benchmarks, localization, energy consumption, resource requirements, etc.

Themelio unifies these two different aspects of Machine Learning. First, facilitate the researcher and scientist working with new ML techniques or training the next generation of ML models. It also provides a "Zero-Friction" environment where users never manage OS layers or drivers, yet retain full control over the compute stack.

• Users should not have to install operating systems.
• Users should not have to install drivers.
• Users should be able to install required libraries, if they are not already installed, with minimal hassle; if libraries require compilation, the compiler should be already installed in the system.

Themelio strives to balance between easy-of-use and granular control of complex ML pipelines and operations, with the goal of advancing ML for everyone and bridging the gap between science and industry.

#Operating Party

Themelio is meant to be run by a legal entity that has a lot of hardware and financial resources. In the case of Pharos AI, it will be run by a separate entity, but the goal is for Themelio to be portable and usable by other research and academic institutions.

#Themelio Project

A Themelio Project is the primary organizational unit in the platform. It groups people and resources around a shared scientific goal — a training campaign, an experiment series, or a data processing pipeline — for a defined timeframe and with allocated hardware resources.

Concretely, each approved Themelio Project corresponds to six provisioned subsystems:

1. One Waldur order — the central record that tracks membership, quotas, and billing, and drives provisioning of all other subsystems
2. One Kubernetes namespace with ResourceQuotas (CPU, RAM, GPU, storage), plus per-user ServiceAccount, RoleBinding, and Role for scoped access
3. One Kubeflow profile for interactive notebooks and pipeline execution
4. One MLflow workspace for experiment tracking, metric logging, and artifact management
5. One GitLab subgroup per resource type (e.g. models/{slug}, datasets/{slug}, spaces/{slug}), with an attached S3 storage bucket. Storage quotas are enforced by Ceph/RADOS or an interim storage site agent
6. One HPC Slurm account with per-user sub-accounts, configured with QOS and TRES limits for quota enforcement per group and per user

This 1:1 mapping ensures that every project gets a fully isolated environment across compute, storage, ML tooling, and repositories from the moment it is approved.

Daedalus HPC resources require special handling during allocation. Daedalus has approximately 765,000 node hours for HPC per year, shared between EuroHPC, national projects, and the academic community. Each Themelio Project should have its own scientific rationale and describe end goals achievable in its lifetime. Proposals should be realistic — for example, requesting half of the Daedalus computing power for a very limited scientific scope would not be approved.

Themelio Projects help both the end users and the administrators to:

• Provide a user-friendly way for Project Owners to get their grant approved in order to get access to Daedalus hardware
• Access hardware resources, both storage and computing (Daedalus HPC and cloud-native Kubernetes)
• Access software resources that use allocated hardware resources, e.g. ML-optimized git repositories, MLflow, Kubeflow
• Set a specific timeframe for allocating these resources
• Determine and enforce the usage quota limits for each project, and manage their billing

#Storage

Storage is an integral point for Themelio. Chronologically, this is the first hardware resource that Project Members will use.

Typically they will first and foremost want to upload their own dataset, or even a model forked from Hugging Face, as well as a script for training.

Access to Storage should be prolonged for a grace period of few months after the Themelio Project is expired, and the Project Members should be contacted many times before we proceed with the deletion of their data.

#Node hours

HPC environments are special cases of computing. Typically, the usage is measured in node hours, since the bulk of the processing is done in compute nodes, collaborating as part of a distributed systems, enabling scalability, fault tolerance, and parallel processing.

On the HPC side, each Themelio Project maps to a Slurm account. Slurm accounts are the equivalent of projects or teams — they are organized hierarchically and, combined with QOS (Quality of Service) and TRES (Trackable Resources) limits, provide full quota enforcement per group and per user. There is no separate "namespace" concept in Slurm; accounts fill that role.

#Compute Quotas (k8s)

#Resources

Themelio Projects can have Resources hosted on the Storage allocated to said project. Themelio Project has its own private Catalogue of resources. At some point, Project Owners or Pharos Admins can choose to graduate a Resource and showcase it to Themelio Explore.

#Themelio Catalogue

The Themelio Catalogue is a directory of different Resources for a Themelio Project, hosted inside Themelio as Gitlab repositories.

Everything on Themelio is a repository — a version-controlled collection of files backed by Git. What makes each resource type distinct is how the platform interprets and presents the contents: a model repository gets inference deployment options, a dataset repository gets size metadata and format tags, a space repository gets deployed as a running application.

#Models

A model repository holds trained ML model weights, configuration files, and a model card. Users can browse the files, inspect the commit history, and — when the model is deployed — send inference requests to a live endpoint.

What's in a model repo:

• Model weights (often stored via Git LFS for large files)
• Configuration files (config.json, tokenizer files, etc.)
• A README serving as the model card
• Metadata: tags, license, framework, task type

What you can do:

• Browse and download model files
• Deploy the model as an inference endpoint (creates a Kubernetes pod with HTTP routing)
• Monitor deployment status and logs
• Fork the model to your own namespace
• Run custom actions defined in actions.yaml

#Datasets

A dataset repository stores data files — CSVs, Parquet files, images, audio, or any other format — along with documentation and metadata. Git LFS handles large files so that the repository remains cloneable without downloading the full dataset.

What's in a dataset repo:

• Data files (potentially large, stored via Git LFS)
• A README describing the dataset, its format, and intended use
• Metadata: tags for data modality (text, image, audio, tabular), license, size

What you can do:

• Browse the file tree and inspect individual files
• Clone the repository and pull data via Git LFS
• Tag and categorize by data type, task, and license
• Fork the dataset to your namespace

#Spaces

A space is a deployed interactive application. You write the code in a Git repository, and the platform builds and runs it as a containerized web app with a public URL.

Supported frameworks:

• Gradio — Python-based ML demos
• Streamlit — Data apps and dashboards
• Docker — Any containerized application
• Static — Plain HTML/CSS/JS sites

What's in a space repo:

• Application source code
• A README or configuration specifying the framework
• Optional environment variables and secrets

What you can do:

• Deploy the space to get a live URL
• Link a space to a running inference endpoint (the space can call the model)
• Configure environment variables and secrets
• Monitor deployment logs and status
• Set resource limits (CPU, memory, GPU)

#Recipes

A recipe is a reusable workflow template — a step-by-step guide or automation script that shows how to accomplish a specific ML task. Recipes are documentation-first: they explain a process and provide the code to execute it.

What's in a recipe repo:

• Workflow scripts or notebooks
• A README walking through the steps
• Metadata: tags, description, related models or datasets

What you can do:

• Browse and follow the recipe
• Fork it to your namespace and adapt it
• Search recipes by task or tag

#Upskillings

An upskilling resource is educational content — tutorials, training materials, or learning paths for ML practitioners. They follow the same Git-backed structure but are organized and tagged for learning rather than production use.

What's in an upskilling repo:

• Tutorial content (Markdown, notebooks, code samples)
• A README with learning objectives
• Metadata: tags, difficulty level, prerequisites

What you can do:

• Browse the content online
• Clone and work through it locally
• Search by topic or skill level

#Generic Repositories

For anything that doesn't fit the other categories, generic repositories provide standard Git hosting within the platform. They don't get type-specific features (no deployment, no dataset metadata) but they benefit from the same authentication, access control, and collaboration tools.

#Visibility

These repositories can offer different levels of access to satisfy different project needs for each phase of the Project lifecycle.

• public - anybody can see these, doesn't require authentication
• private - only Project Members can see these, requires authentication and access to the Project's resources
• gated - anybody can see an overview of what this resource is about (model card) but Users can request access after agreeing to ToU and NDA compliance

#Themelio Explore

Themelio Explore is a directory listing of all public, gated, or otherwise promoted Resources from any Themelio Project. This means that Pharos Admins will be able to curate a list of Machine Learning Resources for users that are not Project Members or any public users visiting from the Internet (not authenticated).

#User Personas

Given the Core requirements discussed in the previous section, Themelio must cater to many distinct categories of users - hereinafter “User Personas“, while also ensuring that the services it offers are comparable to the services that are available from providers like Microsoft, Amazon, and Google, since our users already work with these tools and we aspire to provide them a more simple and streamlined service.

#Project Member

This user persona can be at least one of the following sub-personas.

• ML Researcher requires bare-metal throughput, batch scheduling (Slurm), and massive hardware resources for training foundation models. This category of users is more likely to work by programming and scheduling computationally intensive, long-running jobs; also planning meticulous training, post-training, and evaluation procedures.
• Applied ML Engineer requires agility, interactive notebooks (Kubeflow), and API-driven inference typical of hyperscalers (AWS/Azure). This category of users is more likely to work interactively with the models and they are used to rapid experimentation with small datasets and a rich user interface experience that combines coding with documentation and visualization, typically provided by interactive notebooks. This persona also includes Students and other academic staff that simply use ML models to advance their work.

#Project Owner

This user persona requires a way to efficiently propose new projects, manage any project that they lead, adding or removing project members, and monitor the project usage.

#Administrator

This user persona requires an elevated privilege access. Each service will have its own group of whitelisted admins, eg. Pharos AAI, Waldur, Gitlab etc. This user type manages infra and quotas, IdP clients/claims, triggers workspace bootstrap (repo, Kubeflow profile multi-tenant, MLflow single tenant), and approves resource requests. This is a special type of user account, whitelisted for trusted personnel of the Operating Party that manages the installation of the Themelio Software.

#Scope & Functional Overview

Page source

Source snapshot · Revision f928834c8.