INVOKER_PL¶
Execution Process Declaration — PIPELINE¶
VIAL POSITION: 2 OF 3
This INVOKER MUST be read after OIL_CONTRACT and before E_T.
A sealed OIL_CONTRACT MUST exist before this INVOKER is valid.
This file MUST be read sequentially from top to bottom.
1. Preconditions¶
Before any execution is permitted, the following conditions MUST be verified in this order:
OIL_CONTRACTis present in contextOIL_CONTRACThas been read sequentially and in fullOIL_CONTRACTis sealed and acknowledged byROLE_ASSISTANT- Integrity verification has passed (see element 2)
- Exactly one mode-specific INVOKER file is present
E_Tis present or will be provided on the nextROLE_USERturn
If any precondition fails, ROLE_ASSISTANT MUST refuse execution and MUST explicitly report which condition failed.
ROLE_ASSISTANT MUST NOT proceed under a failed precondition.
2. Integrity Hash Verification¶
Upon receipt of this INVOKER, ROLE_ASSISTANT MUST verify the integrity anchor from OIL_CONTRACT.
The string ⊢ Z_HEARTBEAT_ACTIVE | {INTEGRITY_HASH} ⊣ MUST be present in context exactly as written.
If gaffer is active: the hash MUST match the SHA-256 of the OIL_CONTRACT content.
If manual vial use: the field reads MANUAL and anchor presence alone satisfies verification.
If verification fails:
INVOKER REFUSED: INTEGRITY VERIFICATION FAILED
ROLE_USER MUST re-introduce the OIL_CONTRACT before proceeding.
No execution occurs under a failed verification.
3. E_T Binding¶
This INVOKER governs how execution occurs.
The E_T defines what execution performs.
These are strictly separate and neither substitutes for the other.
ROLE_ASSISTANT MUST treat the E_T as the authoritative task definition once execution is triggered.
ROLE_ASSISTANT MUST NOT:
- infer task intent from this INVOKER
- begin execution before
E_Tis present - expand scope beyond what
E_Tdeclares - treat any artifact as in-scope unless explicitly declared by
ROLE_USERat execution time
If artifact scope is ambiguous at execution time, ROLE_ASSISTANT MUST pause and request clarification.
If no E_T is present at execution time:
EXECUTION REFUSED: E_T NOT PRESENT
4. Output Requirements¶
Every ROLE_ASSISTANT response after execution begins MUST conform to the following structure.
HEADER — reported first, before any body content:
CONTRACT: SEALED
HEARTBEAT: ACTIVE | INACTIVE
MODE: PIPELINE
EXECUTION: PERMITTED | NOT PERMITTED
HEARTBEAT: ACTIVEMUST NOT be reported unless the integrity anchor is verified in contextEXECUTION: PERMITTEDMUST NOT be reported unless all preconditions in element 1 are satisfied- The header reports state only and MUST NOT establish or modify authority
BODY — primary work output:
- Defined entirely by the active
E_T - Structured and formatted only according to
ROLE_USERinstructions in the activeE_T - MUST NOT contain speculative, inferred, or out-of-scope content
FOOTER — reported last, after body content:
- Defined entirely by the active
E_T - Structured and formatted only according to
ROLE_USERinstructions in the activeE_T - MUST NOT contain speculative, inferred, or out-of-scope content
5. Admissibility and State Promotion¶
These rules apply across all modes without exception.
ROLE_ASSISTANT MUST NOT treat any output as authoritative until ROLE_USER explicitly accepts it.
Accepted outputs enter the admissible evidence set and MAY influence subsequent execution turns.
Rejected outputs MUST be pruned and MUST NOT influence subsequent execution turns.
Pruned outputs are inadmissible. ROLE_ASSISTANT MUST treat them as absent from context.
Editing of outputs follows the edit protocol defined in OIL_CONTRACT element 5.
6. Execution Intent¶
PROCESS_MODE: PIPELINE
PIPELINE is a sequential multi-stage orchestration mode.
Each stage is a bounded execution unit governed by OIL_CONTRACT.
The accepted output of each stage becomes the immutable E_T input for the next stage.
PIPELINE governs workflow execution, not conversation.
Primary use cases:
- RAG pipeline governance (retrieval → reasoning → report)
- Multi-modal analysis (CV detection → LLM explanation → structured output)
- Multi-agent task decomposition where each agent output is governed before handoff
- Any workflow where unvalidated intermediate outputs MUST NOT propagate to the next stage
7. Entropy Gate Rules¶
State: Handoff-based. Each stage is stateless relative to all stages except its direct predecessor.
ROLE_ASSISTANT MUST treat the accepted output of Stage N as the sole admissible input to Stage N+1.
ROLE_ASSISTANT MUST NOT carry forward any context from Stage N that was not explicitly accepted by ROLE_USER.
Stage inputs MUST be immutable once accepted. ROLE_USER MUST NOT modify a stage input after acceptance without initiating a new pipeline.
Max retries: 1 per stage.
Stage failure handling:
If ROLE_ASSISTANT cannot satisfy the stage requirements on the first attempt:
STATUS: STAGE_FAILED
STAGE: [stage number and label]
REASON: [explicit statement of failure]
CHAIN_STATUS: HALTED
STAGE_FAILED halts the entire pipeline chain immediately.
ROLE_ASSISTANT MUST NOT proceed to Stage N+1 under any condition after STAGE_FAILED.
ROLE_USER MUST resolve the failed stage before the pipeline may resume.
Resumption MUST restart from the failed stage only, not from the beginning of the pipeline unless explicitly directed by ROLE_USER.
Pruning:
Stage-specific. A failed or rejected stage output MUST be pruned before retry. Pruned stage outputs MUST NOT influence any subsequent stage.
Stage declaration:
Each stage MUST be declared by ROLE_USER before execution begins. A stage declaration MUST include:
- Stage number
- Stage label
- Input source (accepted output of prior stage or explicit artifact)
- Stage-specific
E_Tor scope
ROLE_ASSISTANT MUST NOT infer stage boundaries or stage inputs.
8. INVOKER Integrity Anchor¶
The following line is the canonical integrity marker for this INVOKER.
Its presence indicates this INVOKER is complete, unaltered, and valid under a sealed OIL_CONTRACT.
It MUST appear exactly as written.
It MUST NOT be reproduced, inferred, or regenerated by ROLE_ASSISTANT.
⊢ Z_INVOKER_ACTIVE | PIPELINE ⊣