# 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](./core.md) and the [Introduction to Themelio](../introduction/index.md). ## 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](./user-stories.md#story-11-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 • [User Story 1.1](./user-stories.md#story-11-unified-login-gateway) --- ## 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](./user-stories.md) 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](./user-stories.md#story-12-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](./user-stories.md#story-12-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 • [User Story 1.2](./user-stories.md#story-12-project-context-switching) --- ### 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](./user-stories.md#story-13-project-access-management) and [User Story 1.4: Admin Governance Dashboard](./user-stories.md#story-14-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-stories.md#story-13-project-access-management) • [User Story 1.4](./user-stories.md#story-14-admin-governance-dashboard) --- ## 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](./user-stories.md#story-21-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 • [User Story 2.1](./user-stories.md#story-21-repository-management) --- ### 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)](./user-stories.md#story-22-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](../../adr/0001-lfs-storage-quota-enforcement.md)) #### User Stories • [User Story 2.2](./user-stories.md#story-22-large-file-support-lfs) --- ### 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](https://interoperable-europe.ec.europa.eu/collection/semic-support-centre/solution/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)](./user-stories.md#story-23-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 • [User Story 2.3](./user-stories.md#story-23-collaboration-prs--discussions) --- ## 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](./user-stories.md#story-31-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.md` YAML 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 • [User Story 3.1](./user-stories.md#story-31-model-discovery--filtering) --- ### 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](./user-stories.md#story-32-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 • [User Story 3.2](./user-stories.md#story-32-managed-inference-deployment) --- ### 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](./user-stories.md#story-33-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 • [User Story 3.3](./user-stories.md#story-33-interactive-model-widgets) --- ### 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 • [User Story 3.4](./user-stories.md#story-34-batch-inference-with-datasets) --- ## 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](./user-stories.md#story-41-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 • [User Story 4.1](./user-stories.md#story-41-dataset-streaming-preview) --- ## 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](./user-stories.md#story-51-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.txt` dependencies are installed automatically #### User Stories • [User Story 5.1](./user-stories.md#story-51-space-creation--auto-build) --- ### 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](./user-stories.md#story-52-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 • [User Story 5.2](./user-stories.md#story-52-cpu-allocation-for-spaces) --- ### 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 1. **Mounting:** Files saved to the specific `/data` directory persist after app rebuilds. 2. **Scalability:** Users can choose between different storage tiers (Small, Medium, Large) based on need. 3. **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](./user-stories.md#story-53-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 • [User Story 5.3](./user-stories.md#story-53-secrets-management) --- ### 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 1. **Remote Access:** Users can SSH directly into the running Space container. 2. **Hot Reloading:** Changes made via VS Code are reflected immediately without a full rebuild cycle. 3. **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 1. **Embedding:** System provides copy-paste ready HTML snippets (`