Core Concepts
Understand the key building blocks of the Pipelines platform.
This page covers the foundational concepts you will encounter throughout Pipelines. Understanding these will help you navigate the rest of the documentation.
Organizations
An organization is the top-level container in Pipelines. It holds all your projects, team members, models, tools, evaluation criteria, and prompts. Every user belongs to at least one organization.
At the organization level, Org Admins manage:
- Team members and role assignments
- Custom LLM model credentials (bring-your-own-key)
- MCP server and HTTP tool registrations
- Evaluation criteria and prompt libraries
Projects
A project is a workspace within an organization that groups related pipelines, tasks, team members, and instructions. Projects provide scoping for access control — users are assigned to specific projects with specific roles.
Pipelines
A pipeline is a visual graph that defines the steps in your data workflow. You build pipelines in the drag-and-drop Pipeline Builder by connecting nodes together.
Admins manage a pipeline's status to control when it accepts work:
| Status | Description |
|---|---|
| Draft | Being designed in the builder. Not yet accepting tasks. |
| Active | Live and accepting tasks. Contributors can claim and submit work. |
| Paused | Temporarily stopped. All in-flight tasks are paused and hidden from contributors. |
| Completed | All tasks finished. |
| Archived | Retired and hidden from active views. |
Pipelines support versioning — you can publish new versions with change detection that classifies modifications as cosmetic, behavioral, or structural, with appropriate migration handling for in-flight tasks.
Nodes
Nodes are the building blocks of a pipeline. Each node defines a step in your pipeline — including what data is collected, how fields are configured, where content comes from, and who can see or edit it.
Subtask node
The primary work node. Each subtask defines a form with configurable fields (text inputs, ratings, selects, code editors, file uploads, and more). Every field has its own input mode — it can be filled by a contributor, pre-populated with seeded data, or auto-generated by an LLM. Fields also carry configuration for visibility, validation, and how they relate to fields in other nodes.
Review node
A quality control node linked to an upstream subtask. Reviewers see the original submission alongside review-specific fields and provide pass/fail decisions at the form level or per individual field. Failed reviews can trigger rework (sending the task back to the contributor for revision) or escalation to an admin.
Logic gate node
An automated decision node that evaluates conditions based on field values from upstream nodes and routes tasks down different paths. Logic gates support nested rule groups with AND/OR logic, comparison operators, and two output branches (Then/Else).
Start and End nodes
Every pipeline has exactly one start node (where tasks enter) and one or more end nodes (where tasks complete).
Tasks
A task is a single unit of work that flows through a pipeline. When a task enters a pipeline, it creates a node instance at each step it reaches. Tasks have their own lifecycle:
| Status | Description |
|---|---|
| Pending | Created but not yet available for work. |
| In Progress | At least one node is being worked on. |
| Finished | All nodes completed successfully. |
| Escalated | Flagged for admin attention due to review failures or logic issues. |
| Quarantined | Automatically held due to exceeded re-review limits. |
| Failed | Task processing encountered an unrecoverable error. |
Tasks can be created in several ways: uploading data via CSV, creating them through the API, seeding from the output of other pipelines on the platform, using infinite seeding mode (where tasks are generated on demand), or creating them in bulk directly from the UI.
Roles and permissions
Pipelines uses a three-tier role-based access control (RBAC) system:
| Role | Scope | Capabilities |
|---|---|---|
| Org Admin | Organization | Manage all projects, team, models, tools within an org |
| Project Admin | Project | Manage pipelines, tasks, team within a project (owner) or view project data (viewer) |
| Contributor | Project | Claim and submit work on assigned tasks |
Project Admins are assigned per-project as either owners (full read/write access) or viewers (read-only). A single user can have different access levels across different projects.
The platform has two personas: the admin persona (for building pipelines, managing projects, and reviewing data) and the contributor persona (for completing assigned work). A user can hold both roles — for example, someone might be a Project Admin on one project and a Contributor on another. Admins can also complete tasks directly from their view without switching personas.
Evaluations
The evaluation system provides quality control at multiple levels:
- Criteria are atomic evaluation definitions — a single metric like "grammar correctness" or "response relevance". Criteria can be of type human rating, LLM judge, or programmatic (exact match, regex, PII detection, JSON validity, keyword matching).
- Evaluations are compositions of one or more criteria, bundled together for reuse.
- Evaluation runs execute criteria against task data inline (before submission), on submission, or in batch.
Datasets
The Data Vault is where all datasets live. Datasets can be:
- Collected — automatically created from completed pipeline tasks
- Imported — uploaded from CSV/JSON files, HuggingFace Hub, or platform exports
The Analytics Studio provides interactive charting, filtering, and aggregation over dataset contents.