# Concepts (/docs/guides/developer-workspace/pipelines/concepts)



This page explains the building blocks of the Pipelines feature in BullSequana AI. Understanding these concepts helps you design effective workflows and interpret the information shown in the UI.

Pipeline [#pipeline]

A pipeline is a compiled definition of a multi-step machine learning or data processing workflow. You write a pipeline in Python using [the Kubeflow Pipelines SDK](https://www.kubeflow.org/docs/components/pipelines/user-guides/core-functions/compile-a-pipeline/), then compile it to a YAML file. Uploading that file to BullSequana AI registers the pipeline so you can run it repeatedly with different parameters without re-uploading.

A pipeline is versioned: each upload of the same pipeline name creates a new version. Older versions remain available so you can re-run or compare them.

Component [#component]

A component is the fundamental building block of a pipeline. Each component represents a single, self-contained unit of work, typically a Python function, that runs inside its own container. Components have typed inputs and outputs. When one component passes its output to the next, the SDK records that dependency in the pipeline graph.

Because a component is a Python function decorated with [`@component`](https://www.kubeflow.org/docs/components/pipelines/user-guides/components/lightweight-python-components/), you can reuse it across pipelines by importing it like any other Python module, or by [compiling it to a YAML file](upload-a-pipeline#before-you-start) and loading it with [`components.load_component_from_file()`](https://www.kubeflow.org/docs/components/pipelines/user-guides/components/load-and-share-components/).

Pipeline graph [#pipeline-graph]

The pipeline graph defines the execution order of all components. The platform executes each step when its upstream dependencies finish. Steps without dependencies run in parallel automatically.

<Mermaid
  chart="flowchart TD
    A[Ingest data] --> B[Preprocess]
    A --> C[Validate data]
    B --> D[Train model]
    C --> D
    D --> E[Evaluate]
    D --> F[Export model]"
/>

In this example, **Ingest data** runs first. **Preprocess** and **Validate data** run in parallel. **Train model** waits for both. **Evaluate** and **Export model** then run in parallel once training completes.

Steps and data flow [#steps-and-data-flow]

When the platform executes a pipeline, each node in the graph becomes a **step**: a single running instance of one component, isolated in its own container. The edges in the graph carry data from one step to the next. Two kinds of data can flow along those edges.

Parameters [#parameters]

Parameters are scalar values such as strings, numbers, and booleans. You declare them as typed arguments in your component function. The platform passes them directly between steps without writing them to storage. Use parameters for configuration values such as learning rate, batch size, or a file path string.

[Learn how to pass parameters between components](https://www.kubeflow.org/docs/components/pipelines/user-guides/components/compose-components-into-pipelines/).

Artifacts [#artifacts]

Artifacts are data objects such as datasets, model files, and metrics. A step that produces an artifact writes it to a local path; the platform then uploads it to object storage and records its location in the Metadata store. A downstream step that consumes the artifact receives that location and downloads the object at runtime.

Artifact types are declared explicitly in your component code. Common types include `Dataset`, `Model`, `Metrics`, `ClassificationMetrics`, `HTML`, and `Markdown`. The type determines how the UI renders and links the artifact in the **Artifacts** view.

When you connect a step's artifact output to another step's input in your pipeline code, the SDK inserts a dependency edge in the graph automatically. The downstream step does not start until the upstream step has finished writing and uploading the artifact.

Experiment [#experiment]

An experiment is a named workspace that groups related pipeline runs together. Use experiments to separate runs by project, dataset version, hypothesis, or any other logical boundary you choose.

Every run must belong to an experiment. There is no automatic default experiment, so you must create at least one before you can start a run.

See [Experiments](experiments) for the full how-to.

Run [#run]

A run is a single execution of a pipeline with a specific set of parameter values. The platform records every detail of the run: its inputs, outputs, execution logs, and the artifacts it produced. Runs are immutable once they complete, so you always have a precise record of what ran and what it produced.

You can compare runs within an experiment side by side to see how changing parameters affects results.

See [Runs](runs) for the full how-to.

Recurring run [#recurring-run]

A recurring run executes a pipeline on a repeating schedule. You define either a periodic interval (for example, every 24 hours) or a cron expression. Each trigger creates a new run, which appears in the experiment alongside manually started runs.

Recurring runs are useful for retraining models on fresh data, running validation jobs overnight, or any workflow that must repeat without manual intervention.

See [Recurring runs](recurring-runs) for the full how-to.

Artifacts [#artifacts-1]

Each artifact produced during a run (see [Steps and data flow](#steps-and-data-flow) above) is stored in the platform's object storage and linked to the run and step that produced it. The **Artifacts** view lets you browse all artifacts across runs. Common examples include trained model files, preprocessed datasets, evaluation metrics, and plots.

You can view artifact lineage to trace which run produced a given artifact and which runs consumed it as input.

See [Artifacts](artifacts) for the full how-to.

Executions [#executions]

An execution is a record of a single pipeline step. It captures the inputs, outputs, and status of one component invocation within a run. Executions are stored in the Metadata store and are the lowest-level unit of traceability in the system.

Use the **Executions** view to inspect individual step inputs and outputs, identify failures, or trace how a value flowed through the pipeline.

See [Executions](executions) for the full how-to.

Step caching [#step-caching]

When you run a pipeline, the platform checks whether a step has run before with identical inputs. If a cached result exists, the platform reuses it instead of re-running the step. This reduces compute time for pipelines where only some inputs change between runs.

Caching is enabled by default. You can disable it at the run level or for individual components in your pipeline code.

How the concepts fit together [#how-the-concepts-fit-together]

A single **pipeline** is composed of **components** connected in a **graph**. You upload the compiled pipeline to BullSequana AI, then create an **experiment** to organize your work. Each time you execute the pipeline, the platform records a **run** inside the experiment and tracks individual **executions** for each step. Steps that produce files or metrics generate **artifacts** that are linked back to the run.

<Mermaid
  chart="flowchart TD
    P[Pipeline] -->|defines| G[Graph of components]
    E[Experiment] -->|groups| R[Run]
    R -->|executes| G
    G -->|produces| A[Artifacts]
    G -->|records| X[Executions]"
/>

Next steps [#next-steps]

* [Upload a pipeline](upload-a-pipeline) to get started.
* [Create an experiment](experiments) before starting your first run.
* [Start a run](runs) to execute a pipeline.