> ## Documentation Index > Fetch the complete documentation index at: https://docs.scitix.ai/llms.txt > Use this file to discover all available pages before exploring further. # Core Concepts and Object Relationships > Understand the relationships among collaboration scopes, deployment locations, resources, assets, tasks, services, and running instances in Siverse. This topic helps you understand the primary objects in Siverse and how they work together across development environments, training jobs, and inference service runtimes. ## Collaboration Scope and Deployment Location Before creating a development environment, training job, or inference service, first determine “who can use it” and “where it runs.” These two dimensions must be selected separately. | Concept | Description | Confirm Before Use | | - | - | - | | **Tenant** | The management scope of an enterprise or organization. | The currently logged-in account belongs to the tenant associated with the current work. | | **Project group** | The management scope for team collaboration and object visibility; it is not equivalent to a group of physical servers. | Which project group an object belongs to, and which members can view or operate it. | | **Region and cluster** | The deployment location of workloads and the availability scope for resources, images, data, and models. | Required resources and assets are available in the same region and cluster. After switching regions or clusters, recheck the available options. | | **Resource pool** | Computing resources organized by resource type, isolation method, and usage policy. | You have permission to use the resource pool; the resource pool supports the current workload type and provides suitable instance specifications and quotas. | Selecting a project group does not automatically grant permissions for resource pools, images, models, or Volumes. When creating a task or service, object visibility, resource usage permissions, and data read/write permissions must all be satisfied. ## Workload-Referenced Resources and Assets The following diagram illustrates the relationship between the configuration used to create a task or service and the instances that actually run it. ![Platform Object and Runtime Relationships](https://mintcdn.com/scitix-adfc65c2/ZqwdmfntBUDyGPkJ/siverse/get-started/media/platform-object-relationships-orange.svg?fit=max\&auto=format\&n=ZqwdmfntBUDyGPkJ\&q=85\&s=346d8f6497499a40201b1bc0ae06c588) In the figure, Data and Models refers to input files. When needed, select a dataset, model source, or storage mount according to the options supported by the relevant module; not every workload must use both data and models. | Object | Role in Creation and Runtime | | - | - | | **Project Group** | Determines the collaboration scope and visibility of tasks or services. | | **Region and Cluster** | Determine where tasks or services are deployed, as well as the available resources and assets. | | **Resource Pool and Specifications** | Provide computing resources such as GPUs, CPUs, and memory for tasks or services. | | **Image** | Provides the software environment required for container runtime and the code included in the image. | | Data and Models | Are read by workloads as input files and may come from datasets, model sources, or storage mounts. | | **Tasks or Services** | Store the creation configuration and are the objects managed, viewed, modified, and troubleshot by the platform. | | **Running Instances** | The actual execution units started by the platform based on the creation configuration and resource scheduling results. | | **Persistent Outputs, Logs, and Metrics** | Used to save runtime results, explain program behavior, and observe runtime trends, respectively. | Submitting the creation request only indicates that the platform has accepted the configuration. Resource scheduling, image pulling, storage mounting, and application startup must still take place afterward. ## Images, Datasets, Models, and Volumes These types of objects serve different responsibilities. Managing them separately facilitates dependency updates, data reuse, and result preservation. | Object | What It Mainly Stores or Describes | Example Use | Notes | | - | - | - | - | | **Image** | The software environment required by a container, as well as code built into the image. | Pin versions of Python, training frameworks, CUDA, and system dependencies. | Save images to preserve the software environment; they cannot replace storage backups. | | **Dataset** | Data that workloads can select and read. | Mount as input to development environments or training jobs. | Ensure that the target workload can access the dataset and write outputs to a writable Volume. | | **Model** | The model name, version, source, and related information. | Specify weights, a tokenizer, and configuration files for inference. | Model records must correspond to files that are actually accessible; before training artifacts can be used for inference, they may need to be organized or converted. | | **Volume** | Persistent file storage that can be mounted by workloads. | Store project code, Notebooks, training results, and checkpoints. | Paths inside the container are determined by the mount configuration. For example, if a program reads `/mnt/data`, the target data must be mounted at that path. | Execution progress must be saved by the program itself; for example, a training program should save checkpoints. The platform can restart the training task, but it cannot replace the program in saving and loading progress. ## Tasks, Services, and Running Instances When you create a training job or inference service, you configure a platform-managed object. Based on this configuration, the platform starts one or more running instances. | Relationship | Description | What to Check During Use | | - | - | - | | **Creation configuration** | Includes information such as the image, commands, resources, mounts, ports, and environment variables. | Whether the configuration matches the code, data, model, and resource requirements. | | **Running instance** | The actual execution unit started by the platform based on the creation configuration and resource scheduling results. | Whether the target instance has been created and whether the expected number of ready instances has been reached. | | **Status, events, and logs** | Record the object lifecycle, scheduling process, and program runtime output. | Whether the issue is caused by a configuration not taking effect, resources not being scheduled, or an exception in the program itself. | | **Persistent output** | Written by the program to a Volume or other persistent storage to save results and resume progress. | Whether outputs, checkpoints, or model files have been written to a persistent location. | Tasks or services are not directly equivalent to running instances in terms of quantity. A service may have multiple replicas, and a training task may also include multiple roles or execution units. ## Specification Count, Replicas, and Resource Usage Instance specification describes a set of resources, such as GPU, CPU, and memory. Number of specifications determines how many sets of specifications an execution unit requests, while number of replicas determines how many such execution units are needed. For example, each allocation includes 2 GPUs, each replica uses 2 allocations, and 2 replicas are running in total: | Calculation Item | Calculation Result | | - | - | | GPU requirement per replica | 2 GPUs × 2 copies = 4 GPUs. | | GPU requirement for all replicas | 4 GPUs × 2 replicas = 8 GPUs. | CPU and memory are calculated using the same quantities and replica counts. For multi-role jobs, sum the resources for each role; for multi-node inference, also account for the number of nodes in each group. Refer to the resource configuration on the relevant creation page for details. Quota indicates the amount of resources allowed for use, while schedulable capacity indicates the amount of resources that can actually be scheduled under current conditions. Even when the quota is sufficient, tasks or services may still wait because of nodes, instance type combinations, resource pool status, or scheduling policies. ## Permission and Visibility Boundaries Project team visibility, resource usage rights, and data read/write permissions are distinct permission boundaries. | Requirement | Required Conditions | | - | - | | View task configurations, status, and logs | Object visibility and the corresponding view permissions. | | Stop, delete, or modify objects | Permissions for the corresponding operations and authorization for the object scope. | | Submit tasks or services using a resource pool | Resource pool usage permission, available quota, and an appropriate instance specification. | | Read data or write results | Read and write permissions for the Volume, directory, or data source. | | Reuse another user's configuration | Meet the applicable requirements for using compute resources, images, models, and storage, and reset the output path. | Task links are used to locate objects and do not grant access permissions themselves. Before sharing configurations, commands, environment variables, or logs, ensure that they do not contain passwords, access tokens, storage keys, or other sensitive information. ## Next Steps * [Quick Start with Siverse](/siverse/get-started/quickstart-ai-platform.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.