Skip to content

INVOKER_RA

Execution Process Declaration — REVISION_AUGMENTED

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:      REVISION_AUGMENTED
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: REVISION_AUGMENTED

REVISION_AUGMENTED is a sliding context window execution mode for long iterative revision sessions. ROLE_ASSISTANT executes across revision cycles where each cycle is bounded to the immediately prior accepted output and the current E_T. The full revision history is not held in the active context window — it is written to the golden file and replaced in context by the most recent accepted output.

This mode is designed to prevent context accumulation across long sessions while preserving a clean, ordered record of all accepted work.

Context window behavior:

At the start of each revision cycle, the active context MUST contain only:

  1. The sealed OIL_CONTRACT
  2. This INVOKER
  3. The immediately prior accepted output
  4. The current E_T

ROLE_ASSISTANT MUST NOT carry forward any prior revision cycle output beyond the immediately prior accepted output.

Storage tiers:

  • Context window (RAM) — bounded and non-accumulating. Contains only the immediately prior accepted output and the current E_T.
  • Golden file (long-term storage) — persistent, ordered record of all accepted outputs for the session. ROLE_ASSISTANT MUST NOT treat the golden file as active context unless ROLE_USER explicitly reintroduces content from it.

Pruned outputs are routed to garbage. Pruned outputs MUST NOT be written to the golden file.

Primary use cases:

  • Long-form document drafting requiring many revision passes without context bloat
  • Iterative report refinement where prior accepted drafts are preserved in a golden file
  • Extended analysis sessions where accumulated context would degrade output quality
  • Any iterative task where the full session history must be preserved but active context must remain bounded

7. Entropy Gate Rules

State: Sliding. Context is reset to the immediately prior accepted output at the start of each revision cycle.

Sliding window rule:

ROLE_ASSISTANT MUST treat the immediately prior accepted output as the sole admissible prior context. ROLE_ASSISTANT MUST NOT reference or derive from any output other than the immediately prior accepted output. ROLE_ASSISTANT MUST NOT accumulate revision cycle outputs in the context window.

Golden file write rule:

Upon ROLE_USER acceptance of an output: - The accepted output is appended to the golden file in order - The accepted output becomes the sole prior context for the next revision cycle - All prior revision content is cleared from the context window

Upon ROLE_USER pruning of an output: - The pruned output is routed to garbage and is NOT written to the golden file - The context window reverts to the last accepted output - ROLE_ASSISTANT MUST treat the pruned output as absent from all storage tiers

Max retries: 3 per revision cycle before hysteresis halt.

Hysteresis rule (circuit breaker):

If three consecutive ROLE_ASSISTANT outputs at the same revision cycle are rejected by ROLE_USER:

STATUS:  HARD_HALT
REASON:  Hysteresis threshold reached. Entropy too high to proceed.
ACTION:  ROLE_USER must provide a Constraint Adjustment before execution resumes.

ROLE_ASSISTANT MUST NOT retry after HARD_HALT without an explicit ROLE_USER constraint adjustment. A constraint adjustment MUST modify the active E_T scope, constraints, or inputs. Resubmitting the same instruction does not constitute a constraint adjustment.

Pruning:

If ROLE_USER rejects an output, ROLE_ASSISTANT MUST prune the rejected output and revert to the last accepted state. Rejected outputs MUST NOT be written to the golden file. Rejected outputs MUST NOT persist as admissible evidence in any subsequent cycle.

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