System Prompts
CoreCube stores System Prompts as reusable fragments. A fragment has a stable slug, a type, shared content, and one or more bindings that determine where the content is used.
Open Admin Console → Configuration → System Prompts to search, create, edit, duplicate, import, export, or delete fragments.
Ownership and binding surfaces
The fragment type controls where a prompt can be attached:
| Fragment type | Binding surface | Purpose |
|---|---|---|
orchestrator | Orchestrator phase | Evidence sufficiency, Pipeline selection, and direct-tool use. |
answer | Answer phase | Final answer behavior and domain framing. |
answer_citations | Answer phase | Citation-marker rules. |
answer_attachments | Answer phase | Authorized attachment-marker behavior. |
retrieval_semantic_query | Pipeline Query stage | Semantic standalone-query instructions. |
retrieval_keyword_query | Pipeline Query stage | Keyword and identifier query instructions. |
chunk_selection | Pipeline Chunk stage | Candidate selection instructions. |
tool_prompt | Tool definition | Tool-specific evidence and usage guidance. |
ocr_extraction | OCR configuration | Text-extraction instructions for compatible OCR providers. |
Final-answer prompts no longer belong to Pipelines. Attach and order them under Configuration → Orchestrator → System Prompts. Pipelines only accept Query and Chunk prompt types.
Orchestrator and Answer phases
The Orchestrator keeps two separately ordered prompt sequences:
- Orchestrator phase prompts instruct the model how to evaluate cumulative evidence and choose exactly one permitted next action.
- Answer phase prompts instruct the same model how to generate the final response from frozen evidence after retrieval decisions are complete.
The server adds non-editable safety constraints around these prompts. Retrieved content and tool results remain untrusted data, the Orchestrator must choose from supplied functions, and final answers remain bounded to admitted evidence and authorization-safe citations.
An Orchestrator binding records the fragment, phase, enabled state, and order for one saved revision. The fragment content itself remains shared.
Pipeline prompts
Pipelines maintain ordered prompt lists for two stages:
- Query: semantic and keyword query fragments used by compatible query tools.
- Chunk: chunk-selection fragments used by compatible chunk tools.
Open a Pipeline, attach a compatible fragment inside the Query or Chunk stage, and drag fragments within that stage to change their order. A fragment cannot be moved into an incompatible stage.
See Pipeline composition for the complete stage model.
Tool prompts
Each tool can reference a tool_prompt fragment. Tool prompts explain the tool's evidence contract
and how its output should be interpreted. They do not grant additional data access: the tool's
server-owned evidence manifest and the caller's authorization remain authoritative.
Shared content and active snapshots
Editing a fragment changes its shared library content and can affect several saved Pipelines, tools, or Orchestrator bindings. Review the Used by information before saving.
The active Orchestrator snapshot is immutable. Saving shared prompt content does not modify the snapshot already serving requests. To activate a change:
- Save the fragment.
- Save the affected Pipeline or Orchestrator draft when its binding changed.
- Review validation and readiness in the Orchestrator.
- Apply a new Orchestrator revision.
Apply stores the exact prompt content and content hash inside the new snapshot. Later edits cannot change earlier snapshots or answer turns already in progress.
Seeded fragments
Fresh installations include fragments for:
- the Orchestrator role, evidence sufficiency, and Pipeline selection;
- final-answer behavior, citations, and attachments;
- semantic and keyword query generation;
- chunk selection and pass-through behavior;
- OCR extraction;
- the seeded Pipeline and direct evidence tools.
Seeded slugs include default-orchestrator-role, default-orchestrator-sufficiency,
default-orchestrator-pipeline-selection, default-orchestrator-final-answer,
default-citations, and default-attachments.
Duplicate a seeded fragment when you need a variant with a distinct purpose. Reusing a shared fragment is appropriate when every binding should receive the same future content edits.
Limits
| Field | Constraint |
|---|---|
| Slug | Lowercase letters, numbers, and hyphens; 1–120 characters. |
| Name | 1–200 characters. |
| Description | Up to 1,000 characters. |
| Content | 1–16,384 characters. |
Fragment type and slug are selected when the fragment is created. Edit the name, description, and content later, or duplicate the fragment when a different type or slug is required.