Pipelines

A Pipeline is a reusable retrieval definition. It describes how CoreCube prepares queries, retrieves candidate chunks, processes those candidates, and returns admitted evidence to the Orchestrator.

Pipelines do not select the answer LLM, own final-answer prompts, or become active by themselves. The Orchestrator decides which Pipelines are eligible for each Search mode and embeds their resolved definitions into the active runtime snapshot when an administrator applies a revision.

Where to find them

Open Admin Console → Configuration → Pipelines.

Pipelines and the Orchestrator

Pipelines own	The Orchestrator owns
Purpose and stable slug	Query-resolution, orchestration, and answer LLM
Ordered query tools	Fast, Balanced, and Accurate mode policies
Default and optional retrieval tools	Eligible Pipeline bindings for each mode
Ordered chunk tools	Direct evidence tools
Query and chunk System Prompts	Orchestrator and Answer System Prompts
Per-execution tool-call and wall-time limits	Turn-wide action, evidence, token, and latency ceilings

This separation lets administrators reuse one retrieval strategy in several modes without copying the model, answer prompts, or policy controls.

Seeded Pipelines

Fresh installations include three Pipelines:

Pipeline	Slug	Intended use
Exact Lookup	exact-lookup	Names, identifiers, error codes, titles, quoted phrases, and other lexical lookups.
Hybrid Coverage	hybrid-coverage	General explanatory, comparative, and multi-aspect questions using lexical and semantic retrieval.
Deep Document Analysis	deep-document-analysis	High-recall questions that may require evidence across several passages or sources.

The default Orchestrator binds them to Fast, Balanced, and Accurate respectively. The binding is a starting policy, not a permanent relationship: you can attach and order any ready Pipeline in each mode.

Pipeline Library

The Pipeline Library shows each Pipeline's name, slug, and readiness. From this page you can:

• add a Pipeline;
• open and edit an existing Pipeline;
• duplicate a Pipeline as a starting point;
• import or export a JSON definition;
• delete a Pipeline that is no longer needed.

Use the Purpose field to explain when the Orchestrator should choose the Pipeline. Keep it specific enough to distinguish the Pipeline from other eligible choices.

Pipeline names are for people. Slugs are stable identifiers used in URLs, exports, audit records, and runtime snapshots.

Execution limits

Every Pipeline has two local safety limits:

Setting	Range	Meaning
Max tool calls per execution	1–64	Maximum tool-call iterations during one Pipeline run.
Max wall time per execution	1,000–600,000 ms	Maximum elapsed time for one Pipeline run.

These limits apply inside one run_pipeline action. The Orchestrator's mode budgets remain the turn-wide authority and may stop work earlier.

Save versus active behavior

Saving a Pipeline updates its reusable definition. It does not modify an already-active Orchestrator snapshot.

To put a Pipeline change into service:

1. Save the Pipeline.
2. Open Configuration → Orchestrator.
3. Review any dependency-change or readiness notice.
4. Save and Apply a new Orchestrator revision.

Apply resolves the selected Pipeline, its tools, retrieval settings, and prompt content into the immutable snapshot used by subsequent answer turns. A turn already in progress keeps the snapshot it captured at its start.

Deleting a Pipeline removes the mutable definition and detaches it from the saved Orchestrator draft. Any previously applied snapshot retains its embedded copy until another revision is applied.

Readiness

A Pipeline is ready when its composition is valid and its required dependencies are available. A Pipeline can require attention when, for example:

• no default retrieval tool is configured;
• a referenced tool or System Prompt is unavailable;
• reranking is enabled without a ready reranker model;
• the reranker request exceeds the active worker's reported capacity.

Pipeline readiness is checked again when the Orchestrator prepares a snapshot for Apply.

Admin API

The Pipeline Library uses authenticated /api/pipelines endpoints:

Endpoint	Purpose
GET /api/pipelines	List Pipelines.
POST /api/pipelines	Create a Pipeline.
GET /api/pipelines/:id	Read by ID or slug.
PATCH /api/pipelines/:id	Update a Pipeline.
GET /api/pipelines/:id/readiness	Read readiness.
POST /api/pipelines/:id/readiness/probe	Recheck dependencies.
GET /api/pipelines/:id/export	Export JSON.
POST /api/pipelines/import	Import JSON.
DELETE /api/pipelines/:id	Delete a Pipeline.

The former /api/presets endpoint is not part of the current API.

Related

• Pipeline composition
• Retrieval settings
• Orchestrator
• System Prompts
• Retrieval Pipeline