Skip to content


The following provides a brief overview of the core concepts behind Continual.


Users are people like you. You can register for an account by visiting

Learn more about users in the users section of the documentation.


Organizations map to companies or business units. The first step after signing up is to create your organization.

Learn more about organizations in the organizations section of the documentation.


Projects are isolated workspaces that allow you to collaborate around your features and predictive models. Each project connects bi-directionally to a single data warehouse.

Learn more about projects in the projects section of the documentation.


Environments are a feature of projects that separate resources in Continual. Environments are freely named, but they typically represent stages in a development to production pipeline: such as development, staging, and production. This isolation between environments and the ability to see the impact of changes before deploying them is a unique characteristic of Continual and also provides a seamless experience with CI/CD systems.

Learn more about environments in the environments section of the documentation.


Environments are manipulated by declarative changes. You can make changes from the Web UI, CLI, or dbt integration. A change could be adding a new feature to the shared feature store, adding a new predictive model, or changing a model refresh policy.

Infrastructure-as-Code for AI

If you're familiar with infrastructure-as-code systems such as Terraform, you can think of a Change as equivalent to running terraform apply. Continual brings many of the ideas from infrastructure-as-code tools to operational AI workflows.

This declarative approach to AI is critical Continual's operational simplicity. It contrasts with point-and-click tools that lack an operational foundation or imperative pipeline-centric MLOps platforms.

Learn more about changes in the CI/CD section of the documentation.

Feature Sets

Feature sets sit at the core of Continual's data-first declarative design. They map to tables or views in your data warehouse. Columns represent individual features that are the inputs to predictive models.

By defining feature sets in Continual, you can easily share features across use cases to accelerate model development and help automatically prevent issues like data leakage when doing time-aware modeling tasks.

You can define feature sets using a SQL query and a small amount of additional metadata. The SQL query becomes a view in your underlying data warehouse and the metadata provides the additional information needed for machine learning purposes. If you're using dbt, a feature set can be mapped directly to a dbt model via dbt annotations.

You can read more about feature sets in the feature sets section of this documention and in the Feature set YAML reference.


Predictive models take features as input and return predictions. The common terminology in use in data science is the same as in Continual, although don't confuse it with a data or dbt model. For instance, a predictive model could predict the probability a customer churns or an inventory level thirty days in the future.

In the common use case of relational data, you can view a model target as the column of a table that we wish to predict based on one or more other columns (i.e. features). We apply an algorithm to the inputs to create an artifact that is able to make predictions based on new data. This artifact is a model version.

Like feature sets, in Continual, models are defined by providing a SQL query that corresponds to the input data. Users must additionally specify the columns that represent the index, target, and (optionally) time index, as well as providing any column references for any linked entities. Continually automatically joins feature sets with models based on these linked entity references while ensuring no temporal data leakage.

Continual continually maintains both the model and model predictions following the schedule in your model configuration.

You can read more about models in the models section of this documention and in the model YAML reference.

Model Versions

Each time a model is trained, a new model version is created in the system. This typically happens on a schedule given in the model definition but can also be triggered manually or via an API call. When training occurs, Continual's AutoML engine runs many different experiments finding the best model. The winning experiment in a training run represents the model version.

Learn more about model versions in the model versions section of the documentation.


Although each model will contain many model versions, only a single model version can be actively promoted at one time. Whenever a batch prediction job is run, the currently promoted model version will be used to make all predictions. Model versions can either be automatically promoted based on a policy, or manually via direct user interaction. Continual tracks all promotions for models in the system.

Learn more about promotions in the promotions section of the documentation.

Batch Predictions

A batch prediction refers to a batch scoring update. Continual maintains predictions in your underlying data warehouse by periodically rescoring your data or newly arriving data. Batch prediction runs keep track of the history of these scoring updates.

Learn more about batch predictions in the batch prediction section of the documentation.

Back to top