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.
Functional Requirements
Version: 0.2 | Status: Under Review | Date: 2026-2-20
This document contains the Functional Requirements for Themelio. For complete context including executive vision, scope, and user personas, please refer to the Core Specifications and the Introduction to Themelio.
2.1. Authentication, Authorization, and Identity (AAI)
FR-AAI-01: Authentication Infrastructure
Priority: P0 (Critical)
User Problem
Users span academia (eduGAIN) and industry/independent sectors (eIDAS/TaxisNet) and need a unified login.
Description
Gateway supporting Academic login via eduGAIN and Citizen login via eIDAS through MyAccessID.
Acceptance Criteria
See User Story 1.1: Unified Login Gateway for detailed acceptance criteria:
- AC 1.1.1: User can authenticate via eduGAIN (Academic path)
- AC 1.1.2: User can authenticate via eIDAS node (Citizen path, not yet available, TBD)
- AC 1.1.3: Attributes are auto-ingested from the IdP upon successful login, to ensure access to project and resources to Project Members, and also administrator access to Administrators
- AC 1.1.4: Session is shared transparently across Gitlab, Open OnDemand, and Billing subsystems (SSO)
User Stories
2.2 Themelio Projects
FR-PRO-01: Multi-step Project Application Wizard
Priority: P0 (Critical)
User Problem
Users should be able to apply for a new project grant in order to get access to the HPC and Compute resources of DAEDALUS. Admins should be able to review project application on Waldur, instead of managing applications as PDF questionnaire.
Description
The Project Owner (commonly referred to as Principal Investigator in the EuroHPC community) proposes a new Themelio Project. Pharos Administrators will review this applicaton, and it fits their criteria and they will approve it. They can reject the application if they think that the resources they asking for are not realistic or that they can not be served at the given time period of the application.
Acceptance Criteria
See User Story 1.2: Project Proposal Form for detailed acceptance criteria:
- AC 1.2.1: UI provides a button to create an applicatin for a new Project
- AC 1.2.2: Project Owner fills in the details, such as description, scientitific rationale, configuration of resources
- AC 1.1.1: PO can navigate a linear stepper including: Project Overview, PI/Organization, Scientific Case, Resource Request, and Compliance. +4
- AC 1.1.2: System validates that "Civilian Purpose" is set to "Yes" before allowing progression to Step 2.
- AC 1.1.3: User can input a "Preferable Starting Date," but the system explicitly notes this is a request; the effective start and end date may be determined by the Admin upon approval.
- AC 1.1.4: System supports rich text input for "Scientific Case" and "Technical Description" to allow for validation of the project purpose.
- AC 1.1.5: User must explicitly acknowledge GDPR data consent and Pharos Access Policy terms before the "Submit" button becomes active.
- AC 1.2.3: Project Owner adds Project Members as part of the application, and they can add more members later
- AC 1.2.3: Project Members should also agree with said GDPR & Pharos Access Politcy terms
- AC 1.2.4: Project Members can upload their public SSH keys for use in the HPC cluster and in other Themelio services
- AC 1.2.4: Project application can exist in a draft state until Project Owner decides it is ready to formally submitted
FR-STITCH-02: Unified Resource Request (Hybrid Offering)
Priority: P0 (Critical)
User Problem
Users need to request both traditional HPC (SLURM) resources and Cloud (Kubernetes) resources in a single scientific proposal, even though these are technically separate "offerings" in the underlying infrastructure.
Description
A unified resource selection step that aggregates requests for Daedalus (HPC) and Kubernetes (Cloud) into a single logical project request, which the backend will split into appropriate Waldur Orders.
Acceptance Criteria
-
AC 2.1.1: User can select and request HPC Resources defined by "Node Hours" (aligned with the EuroHPC 30% or National allocation model).
-
AC 2.1.2: User can select and request Kubernetes (Cloud) Resources defined by explicit quotas:
CPU: Total vCPUs/Cores requested.
RAM: Total Memory (GB) requested.
Storage: Total Persistent Storage (GB) requested.
-
AC 2.1.3: User can select one or more of the HPC and Kubernetes offerings
-
AC 2.1.3: System validates that the requested Kubernetes resources (CPU/RAM) do not exceed the maximum allowable "Offering" limits set by the Service Provider (Pharos Inc.).
-
AC 2.1.4: User can provide a text justification specifically for Cloud/K8s resource usage to differentiate from the HPC scientific case.
FR-PRO-02: Project-Centric Resource Access
Priority: P0 (Critical)
User Problem
Users work on multiple grants simultaneously; resources must be billed to the correct grant, not the user personally.
Description
Resources are "leased" by Projects. AAI dictates billing codes, quotas, and policies based on the active Project context.
Acceptance Criteria
See User Story 1.2: Project Context Switching for detailed acceptance criteria:
- AC 1.2.1: UI provides a selector to switch the active Project
- AC 1.2.2: Visual indicator shows the currently active Project
- AC 1.2.3: Switching context updates available quotas and billing ledger target
- AC 1.2.4: RBAC permissions propagate immediately to Slurm/K8s upon switch
FR-AAI-02: Project-Centric Resource Access
Priority: P0 (Critical)
User Problem
Users work on multiple grants simultaneously; resources must be billed to the correct grant, not the user personally.
Description
Resources are "leased" by Projects. AAI dictates billing codes, quotas, and policies based on the active Project context.
Acceptance Criteria
See User Story 1.2: Project Context Switching for detailed acceptance criteria:
- AC 1.2.1: UI provides a selector to switch the active Project
- AC 1.2.2: Visual indicator shows the currently active Project
- AC 1.2.3: Switching context updates available quotas and billing ledger target
- AC 1.2.4: RBAC permissions propagate immediately to Slurm/K8s upon switch
User Stories
FR-AAI-03: Project Administration & Governance
Priority: P0 (Critical)
User Problem
Users expect to get access to HPC and Soft Resources by getting their Projects approved, and get technical support for complex infrastructure.
Description
When a new project is proposed or its membership changes for any reason, the Operating Party of Themelio has to perform certain operations. Users need access to complex infrastructure and resources, requiring coordination of different systems behind the scenes.
Acceptance Criteria
See User Story 1.3: Project Access Management and User Story 1.4: Admin Governance Dashboard for detailed acceptance criteria:
From Story 1.3 (Project Access Management, Waldur, and Manual Administration):
- AC 1.3.1: Owner can view a list of all current members and their roles
- AC 1.3.2: Owner can invite a user to the project via email or username
- AC 1.3.3: Owner can revoke a user's access
- AC 1.3.4: Owner can assign "Co-owner" role to delegate management
- AC 1.3.5: Users that are invited to the Project should sign an agreement and provide their SSH keys (it is currently the same procedure that GRNET HPC team is doing)
From Story 1.4 (Waldur):
- AC 1.4.1: Admin interface to list pending project applications
- AC 1.4.2: Ability to Approve (triggering group creation & metadata assignment) or Reject (with reason) an application, and ask for changes
- AC 1.4.3: Ability to modify quotas for an active project
- AC 1.4.4: Ability to force-stop jobs/projects affecting cluster health
User Stories
• User Story 1.3 • User Story 1.4
2.2. ML-Optimized Git Repositories
FR-REP-01: Git & Revision History
Priority: P0 (Critical)
User Problem
ML Researchers and Applied ML Engineers need to track experiments, revert to previous git commits if performance degrades, and maintain history across different versions of a file.
Description
The repository storage backend must be a fully functional Git server. It allows users to interact via standard Git CLI commands (push, pull, clone) and creates an immutable history of changes (commits) for all files, including LFS pointers.
Acceptance Criteria
See User Story 2.1: Repository Management for detailed acceptance criteria:
- AC 2.1.1: User can create a new Repo (Model, Dataset, Space, or Recipe) for the active Project
- AC 2.1.2: Repository form captures all required fields (eg. title, creator, creation date, visibility, owner)
- AC 2.1.3: Repository form support essential optional fields (URL, description, domain, task/AI category)
- AC 2.1.3: User can upload contents to an empty Repo for the active Project using
git push(HTTPs & SSH) - AC 2.1.4: User can download repositories using standard
git clone(HTTPs & SSH) - AC 2.1.5: UI displays commit history (hashes, authors, timestamps)
User Stories
FR-REP-02: Repository Visibility Control
Priority: P0 (Critical)
User Problem
Users need to control access to their models during development and testing before making them publicly available, but also need an easy way to publish when ready.
Description
A visibility management system that allows model owners to set resources as Public (discoverable by all) or Private (accessible only to owner and authorized users), with the ability to toggle visibility with confirmation.
Acceptance Criteria
- AC 2.2.1: Visibility can be set to Public, Gated or Private during model creation
- AC 2.2.2: Visibility toggle available in repository settings page for Project Owners
- AC 2.2.3: Confirmation dialogs explain implications of visibility changes, similar to Github by typing the full slug of the repository as a
- AC 2.2.4: Visibility status clearly indicated in dashboard and view page
- AC 2.2.5: Private repositories do not appear in public catalogue or search results
User Stories
TODO
FR-REP-02: Large Binary File Support (LFS)
Priority: P0 (Critical)
User Problem
Machine learning projects often contain massive binary files (model weights, datasets) that standard Git cannot handle efficiently, leading to slow operations and storage limits.
Description
A version control system backed by LFS (or Xet) protocol that optimizes storage for ML assets. Ideally, it must support chunk-level deduplication to accelerate uploads and downloads of large files (e.g., .safetensors, .parquet) while maintaining standard Git compatibility.
Acceptance Criteria
See User Story 2.2: Large File Support (LFS) for detailed acceptance criteria:
- AC 2.2.1: Support for git push of files up to TB scale via LFS/Xet protocol
- AC 2.2.2: Chunk-level deduplication is implemented to optimize storage
- AC 2.2.3: Standard git clients work without requiring custom plugins for basic push/pull
- AC 2.2.4: LFS uploads that would exceed the Themelio Project's storage quota are rejected before data transfer begins, with a clear error message indicating remaining capacity (see ADR-0003)
User Stories
FR-REP-02: Repository Overview Page
Priority: P0 (Critical)
User Problem
Users need to evaluate whether a Repository fits their use case by viewing comprehensive information without being overwhelmed by technical details in the initial view.
Description
A dedicated overview page for each Repository that presents documentation and metadata in a clear, structured format with a "Dive Deeper" option for accessing detailed technical information, metrics, and performance benchmarks.
Acceptance Criteria
- AC 3.2.1: View page displays header with logo, title, type badge, visibility status
- AC 3.2.2: Creator information shown
- AC 3.2.3: Metadata section displays description, domains, tasks, languages, license, tags and all key metadata following MLDCAT-AP
- AC 3.2.4: Model-specific content shows: URL, type, number of parameters, training datasets
- AC 3.2.5: Related resources section shows linked datasets, recipes, and materials
- AC 3.2.6: Supplemental resources section lists external papers, demos, documentation as links
- AC 3.2.7: "Dive Deeper" button navigates to extended page with detailed metrics and benchmarks
- AC 3.2.8: Discussion section appears at bottom for authenticated users
- AC 3.2.9: Share button available for public models; Edit button for owners
- AC 3.2.10: Supplemental resources can be added with URLs and descriptions
FR-REP-03: Collaboration & Automation
Priority: P1 (High)
User Problem
ML Researchers and Applied ML Engineers need a way to collaborate on models and datasets, proposing changes and reviewing code/data without directly modifying the main repository or downloading everything locally.
Description
A web-based collaboration interface allowing users to open Pull Requests (PRs) and start Discussions. It includes specific visualization tools to review changes in ML-specific file formats (not just text code).
Acceptance Criteria
See User Story 2.3: Collaboration (PRs & Discussions) for detailed acceptance criteria:
- AC 2.3.1: User can open a PR from a branch/fork
- AC 2.3.2: PR supports "Draft" and "Published" states
- AC 2.3.3: Threaded discussions can be opened on PRs or general topics
- AC 2.3.4: UI renders visual diffs for supported non-text files (JSON, Images)
User Stories
2.3. Models
FR-MOD-01: Model Catalogue & Discovery
Priority: P0 (Critical)
User Problem
ML Researchers and Applied ML Engineers cannot effectively locate suitable pre-trained models without comprehensive, structured metadata that describes model capabilities, requirements, and lineage.
Description
A metadata management system for models that captures essential information including technical specifications, usage instructions, training details, and relationships to other resources. The platform stores metadata and links to hosted model locations rather than the actual model files.
Acceptance Criteria
Models are Repositories and as such they inherit their Acceptance Criteria
See User Story 3.1: Model Discovery & Filtering for detailed acceptance criteria:
- AC 3.1.1: Search interface supports filtering by Task, Library, Language, License
- AC 3.1.2: Metadata is auto-parsed from
README.mdYAML front matter - AC 3.1.3: Search results show metrics: Downloads, Likes, Updated timestamp
- AC 3.1.4: Private repositories are hidden from public search (ACL respect)
User Stories
FR-MOD-03: Inference API Deployment
Priority: P1 (High)
User Problem
Applied ML Engineers need to integrate models into external applications (e.g., a mobile app or data pipeline) via standard HTTP requests without managing GPU servers.
Description
A managed service that deploys the model container to the Cloud partition (Kubernetes), exposes it via a secure REST API, and handles auto-scaling.
Acceptance Criteria
See User Story 3.2: Managed Inference Deployment for detailed acceptance criteria:
- AC 3.3.1: One-click deploy from Themelio Catalogue to K8s using the Project resources
- AC 3.3.2: Auto-selection of container (Triton/vLLM) if not specified
- AC 3.3.3: API is secured via User Token (OAuth2/PAT)
- AC 3.3.4: API schema follows standard formats (e.g., OpenAI-compatible for LLMs)
User Stories
FR-MOD-04: Model Widgets
Priority: P2 (Medium)
User Problem
Applied ML Engineers want to visually verify if a model works for their specific use case (e.g., "Does this OCR model read Greek?") before investing time to write code or download weights.
Description
An embedded UI component on the Model Card that dynamically renders input fields based on the model's pipeline_tag (e.g., Textbox for NLP, Image Uploader for Vision) and displays the inference result.
Acceptance Criteria
See User Story 3.3: Interactive Model Widgets for detailed acceptance criteria:
- AC 3.4.1: Widget input UI adapts to pipeline tag (Text, Image, Audio)
- AC 3.4.2: Inference results are rendered visually (JSON pretty print, Image render)
- AC 3.4.3: "Use in API" button generates a curl/python snippet for the current input
User Stories
FR-MOD-05: Batch Inference with Datasets
Priority: P1 (High)
User Problem
ML Engineers need to run large-scale batch inference jobs using trained models on entire datasets for evaluation, feature extraction, or production processing, but interactive widgets and real-time APIs are inefficient for bulk operations.
Description
A batch processing system that allows users to submit script-based inference jobs that apply a trained model to a selected dataset, with automatic scaling, progress tracking, and result storage. The system handles resource allocation, monitors execution, and stores outputs back to the platform.
Acceptance Criteria
- AC 3.5.1: User can select a trained model and dataset from the platform when creating a batch inference job
- AC 3.5.2: User provides or selects an inference script that defines how to apply the model to dataset entries
- AC 3.5.3: System validates model compatibility with dataset format and provides clear error messages if incompatible
- AC 3.5.4: Batch job is queued and executed on appropriate compute resources (K8s/Slurm) based on model requirements
- AC 3.5.5: Progress tracking shows number of items processed, remaining, and any errors encountered
- AC 3.5.6: Inference results are automatically saved to a specified output location (new dataset, model repository, or external storage)
- AC 3.5.7: Logs and error reports are captured and accessible for debugging failed inference runs
- AC 3.5.8: Resource usage (GPU/CPU hours, memory) is tracked and attributed to the project quota
- AC 3.5.9: Batch inference job records link the source model, input dataset, and output results
- AC 3.5.10: User can cancel running batch inference jobs with cleanup of partial results
User Stories
2.4. Data Management
FR-DAT-01: Dataset Metadata Management
Priority: P0 (Critical)
User Problem
Researchers and data scientists cannot effectively discover and evaluate datasets without comprehensive metadata describing data characteristics, format, size, and provenance.
Description
A metadata management system for datasets that captures essential information including data specifications, format details, source information, and relationships. The platform stores metadata and links to hosted dataset locations rather than actual data files.
Acceptance Criteria
Models are Repositories and as such they inherit their Acceptance Criteria
- AC 4.1.3: Complete metadata set includes version, license, languages, tags, derived source
- AC 4.1.5: Format field supports multiple selections (CSV, JSON, Parquet, Arrow, etc.)
- AC 4.1.6: Size field accepts numeric input with unit selector (records, MB, GB, TB)
- AC 4.1.7: Supplemental resources can be added for additional documentation
User Stories
TODO
FR-DAT-02: Dataset View Page
Priority: P0 (Critical)
User Problem
Users need to evaluate dataset suitability by viewing characteristics, format information, and related resources before committing to access or download.
Description
A dedicated view page for each dataset that presents metadata clearly with a "Dive Deeper" option for accessing detailed schema, statistics, and quality metrics.
Acceptance Criteria
- AC 4.2.1: View page displays header with logo, title, type badge, visibility status
- AC 4.2.2: Creator information shown with clickable links
- AC 4.2.3: Metadata section displays description, domains, tasks, languages, license, tags
- AC 4.2.4: Dataset-specific content shows: URL, size, formats, modality
- AC 4.2.5: Related resources section shows models trained on this dataset or recipes using it
- AC 4.2.6: "Dive Deeper" button navigates to detailed statistics and schema page
- AC 4.2.7: Discussion section available at bottom
- AC 4.2.8: Share and Edit buttons available as appropriate
FR-DAT-03: Dataset Preview & Inspection
Priority: P1 (High)
User Problem
Users need to verify data quality and content before committing to a large download, but downloading petabyte-scale datasets just to inspect a few rows is inefficient.
Description
A browser-based viewer that streams the first 100 rows of a dataset. It must natively render various data types (text, images, audio) directly in the table cells without requiring local processing.
Acceptance Criteria
See User Story 4.1: Dataset Streaming Preview for detailed acceptance criteria:
- AC 4.3.1: Viewer streams initial rows via API (no full download)
- AC 4.3.2: Audio and Image columns render players/thumbnails directly in table cells
- AC 4.3.3: Pagination allows navigation through preview rows
User Stories
2.5. Interactive Spaces
FR-SPA-01: App Creation & Hosting
Priority: P1 (High)
User Problem
ML Researchers and Applied ML Engineers need a way to demonstrate their models without managing complex web infrastructure or learning frontend frameworks from scratch.
Description
A streamlined hosting environment that natively supports popular Python SDKs (Gradio, Streamlit) and custom Docker containers for deploying ML applications.
Acceptance Criteria
See User Story 5.1: Space Creation & Auto-Build for detailed acceptance criteria:
- AC 5.1.1: User selects SDK (Gradio/Streamlit/Docker) during creation
- AC 5.1.2: Pushing code triggers auto-build and deployment
- AC 5.1.3:
requirements.txtdependencies are installed automatically
User Stories
FR-SPA-02: Shared GPU Pool
Priority: P1 (High)
User Problem
Running modern large language models (LLMs) or diffusion models requires expensive GPUs that are costly to keep running 24/7 for a simple demo.
Description
Mechanism to upgrade Spaces to specific GPU hardware (e.g., A10G, H100) or use shared GPU for dynamic, on-demand GPU allocation that scales down to zero when idle.
Acceptance Criteria
See User Story 5.2: CPU Allocation for Spaces for detailed acceptance criteria:
- AC 5.2.1: Setting a limit for CPU quotas for a consumer user that visit this space
- AC 5.2.2: Support for "sleep" configuration on idle paid Spaces
- AC 5.2.3: Shared GPU options for efficient resource usage
User Stories
FR-SPA-03: Persistent Storage
Priority: P2 (Medium)
User Problem
Standard Spaces are ephemeral; any data saved to disk is lost when the container restarts (which happens frequently on cloud infrastructure).
Description
An optional storage volume that mounts to /data within the container, retaining files across restarts and deployments.
Acceptance Criteria
- Mounting: Files saved to the specific
/datadirectory persist after app rebuilds. - Scalability: Users can choose between different storage tiers (Small, Medium, Large) based on need.
- Access: Persistent data is accessible by the application code regardless of the underlying container lifespan.
User Stories
(No user stories were listed in the original table)
FR-SPA-04: Secrets Management for Spaces
Priority: P1 (High)
User Problem
Applications often need sensitive API keys (e.g., OpenAI tokens, HF Tokens) which cannot be hardcoded in public repositories.
Description
A secure environment variable management system where owners can set secrets that are injected into the runtime but hidden from the public code view.
Acceptance Criteria
See User Story 5.3: Secrets Management for detailed acceptance criteria:
- AC 5.3.1: UI for adding write-only secrets
- AC 5.3.2: Secrets injected as environment variables at runtime
- AC 5.3.3: Docker builds support secret mounting via
/run/secrets/
User Stories
FR-SPA-05: Dev Mode (SSH & VS Code)
Priority: P2 (Medium)
User Problem
The standard "git push to deploy" loop is too slow for rapid debugging and iterative development.
Description
A "Dev Mode" that enables SSH access to the running container and allows direct connection via an web instance of VS Code or Gitlab Web IDE or on local environment with VS Code Remote.
Acceptance Criteria
- Remote Access: Users can SSH directly into the running Space container.
- Hot Reloading: Changes made via VS Code are reflected immediately without a full rebuild cycle.
- Security: Access is restricted to the Space projets members via secure authentication.
User Stories
(No user stories were listed in the original table)
FR-SPA-06: Embedding & Custom Domains
Priority: P3 (Medium)
User Problem
Businesses and creators want to present their demos on their own websites or domains without the Hugging Face branding wrapper.
Description
Capability to embed Spaces via IFrames/Web Components and route traffic from a custom domain (CNAME) to the Space.
Acceptance Criteria
- Embedding: System provides copy-paste ready HTML snippets (
<iframe>or<gradio-app>). - Custom Domain: Users can configure a DNS CNAME record to serve the Space from their own URL (e.g.,
demo.mycompany.com).
User Stories
(No user stories were listed in the original table)
FR-SPA-07: Secrets & Dev Mode
Priority: P2 (Medium)
User Problem
Apps need secure tokens; standard deploy loop is too slow for debugging.
Description
Management of environment variables and SSH/VS Code access to containers.
Acceptance Criteria
- Secrets: Write-only secrets UI.
- Access: SSH access to running container.
- Dev: Hot-reloading support.
User Stories
(Implied by "I want to create a space" and general developer needs.)
2.6. Recipes
FR-RCP-01: Recipe Creation & Management
Priority: P0 (Critical)
User Problem
Educators and practitioners need a way to document and share step-by-step AI workflows, but lack a structured format that allows them to create, organize, and link resources within instructional guides.
Description
A recipe management system that enables creation of step-by-step guides with a visual editor supporting drag-and-drop reordering, resource association, and rich text instructions. Recipes serve as educational workflows linking models, datasets, and tools.
Acceptance Criteria
- AC 6.1.1: Recipe creation form captures title, description, difficulty, required skills
- AC 6.1.2: Categorization includes domains, tasks, languages, and tags
- AC 6.1.3: Step builder allows adding, deleting, and reordering steps
- AC 6.1.4: Each step has title and instructions with rich text editor support
- AC 6.1.5: Steps can associate platform models and datasets via searchable multi-select
- AC 6.1.6: Step numbering updates automatically when reordered
- AC 6.1.7: Form validation ensures required fields completed
- AC 6.1.8: License and supplemental resources can be added
User Stories
US-RCP-01: As an educator, I want to create step-by-step recipes for using AI tools so that my students can follow structured workflows.
US-RCP-02: As a recipe creator, I want to link models and datasets to specific steps so that users can access the resources they need.
US-RCP-03: As a recipe owner, I want to reorder steps via drag-and-drop so that I can refine the workflow logic.
FR-RCP-03: Recipe View & Navigation
Priority: P0 (Critical)
User Problem
Learners need to follow recipes step-by-step with clear navigation and access to associated resources without losing their place in the workflow.
Description
A recipe view page that presents steps sequentially with navigation controls, progress tracking, and inline access to linked resources. Users can move between steps, jump to specific steps, and access all resources used in the recipe.
Acceptance Criteria
- AC 6.2.1: Recipe overview displays difficulty, required skills, learning objectives
- AC 6.2.2: Steps presented in sequential numbered format
- AC 6.2.3: Each step shows title, instructions, associated resources
- AC 6.2.4: Associated resources (models, datasets, tools) that are hosted in our platform are showcased with cards
- AC 6.2.5: Assoicated resources (models, datasets, tools) that are externaly hosted are showcased via links
- AC 6.2.6: Next/Previous step buttons for linear navigation
- AC 6.2.8: Recipe linked resources section lists all models, datasets, and tools used
- AC 6.2.9: Print or export option available for offline use
- AC 6.2.10: Discussion section available at bottom
- AC 6.2.11: Share and Edit buttons displayed as appropriate
User Stories
US-RCP-06: As a learner, I want to follow recipe steps sequentially so that I can complete an AI workflow successfully.
US-RCP-07: As a user, I want to jump to specific steps so that I can reference particular parts of the recipe.
US-RCP-08: As a learner, I want to access linked resources directly from recipe steps so that I can use the required tools.
FR-RCP-04: Recipe Editing & Version Management
Priority: P1 (High)
User Problem
Recipe creators need to update workflows as tools and best practices evolve, but changes could confuse users actively following the recipe.
Description
An editing system for recipes that allows modification of basic information, steps, and resources while maintaining version history or change tracking to preserve recipe integrity.
Acceptance Criteria
- AC 6.3.1: Edit form pre-populates with current recipe data
- AC 6.3.2: All recipe elements can be modified (metadata, steps, resources)
- AC 6.3.3: Steps can be added, removed, or reordered during editing
- AC 6.3.4: Changes tracked with last updated timestamp
- AC 6.3.5: Preview mode available before saving changes
- AC 6.3.6: Validation ensures recipe remains coherent after edits
User Stories
US-RCP-09: As a recipe owner, I want to edit my recipe steps when workflows change so that the content stays current.
2.7. upskilling materials
FR-USK-01: Material Creation & Management
Priority: P0 (Critical)
User Problem
Content creators need to share educational articles and tutorials either hosted on the platform or linked externally, but lack a unified system for both types of content with proper categorization.
Description
An upskilling material management system supporting two content types: external links pointing to articles hosted elsewhere, and hosted content written directly on the platform with a rich text editor. Both types share common metadata structure.
Acceptance Criteria
- AC 7.1.1: Material type selection during creation (External Link or Hosted Article)
- AC 7.1.2: External materials capture: title, URL, short description, thumbnail, reading time
- AC 7.1.3: External URL validated for accessibility
- AC 7.1.4: Hosted materials use rich text editor (html or md)
- AC 7.1.5: Rich text editor supports syntax highlighting for code blocks
- AC 7.1.6: Image upload and insertion supported in hosted materials
- AC 7.1.7: Embedding Youtube videos supported in hosted materials
- AC 7.1.9: Word count and reading time auto-calculated for hosted content
- AC 7.1.10: Preview mode available before publishing for owners of the material
- AC 7.1.11: Categorization includes: domains, tasks, difficulty, languages, tags
- AC 7.1.12: Related resources (models, datasets, recipes) can be linked
- AC 7.1.13: License and publication date can be specified
User Stories
US-USK-01: As a content creator, I want to write and publish educational articles directly on the platform so that I can share knowledge with the community.
US-USK-02: As a curator, I want to link to external educational resources so that users can discover high-quality content from across the web.
US-USK-03: As a writer, I want auto-save functionality so that I don't lose my work during long writing sessions.
FR-USK-03: Material View Information Page
Priority: P0 (Critical)
User Problem
Users need different viewing experiences for external versus hosted materials - external materials need a clear link to the source, while hosted materials need comfortable reading formatting.
Description
Dedicated view pages for upskilling materials that adapt based on content type: external materials show metadata and prominent link to external source, while hosted materials display full content with readable formatting.
Acceptance Criteria
Common Elements:
- AC-USK-03.1: View page displays metadata (title, description, tags, domain, difficulty, reading time)
- AC-USK-03.2: Author information with links
- AC-USK-03.3: Publication/creation date displayed
- AC-USK-03.4: Related resources section displays linked models, datasets, recipes
- AC-USK-03.5: Discussion section available at bottom
- AC-USK-03.6: Share and Edit buttons displayed as appropriate
External Materials:
- AC-USK-03.4: Prominent "Read Article" or "Go to Article" button with external URL
- AC-USK-03.5: External site information and favicon shown
Hosted Materials:
- AC-USK-03.6: Prominent "Read Material" with URL pointing to the material article page
- AC-USK-03.6: Full article content rendered with proper typography and spacing
- AC-USK-03.7: Code blocks display with syntax highlighting
- AC-USK-03.8: Images render correctly inline
- AC-USK-03.9: Table of contents generated automatically for long articles
- AC-USK-03.10: Reading time estimate shown
User Stories
US-USK-06: As a user, I want to quickly access external articles via a prominent link so that I'm not confused about where the content lives.
US-USK-07: As a learner, I want to see related resources so that I can explore connected models and datasets.
FR-USK-04: Material View Page
Priority: P0 (Critical)
User Problem
Users needs to be able to read hosted material in seperate pages.
Description
Dedicated view page for upskilling materials hosted in our platform, displaying their full content with readable formatting.
Acceptance Criteria
- AC-USK-04.1: Full article content rendered with proper typography and spacing
- AC-USK-04.2: Code blocks display with syntax highlighting
- AC-USK-04.3: Images render correctly inline
- AC-USK-04.4: Embedded videos render correctly inline
- AC-USK-04.5: Table of contents generated automatically for long articles
- AC-USK-04.6: Reading time estimate shown
- AC-USK-04.7: Author profile information shown (image, name etc)
User Stories
US-USK-08: As a reader, I want to read hosted articles with comfortable formatting so that I can focus on the content.
FR-USK-05: Material Editing & Content Updates
Priority: P1 (High)
User Problem
Content creators need to update educational materials as information changes or improves, while maintaining version history for hosted content.
Description
An editing system for upskilling materials that allows modification of metadata, URLs (for external materials), and full content (for hosted materials) while maintaining version history for hosted articles.
Acceptance Criteria
- AC-USK-05.1: Edit form pre-populates with current material data
- AC-USK-05.2: External materials can update: URL, description, thumbnail, metadata
- AC-USK-05.3: Hosted materials can update: content, metadata, images
- AC-USK-05.4: Rich text editor available for hosted content editing
- AC-USK-05.5: Changes tracked with last updated timestamp
- AC-USK-05.6: Preview mode available before saving changes
- AC-USK-05.7: Version history maintained for hosted articles (optional)
User Stories
US-USK-09: As a content creator, I want to update my articles when information changes so that readers have accurate content.
US-USK-10: As a curator, I want to update external links when they move so that users can still access the resources.
2.6. Resource & Quota Management
FR-QTA-01: Quota Request & Lifecycle
Priority: P0 (Critical)
User Problem
Projects have finite resources; users need a formal process to request initial allocations or extensions without emailing admins.
Description
A workflow system for requesting, approving, and extending compute and storage quotas.
Acceptance Criteria
See User Story 6.1: Quota Requests for detailed acceptance criteria:
- AC 6.1.1: Form captures requested GPU hours, Storage quotas, and justification
- AC 6.1.2: Request routes to Admin Dashboard for approval
- AC 6.1.3: System handles "Expired" freeze state for a grace period (read-only mode, keep only storage quotas, freeze CPU/GPU resources and jobs)
- AC 6.1.4: Storage quotas for LFS objects are enforced at upload time (pre-transfer), not post-upload — users must not complete a multi-hour upload only to have it rejected (see ADR-0003)
User Stories
FR-QTA-02: Usage Monitoring & Alerts
Priority: P1 (High)
User Problem
Users run out of budget unexpectedly or leave expensive resources running.
Description
Real-time dashboards showing usage vs. limit and an alerting system.
Acceptance Criteria
See User Story 6.2: Budget Monitoring & Alerts for detailed acceptance criteria:
- AC 6.2.1: Waldur interoperability
- AC 6.2.2: Dashboard shows Real-time Usage vs Limit (GPU hours, Storage)
- AC 6.2.3: Auto-alerts sent at 50%, 80%, 95% usage thresholds
User Stories
2.7. Compute & Training Orchestration
FR-COM-01: Interactive Notebooks
Priority: P0 (Critical)
User Problem
Data scientists need immediate, interactive access to compute without writing Slurm scripts for exploration.
Description
On-demand spawning of JupyterLab instances on either Cloud or HPC partitions.
Acceptance Criteria
See User Story 7.1: Interactive Notebook Spawning for detailed acceptance criteria:
- AC 7.1.1: User selects hardware Kubeflow profile (GPU/CPU)
- AC 7.1.2: User selects for predefined Kubeflow images
- AC 7.1.3: User defines their own custom images
- AC 7.1.4:
/homedirectory persists across stop/start cycles - AC 7.1.5: Jupyterlab should include Git integration plugin attached
User Stories
FR-COM-02: Job Submission & Scheduling
Priority: P0 (Critical)
User Problem
Training foundation models requires batch processing on HPC or distributed training on K8s.
Description
Abstraction layer for submitting training jobs to Slurm (HPC) or Kubernetes (Cloud) via UI or CLI. This also supports batch inference jobs that apply trained models to datasets (see FR-MOD-05: Batch Inference with Datasets).
Acceptance Criteria
See User Story 7.2: Batch Job Submission for detailed acceptance criteria:
- AC 7.2.1: Open OnDemand UI allows defining training Slurm jobs
- AC 7.2.2: Slurm Job is queued and scheduled based on priority/availability
- AC 7.2.3: User can cancel a running or queued job
User Stories
• User Story 7.2 • User Story 7.4
FR-COM-03: Job Observability & Debugging
Priority: P1 (High)
User Problem
"Fire and forget" jobs often fail; users need visibility into execution state.
Description
Live log streaming, resource monitoring graphs, and terminal access to job containers.
Acceptance Criteria
See User Story 7.3: Job Observability for detailed acceptance criteria:
- AC 7.3.1: Live streaming of
stdout/stderrOpen OnDemand - AC 7.3.2: Graphs for GPU utilization, Memory, and CPU usage
- AC 7.3.3: Option to attach a web-terminal to the running node/pod
User Stories
2.8. Experiment Tracking & MLOps
FR-EXP-01: MLflow Integration
Priority: P1 (High)
User Problem
Keeping track of hyperparameters, metrics, and resulting artifacts across hundreds of training runs is impossible manually.
Description
Hosted MLflow instance per project (or shared multi-tenant) for tracking experiments.
Acceptance Criteria
See User Story 8.1: MLflow Experiments for detailed acceptance criteria:
- AC 8.1.1: MLflow server provisioned per project (or secure multi-tenant)
- AC 8.1.2: UI allows visual comparison of runs
- AC 8.1.3: Runs are linked to specific Git commits and Dataset versions
User Stories
• User Story 8.1 • User Story 7.4
FR-EXP-02: Artifact Management
Priority: P1 (High)
User Problem
Models produced by training jobs need to be stored, versioned, and moved to the Themelio Catalogue.
Description
Mechanism to promote training artifacts (checkpoints) to the Themelio Catalogue or download them.
Acceptance Criteria
See User Story 8.2: Artifact Promotion for detailed acceptance criteria:
- AC 8.2.1: MLflow UI
- AC 8.2.2: "Push to Registry" action available on Experiment/Run artifact
- AC 8.2.3: Artifacts are downloadable via UI
User Stories
2.9. User Onboarding & Support
FR-ONB-01: Documentation & Discovery
Priority: P2 (Medium)
User Problem
New users are overwhelmed by the complexity of HPC/Cloud/MLOps tools.
Description
Centralized documentation hub and resource discovery wizard.
Acceptance Criteria
Note: This functional requirement provides cross-cutting support for user onboarding across all epics.
- Docs: Searchable technical documentation.
- Wizard: "Getting Started" guide highlighting available project quotas.
User Stories
Related to: • User Story 1.1 - Authentication • User Story 1.2 - Project context
Page source
Source snapshot · Revision f928834c8.