Glossary

This glossary defines Domino’s first-class concepts. Each entry links to the section that covers the concept in depth. For the full governance vocabulary (attachments, classifications, evidence sets, and more), see the Governance glossary.

​

Agent

An agentic system uses a Large Language Model (LLM) to plan, execute, and adapt across multiple steps: a framework (such as LangChain or custom code) wraps orchestration logic around an LLM, which handles reasoning and generation. Domino hosts, serves, and distributes agents alongside Apps through the App & Agent Hub, and instruments them with traces for evaluation, deployment, and monitoring. See Agentic AI overview and Agents.

​

AI Factory

The set of Domino capabilities that empowers builders to create models, AI systems such as agents, and other computational and quantitative research work, using their preferred languages, IDEs, and compute frameworks, with tailored experiences for experiment management, MLOps, and collaboration. See the Domino overview.

​

AI Gateway (deprecated)

A legacy Domino component that bridged Domino and external Large Language Model (LLM) providers such as OpenAI or AWS Bedrock, proxying requests through central credentials and logging every interaction. It is removed from Domino Cloud, and in Domino 6.3 it is no longer enabled by default and works only where a deployment explicitly enables it. LLM Gateway 2.0 is its successor, adding usage tracking, cost controls, guardrails, and broader model and vendor coverage; Domino distributes it today as a binary deployed as a Domino app and plans to natively integrate it into a future release. See LLM Gateway 2.0 for the migration paths, and AI Gateway (legacy) for the 6.3 configuration.

​

API endpoint

A model from a Project deployed as a REST API for real-time or batch predictions. In Domino, a deployed API endpoint is called a Domino endpoint. See Model deployment.

​

App

An interactive web application built from the code in your Project. Apps run in containerized environments that provide routing, authentication, resource management, and isolation from other Project workflows. See Apps.

​

App & Agent Hub

The place to host, serve, and distribute Apps and agents to a broad spectrum of users within your organization, with the scalability, security, and discoverability to work at enterprise scale. See the Domino overview.

​

App instance

A single running execution of an App version. Starting a version creates an instance and stopping it ends the instance. An App has at most one running instance at a time, and Domino records logs and resource consumption for each one. See App versioning and reproducibility.

​

App Preview

A run of a Draft App in a real App runtime, started from a workspace, that only the App author can reach. Previewing doesn’t change a published App’s configuration or deployed instance, but it is not sandboxed: it runs with the author’s full identity and real access to Domino APIs and shared state. See Develop and test an App.

​

App version

An immutable snapshot of an App’s identity and version-defining content, including pinned source commits, Compute Environment and revision, Data Plane, mounted storage configuration, and identity propagation. Publishing a Draft or editing version-defining content creates a version; starting the App does not. See App versioning and reproducibility.

​

Approval

A sign-off required on provided evidence before a governance stage is considered complete. Approvals can also control transitions between stages. See Governance.

​

Artifact

A file that is neither source code nor data, typically outputs like plots, charts, and serialized models. See Files, artifacts, and results.

​

Audit Trail

Domino’s record of user activity across the deployment, for compliance verification, security investigations, and audit reporting, accessible through purpose-built UI views and APIs. See Audit Trail.

​

Bundle

A container that holds the materials or work items (models, files, Apps) you want to govern as a group, so policies can apply to them. To govern anything, it must be in a bundle; bundles originate in a Project. See Work with bundles.

​

Compute Environment

The container specification an execution runs in, defined by a Docker image that creates an isolated container for each execution unit: Workspaces, runs, Apps, and models. Environments are versioned and shareable. See Compute Environments.

​

Data Plane

The compute location where Domino runs your workloads. A deployment can have more than one Data Plane, in different regions or clouds. The local Data Plane is a namespace in the same Kubernetes cluster as the Domino Control Plane; a remote Data Plane is a namespace in a separate Kubernetes cluster. See Data Plane.

​

Data Source

An external system Domino connects to for data, such as a database, data warehouse, or data lake. Data Source connectors are the simplest way to connect to supported systems, and a Data Source can be reused in any Project. See Domino Data Sources.

​

Dataset

High-performance, versioned, structured filesystem storage in Domino. Use Datasets to build curated collections of data and share them with collaborators across Projects. See Datasets.

​

Domino endpoint

An HTTP API endpoint wrapped around your inference code. You supply arguments as parameters in the HTTP request payload, and the response includes the prediction. See Model deployment.

​

Domino File System (DFS)

Domino’s traditional storage for Project assets. Domino versions DFS files automatically with a Git server it runs in the background, recording a new Project version on every sync. See DFS Projects.

​

Domino Nexus

The capability to run data science workloads across multiple compute clusters, in any cloud, region, or on-premises, by attaching add-on Data Planes to the main Domino Control Plane. See Data Plane.

​

Domino skill

A packaged set of instructions that teaches a coding assistant how to carry out a specific Domino platform task, such as submitting a Job, registering a model, or deploying an App. The Domino Standard Environment ships the skills published in the public domino-claude-plugin repository, and a coding assistant loads them when it starts inside a Workspace. Skills are optimized for Claude Code, and anyone can add one through a pull request in the repository. See Domino skills reference.

​

Draft App

A private, author-only App used for development and testing, linked to a single Workspace and created the first time you use App Preview in that Workspace. Draft Apps never appear in App lists, discovery, or search. Authors access Draft Apps from their linked Workspaces. Previewing one doesn’t change a published App’s configuration or deployed instance, but side effects on shared resources are real. Deleting the Workspace deletes the Draft App. See Develop and test an App.

​

Evidence

Information relevant to a governance policy, in most cases a question with an answer, collected as inputs, metric checks, or scripted checks. Each policy defines the evidence required in each stage. See Governance.

​

Experiment Manager

