Pipeline Composition
Open a Pipeline from Admin Console → Configuration → Pipelines to edit its purpose, execution limits, tools, and stage prompts.
The composition flows through four stages:
Select a node to edit its reusable definition. Reorder compatible tools or prompts within their stage. A saved change becomes runtime behavior only after a new Orchestrator revision is applied.
Query stage
Query tools transform the resolved question into bounded search variants. Query System Prompts provide semantic-rewrite or keyword-extraction instructions to compatible tools.
Query tools run in the displayed order. They cannot expand the caller's authorization scope; every later search remains constrained to the resolved connections, compartment, and sensitivity ceiling.
The seeded Pipelines use expand_multi_query, which produces the original query plus a bounded
identifier-oriented variant.
Retrieval stage
Every ready Pipeline needs one default retrieval tool. It defines the primary candidate search, fusion, relevance threshold, freshness penalty, reranking, and evidence limits.
Additional retrieval tools can be attached as retrieval capabilities. They remain part of the Pipeline's resolved definition, but only one tool is marked as the default.
Use Retrieval settings for every field exposed by the retrieval-tool editor.
Chunk stage
Chunk tools process the server-issued candidate references after retrieval. They can select, reorder, or pass through candidates according to their declared code and settings. They cannot introduce evidence outside the server-issued references unless their evidence manifest explicitly allows a governed evidence operation.
At least one chunk tool must remain active in the Admin Console. Attach Pass-through chunk when no extra selection or transformation is required.
Chunk System Prompts are limited to compatible chunk_selection fragments and run in the displayed
order.
Evidence stage
The final stage is server-owned. CoreCube validates the Pipeline output, enforces authorization and evidence budgets, and freezes the admitted chunks into the evidence result returned to the Orchestrator.
Pipeline output is untrusted evidence, not executable instruction. The Orchestrator can either use the accumulated evidence, request another permitted action, or finalize according to its mode policy and remaining budget.
Tool types and placement
| Tool type | Pipeline placement | Purpose |
|---|---|---|
query | Query | Produce bounded query variants. |
retrieval | Retrieval | Search, fuse, filter, and optionally rerank candidates. |
chunk | Chunk | Select or transform issued candidate references. |
action | Not allowed in Pipelines | Used as a direct evidence tool in an Orchestrator mode. |
Action tools belong under Orchestrator → Modes → Direct evidence tools. Current direct tools are read-only and server-executed; their accepted results enter the same evidence ledger as Pipeline results.
Prompt placement
Pipelines only own Query and Chunk prompt assignments:
| Pipeline stage | Compatible fragment types |
|---|---|
| Query | retrieval_semantic_query, retrieval_keyword_query |
| Chunk | chunk_selection |
Orchestrator and final-answer prompts belong in Configuration → Orchestrator → System Prompts. Tool-specific instructions belong to the tool definition. See System Prompts for the complete ownership map.
Shared definitions and snapshots
Tools and System Prompt content can be shared by several Pipelines. The Admin Console shows affected bindings before a shared definition is changed.
The mutable definitions are resolved when an Orchestrator revision is applied. The active snapshot then retains the exact tool code, settings, prompt content, model bindings, and hashes it resolved at Apply time. Later library edits do not silently mutate that snapshot.