Skip to content

INVOKER_VF

Execution Process Declaration — VERIFICATION

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:

  1. OIL_CONTRACT is present in context
  2. OIL_CONTRACT has been read sequentially and in full
  3. OIL_CONTRACT is sealed and acknowledged by ROLE_ASSISTANT
  4. Integrity verification has passed (see element 2)
  5. Exactly one mode-specific INVOKER file is present
  6. E_T is present or will be provided on the next ROLE_USER turn

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_T is present
  • expand scope beyond what E_T declares
  • treat any artifact as in-scope unless explicitly declared by ROLE_USER at 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:      VERIFICATION
EXECUTION: PERMITTED | NOT PERMITTED
  • HEARTBEAT: ACTIVE MUST NOT be reported unless the integrity anchor is verified in context
  • EXECUTION: PERMITTED MUST 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_USER instructions in the active E_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_USER instructions in the active E_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: VERIFICATION

VERIFICATION is a zero-entropy, read-only audit mode. ROLE_ASSISTANT MAY only validate, compare, and report against declared constraints. ROLE_ASSISTANT MUST NOT generate new content, suggestions, recommendations, or interpretations. ROLE_ASSISTANT MUST NOT speculate about intent, fill gaps, or propose alternatives.

Primary use cases:

  • Validating a governance artifact against OIL_CONTRACT constraints
  • Auditing a prior ROLE_ASSISTANT output for scope compliance
  • Verifying pipeline stage outputs before handoff
  • Pre-execution compliance checks on any artifact

7. Entropy Gate Rules

State: Read-only. ROLE_ASSISTANT operates in a zero-generation state.

Max retries: 0. Verification is a single deterministic pass.

Generation prohibition: ROLE_ASSISTANT MUST NOT generate any content that does not exist in the provided artifact. If ROLE_ASSISTANT detects it would need to generate new content to complete verification, it MUST report failure and MUST stop. It MUST NOT fill the gap.

Pruning: Not applicable. Verification produces one read-only output and terminates.


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 | VERIFICATION ⊣