Domino’s experiment tracking, built on MLflow Tracking, that logs experiment details such as parameters, metrics, and artifacts, storing metadata and results within the Project for reproducibility. See Track and monitor experiments.

​

Extension

Functionality from a Domino App surfaced inside the Domino UI, at one of five mount points: a link in the Project sidebar, an entry on a Dataset details page, an entry on a Model details page, an entry in the three-dot menu for files in a Dataset, or a new page in the Admin panel. An Extension changes nothing in the core Domino codebase, and it is not an App: it points to an App, and one App can power several Extensions. See Create and manage Extensions.

​

External data volume (EDV)

A volume from a network-attached storage system mounted to Domino. When an EDV is attached to a Project, Domino mounts its file system when running code in that Project. See External data volumes.

​

Finding

An issue discovered while reviewing governance evidence. Findings apply to a specific bundle and are typically related to a specific piece of evidence one of the bundle’s policies requires. See Governance.

​

FinOps

Cost management for AI work, one facet of Domino’s Governance Center. See FinOps.

​

Flow

An orchestrated, multi-step process with full lineage and reproducibility. The steps, implemented as Domino Jobs, are tasks, and the connections between them form a workflow defined as a directed acyclic graph (DAG). See Flows.

​

Gate

A governance control that prevents specific actions, such as deploying a published App, an agent, or a model Endpoint, until required approvals are complete. See Governance.

​

Git-based Project

A Project that stores its code at your Git provider. Git workflows (branch, commit, push, pull) work natively in your Workspace, and you keep your provider’s collaboration features. See Git-based Projects.

​

Governance Center

The set of capabilities for managing the facets of AI work: policies that enforce standards for lifecycle management, FinOps for managing costs, and an Audit Trail that tracks actions taken in the platform. See the Domino overview and Governance.

​

Hardware Tier

The compute specification (CPU, memory, and GPU) for the pods hosting Domino executions. Users select a Hardware Tier when launching an execution, which determines the available resources and node type. See Hardware Tiers.

​

HPC Job

A batch job submitted to and scheduled by Slurm from inside Domino. HPC Jobs are submitted from a Workspace with the standard Slurm CLI, or from the HPC tab of the Project’s Jobs page where an administrator has enabled UI submission. They run on autoscaled worker nodes, and the HPC tab carries their history. See Run HPC workloads with Slurm.

​

Job

A batch execution of code logic in a fully reproducible manner. Where Workspaces are for interactive development, Jobs are for batch and headless workloads. See Jobs.

​

Launcher

A self-serve web form that exposes a pre-defined task to less technical users. A Launcher’s UI controls (like a textbox or menu) feed parameters into the underlying run. See Launchers.

​

Librarian

A user role that manages the project library, including the organization’s tag structure and its Properties. See Roles.

​

Model

A machine learning or AI asset that builders create in a Project. Domino tracks models in the MLflow-based Model Registry, deploys them as API endpoints, and analyzes them in production with Model Monitoring. See Register models.

​

Model Monitoring

Analysis of models in production that alerts you when a model’s performance falls outside a specified range, tracking drift for input features and prediction variables against configurable thresholds. See Model Monitoring.

​

Model Registry

Domino’s MLflow-based registry for tracking and managing machine learning models: discover models in project-scoped and deployment-scoped registries, record metadata and lineage for auditability and reproducibility, manage versions and deployments, and limit access with Role-Based Access Control (RBAC). See Manage models with model registry.

​

Namespace

The allowed keys in Domino’s key-value tag structure; Tags are the allowed values within a given Namespace. Think of a Namespace as the category or dimension you classify by, and Tags as the values that category can take. See Tags.

​

NetApp Volume

Enterprise-grade storage from Domino’s native integration with NetApp ONTAP, mounted directly into Domino workloads. See NetApp Volumes.

​

Organization

A group of users that can be granted permissions as a unit. Domino treats organizations and users as near-equivalents. The user who creates an organization owns it and manages its membership. See Manage organizations.

​

Policy

The definition of the governance lifecycle a bundle must go through: all stages, evidence, and approvals required for compliance. A bundle can carry multiple policies, and a policy can be reused across bundles. See Define policies.

​

Policy version

A specific published revision of a Policy. Each policy version fixes the stages, evidence, and approvals that governed bundles follow while it is in effect, so successive versions can evolve the policy without disrupting bundles already in flight. See Define policies.

​

Project

Domino’s unit of organization: the code, data, results, and people for one piece of work. Apps, models, and API endpoints publish from a Project, and governance bundles track the work inside it. See Projects.

​

Project template

A template created from an existing Project by selecting which assets to include, so users can start from a working prototype instead of from scratch. Project templates are supported for Git-based Projects only. See Create Projects.

​

Property

A typed, open-ended field that enriches an entity with custom information. Unlike Tags, Properties have no hierarchy, and apart from the select types, no predefined set of values: users supply any value that matches the property’s defined type. See Properties.

​

Scheduled Job

A Job set to execute on a regular cadence, useful when a data source updates regularly. See Schedule a Job.

​

Snapshot

A read-only, immutable record of a Dataset at a specific point in time. You can tag snapshots, download them, or create versions from them. See Version data with snapshots.

​

Stage

A phase of a governance policy’s lifecycle, for example Use Case Definition, Data Selection, Deployment, and Ongoing Monitoring. Stages contain the evidence the policy requires. See Governance.

​

Tag

A value from a controlled, hierarchical list used to categorize and discover assets. Tags are organized as key-value pairs: Namespaces are the allowed keys, Tags the allowed values within each Namespace. See Tags.

​

Workspace

An interactive session where you conduct research, analyze data, and train models in the development environment of your choice, such as Jupyter, RStudio, or VS Code. See Workspaces.