Glossary¶

This glossary defines terms as they are used within the Entropy-Gated AI Framework and establishes their authoritative meanings for all specifications, manuals, use cases, and execution artifacts contained in this repository. All definitions in this glossary are normative. They are binding for interpretation of the framework and its operation. Where conflicts exist, these definitions override informal language, colloquial understanding, external documentation, industry usage, or alternative interpretations.

Terms are defined to support precision, repeatability, and auditability in governed interactions with probabilistic language models. Definitions are intentionally explicit and operationally grounded to prevent ambiguity during execution, evaluation, or review.

This glossary applies uniformly across all framework components, including but not limited to:

the OIL_CONTRACT
the INVOKER
Execution Transmissions (E_T artifacts)
instruction manuals
use cases and proof-of-concept demonstrations

Unless explicitly stated otherwise, terms defined here retain the same meaning regardless of context, document, or execution mode. No implicit reinterpretation, shorthand, or inferred meaning is permitted. The glossary does not attempt to redefine general computing or mathematical concepts beyond what is necessary to ensure correct operation of the Entropy-Gated AI Framework. Where a term is adapted from an external discipline, its meaning is constrained to the scope and intent of this framework. Understanding and adhering to these definitions is a prerequisite for correct use of the Entropy-Gated AI Framework.

Acceptance¶

An explicit, deliberate action taken by ROLE_USER indicating that a ROLE_ASSISTANT output is correct, complete, and permitted to influence subsequent execution, probabilistic reasoning, or decision-making.

Acceptance establishes an acceptance boundary, after which an output may be referenced, reused, summarized, or promoted as authoritative state. Outputs that have not been explicitly accepted remain non-authoritative, regardless of perceived correctness or confidence.

Acceptance is the only mechanism by which State Promotion occurs within the framework.

Accepted outputs are stamped by the EGAF gaffer with:

<<<Z::ACCEPTED::T={turn}>>>

Acceptance Boundary¶

The conceptual and operational boundary separating non-authoritative probabilistic outputs from accepted, authoritative state.

Only outputs that cross the acceptance boundary through explicit ROLE_USER action may influence subsequent execution or probabilistic reasoning. The acceptance boundary prevents silent State Promotion and uncontrolled propagation of probabilistic artifacts.

Artifact¶

A discrete input or reference object used during governed Execution.

An Artifact: - is explicitly declared in scope by ROLE_USER - may be referenced by an Execution Transmission - may be required by an INVOKER or bounded by the OIL_CONTRACT - MUST NOT be inferred, assumed, or substituted without explicit Authority

Artifacts exist to preserve auditability and prevent implicit scope expansion.

Authority¶

The exclusive right to define intent, declare scope, permit execution, accept or reject outputs, and perform State Promotion.

Within this framework, all Authority originates with ROLE_USER. ROLE_ASSISTANT possesses no independent Authority and cannot assume, infer, or manufacture Authority under any condition.

Authority is never delegated implicitly and is never shared.

Authority Erosion¶

The gradual degradation of Authority caused by overreliance on probabilistic outputs, inferred intent, or ROLE_ASSISTANT guidance.

Authority Erosion occurs when ROLE_USER defers judgment, acceptance, or rejection decisions implicitly rather than explicitly. Authority Erosion invalidates governance guarantees even in the absence of explicit rule violations.

Baseline Artifact¶

An Artifact representing the reference state used for comparison during governed Execution.

A Baseline Artifact: - is declared in scope by ROLE_USER - is treated as authoritative for baseline state comparisons within the declared task - MUST be distinguished from a Current Artifact to prevent ambiguity

Capsule¶

A standalone, single-artifact governance file containing exactly one framework component — either an OIL_CONTRACT, an INVOKER variant, or an E_T.

A Capsule: - contains one artifact only — it is not a composite package - is intended for portable, modular deployment - exists in two variants: gaffer (integrity anchor field populated with SHA-256 hash) and manual (field reads MANUAL) - is stored on the Shelf

Capsules are assembled into Vials at runtime. A Vial is the composed execution unit; a Capsule is the individual component.

Capsules are a planned extension of the framework.

Charged¶

A Vial type indicating that the vial contains an OIL_CONTRACT, an INVOKER, and a bound Execution Transmission, and is ready for governed Execution.

A Charged vial: - has all three vial positions filled - is in the final pre-execution state - MUST NOT proceed to execution unless all governance conditions are verified

Context Contamination¶

A failure mode in which invalid, rejected, exploratory, or non-authoritative probabilistic outputs remain present in the interaction context and influence subsequent Execution, Probabilistic Reasoning, or operator decisions.

Context Contamination occurs when outputs that have not crossed the Acceptance Boundary are allowed to persist and exert influence through proximity, reference, or implicit reuse. The contamination is structural rather than semantic; the mere presence of non-authoritative content in context is sufficient to compromise governance, even if the content is not explicitly cited.

Context Contamination commonly results from: - failure to Prune rejected outputs - issuing Retries without editing the prior ROLE_USER instruction - continuing execution after partial failure - allowing exploratory or speculative outputs to remain in scope - relying on conversational continuity instead of explicit acceptance

Context Contamination directly increases Interaction-Level Entropy and enables Implicit State Promotion. Once contamination occurs, repeatability and auditability are no longer guaranteed, even if subsequent outputs appear correct.

The only corrective action for Context Contamination is explicit Pruning followed by a clean Retry from an edited instruction. ROLE_ASSISTANT MUST NOT assume contamination has been resolved unless ROLE_USER performs explicit corrective action.

Current Artifact¶

An Artifact representing the observed or assessed state used for comparison during governed Execution.

A Current Artifact: - is explicitly declared in scope by ROLE_USER - represents the present or measured state under evaluation - is compared against a Baseline Artifact - MUST NOT be substituted, inferred, or reused across executions without explicit Authority

The distinction between Baseline Artifacts and Current Artifacts is mandatory for auditability and repeatability.

EDIT (Disposition State)¶

An output disposition state indicating that a ROLE_ASSISTANT output requires targeted revision before it may be accepted.

An output in the EDIT state is governed by the Edit Protocol defined in OIL_CONTRACT element 5. The output enters a structured revision loop using REVISE or QUERY edit types and may only be promoted to Accepted state after the revision is explicitly accepted by ROLE_USER.

Edit Protocol¶

A structured revision mechanism defined in OIL_CONTRACT element 5 that governs how specific regions of a ROLE_ASSISTANT output are revised without discarding the entire response.

The Edit Protocol defines two edit types: - REVISE — a directive to rewrite a specific region of output against a correction instruction - QUERY — a question about a prior output with no regeneration

Under the Edit Protocol: - only content within ⟨REVISE⟩...⟨/REVISE⟩ tags re-enters probabilistic generation - all content outside those tags is implicitly accepted verbatim and MUST NOT be modified - ROLE_ASSISTANT MUST NOT regenerate, reinterpret, or alter content outside marked regions

The Edit Protocol enables surgical Pruning of specific output regions while preserving accepted content, confining Interaction-Level Entropy to the declared revision scope.

Entropy¶

A measure of uncertainty, variability, or unpredictability inherent in probabilistic systems.

Within this framework, Entropy is treated as a governing concept applicable across multiple dimensions of AI interaction — including but not limited to token-level generation uncertainty, interaction-level drift from accumulated unvalidated outputs, and semantic uncertainty arising from underspecified inputs or inferred scope.

Entropy is not treated as a flaw but as an engineering constraint that must be governed. The framework's name reflects this: entropy is not eliminated — it is gated.

The primary operational form addressed by this framework is Interaction-Level Entropy, but the governance model is designed to be applicable wherever probabilistic uncertainty must be bounded and audited.

Entropy Gating¶

The deliberate regulation of when and how Probabilistic Reasoning is permitted to influence outputs or accepted state.

Entropy Gating does not eliminate uncertainty. Instead, it: - bounds when Probabilistic Reasoning may occur - constrains how outputs may influence state - prevents uncontrolled accumulation of uncertainty across retries and turns

Entropy Gating is enforced through the combined operation of the OIL_CONTRACT, INVOKER, explicit Process Modes, and Acceptance rules.

Entropy-Gated AI Framework¶

A governed interaction framework for controlling, constraining, and auditing Probabilistic Reasoning performed by a ROLE_ASSISTANT.

The Entropy-Gated AI Framework: - treats Entropy as an engineering constraint across all dimensions of AI interaction - enforces Entropy Gating to prevent uncontrolled accumulation of uncertainty - separates planning (Hub) from governed Execution (Lab) - requires explicit Authority, verification, and Acceptance before State Promotion - achieves Quasi-Deterministic outcomes through contracts, execution processes, and disciplined Pruning - is vendor-agnostic, model-agnostic, and modality-agnostic

The framework is composed of, but not limited to: - the OIL_CONTRACT - the INVOKER - Execution Transmissions - declared Process Modes - explicit Acceptance Boundaries

Execution¶

A bounded instance of governed Probabilistic Reasoning initiated by ROLE_USER under a sealed OIL_CONTRACT, an acknowledged INVOKER, and a valid Execution Transmission.

Execution: - never begins implicitly - never occurs at INVOKER paste time - begins only when a valid Execution Transmission is activated under an armed INVOKER - always operates within a declared Process Mode

Execution ends when outputs are accepted or pruned.

Execution Process¶

A declared operational mode that defines how Probabilistic Reasoning proceeds, how inputs are bound, and how outputs may influence subsequent interaction.

Execution Processes are explicitly selected via the INVOKER and include: - SINGLE_PASS (SP) - MULTI_TURN (MT) - INTERACTIVE (IX) - PIPELINE (PL) - VERIFICATION (VF) - REVISION_AUGMENTED (RA)

Exactly one Execution Process may be active per INVOKER. Execution Processes are a primary mechanism for Entropy Gating.

Execution Transmission (ET)¶

A structured, human-authored or hub generated artifact that defines what work is to be performed, under what constraints, and with what reporting requirements. It is the sole mechanism by which Execution intent is declared. It is VIAL POSITION 3 OF 3.

An Execution Transmission is composed of six mandatory sections:

Objective — one-sentence execution objective (EXECUTION_TRANSMISSION) and payload modality declaration (PAYLOAD_MODALITY)
Scope — artifacts, entities/systems, timeframe/context, and explicit exclusions
Execution Requirements — the specific operations ROLE_ASSISTANT MUST perform
Constraints — binding restrictions ROLE_ASSISTANT MUST NOT violate
Output Requirements — required format, structure, and tone
Reporting Format — required sections and their declared order

All fields MUST be filled by ROLE_USER before submission. Unfilled fields (marked < >) MUST be surfaced as ambiguity by ROLE_ASSISTANT. ROLE_ASSISTANT MUST NOT infer values for unfilled fields.

An Execution Transmission has no authority until explicitly pasted by ROLE_USER in an active Lab and does not execute work by itself.

Execution Transmissions exist in two variants: GAFFER (delivered via API user message) and MANUAL (pasted into chatbot interface).

GOLDEN (Disposition State)¶

An output disposition state indicating that ROLE_USER has accepted the output and designated it for permanent record.

An output in the GOLDEN state: - is appended to the context window and written to file (long-term storage) - is stamped by the EGAF gaffer with:

<<<Z::GOLDEN::T={turn}>>>

GOLDEN is the highest disposition state. It represents both acceptance and explicit elevation to long-term storage.

Governance¶

The set of explicit rules, constraints, Authority boundaries, and structural requirements that control how Probabilistic Reasoning is permitted to occur.

Governance is enforced through: - the OIL_CONTRACT - the INVOKER - Execution Processes - Acceptance and Pruning rules

Governance exists to preserve correctness, repeatability, and auditability in probabilistic systems.

Heartbeat Continuity Rule¶

A governance requirement stating that the OIL_CONTRACT integrity anchor must remain verifiable throughout an active Execution session.

Under the Heartbeat Continuity Rule: - ROLE_ASSISTANT MUST report HEARTBEAT: ACTIVE when the anchor field contains a SHA-256 hash (gaffer mode) or the literal value MANUAL (manual mode) - ROLE_ASSISTANT MUST report HEARTBEAT: INACTIVE when the anchor field is unfilled ({INTEGRITY_HASH}) - HEARTBEAT: INACTIVE MUST trigger immediate execution halt; no task output is produced

The rule is grounded in attention behavior: constraints placed closer to generation time are more reliably enforced. Positioning the OIL_CONTRACT at session start and verifying the anchor throughout preserves governance integrity across long contexts.

Hub¶

A freeform control and coordination space used for planning, discussion, review, and decision-making.

The Hub: - does not require the framework to be active - does not enforce Governance - is where Execution Transmissions are planned and authored

The Hub functions as a management and control plane, distinct from governed Execution environments.

Implicit State Promotion¶

The unauthorized promotion of probabilistic outputs to authoritative state without explicit Acceptance by ROLE_USER.

Implicit State Promotion occurs when generated content is reused, summarized, referenced, or relied upon without crossing the Acceptance Boundary. Implicit State Promotion is prohibited and constitutes a primary driver of Interaction-Level Entropy.

Interaction-Level Entropy¶

The accumulation of uncertainty introduced when Probabilistic Reasoning outputs are reused, referenced, summarized, or implicitly promoted across interactions without explicit Acceptance.

Interaction-Level Entropy arises from interaction behavior rather than model internals and reflects how probabilistic artifacts persist, compound, and influence subsequent reasoning over time.

Interaction-Level Entropy increases through: - rejected outputs remaining in context - retries built upon prior probabilistic generations - ambiguous or underspecified instructions - silent assumptions or inferred intent - implicit reuse of unaccepted outputs

Unchecked Interaction-Level Entropy compounds across turns and retries, degrading repeatability, auditability, and trustworthiness even when individual outputs appear correct.

Interaction-Level Entropy Threat¶

A class of operational risk arising when Interaction-Level Entropy degrades the correctness, repeatability, or auditability of governed Execution.

The Interaction-Level Entropy Threat manifests through implicit state promotion, contaminated retries, ambiguity propagation, and erosion of Authority rather than through model compromise, malicious action, or external attack. This threat is systemic, cumulative, and interaction-driven, and must be mitigated through Entropy Gating, explicit Acceptance, and disciplined Pruning.

INTERACTIVE (IX)¶

A governed Execution Process that permits clarification and question asking prior to or during Execution.

INTERACTIVE: - allows ROLE_ASSISTANT to request clarification - prohibits assumption-making - pauses Execution on ambiguity - prioritizes correctness over speed

INTERACTIVE is used when inputs are incomplete or intent must be confirmed before execution proceeds.

INVOKER¶

A canonical Execution declaration that arms an Execution Process under a sealed OIL_CONTRACT. It is VIAL POSITION 2 OF 3.

The INVOKER: - declares the active Process Mode - defines Entropy Gating rules for the selected mode - establishes Authority-bounded execution permissions - verifies the OIL_CONTRACT integrity anchor upon receipt - does not bind inputs - does not execute work

The INVOKER controls how Execution occurs, not what work is performed.

A sealed OIL_CONTRACT MUST exist before any INVOKER is valid. Exactly one mode-specific INVOKER file may be present per session. Each INVOKER carries its own integrity anchor: ⊢ Z_INVOKER_ACTIVE | {MODE} ⊣

INVOKER_RA (REVISION_AUGMENTED)¶

A planned INVOKER variant implementing a sliding context window architecture for iterative, revision-driven execution.

Under INVOKER_RA: - each revision cycle contains only the immediately prior accepted output and the new revision instruction - accepted outputs are promoted to long-term storage (golden file) - pruned outputs are routed to garbage and permanently removed from context - the context window functions as RAM — bounded and non-accumulating - the golden file functions as long-term storage — a persistent, ordered record of accepted outputs

INVOKER_RA is designed to prevent context accumulation in long iterative sessions while preserving a clean record of all accepted work. This mode is pending build and is not yet available in the current release.

Lab¶

A scoped Execution environment in which the framework is active and Governance is enforced.

Within a Lab: - the OIL_CONTRACT governs behavior - the INVOKER arms Execution - Entropy Gating is enforced - outputs are non-authoritative until explicitly accepted - the session header reports: CONTRACT: SEALED, HEARTBEAT: ACTIVE, MODE: {mode}, EXECUTION: PERMITTED

Labs are where analysis and Execution occur under constraint.

MULTI_TURN (MT)¶

A governed Execution Process that permits bounded, iterative Probabilistic Reasoning across multiple turns.

MULTI_TURN: - allows intermediate outputs to be produced - requires explicit Acceptance before any output may influence subsequent turns - prohibits reuse of rejected outputs - remains subject to Entropy Gating at all times

MULTI_TURN is used when staged reasoning is required but auditability must be preserved.

OIL_CONTRACT¶

The governance artifact that defines Authority, constraints, prohibitions, structural rules, and continuity requirements for an Execution session. It is VIAL POSITION 1 OF 3.

The OIL_CONTRACT is structured in eight elements:

Purpose and Scope (including SESSION_TIMESTAMP)
Roles and Authority
Constraints and Prohibitions
Markdown Structural Authority
Edit Protocol
Output Disposition Protocol
Contract Acknowledgment and Seal
Contract Anchor (Z_HEARTBEAT_ACTIVE)

Once sealed, the OIL_CONTRACT: - governs all ROLE_ASSISTANT behavior - constrains Probabilistic Reasoning, Execution, and output formatting - remains active until explicitly revoked by ROLE_USER

No Execution, analysis, or Probabilistic Reasoning is permitted unless an OIL_CONTRACT is sealed and verifiable. No INVOKER may be activated unless this contract is sealed.

Orchestration Initialization Loader (OIL)¶

See OIL_CONTRACT.

Output Disposition Protocol¶

The governance mechanism defined in OIL_CONTRACT element 6 that requires every ROLE_ASSISTANT output to be explicitly disposed of by ROLE_USER before the session advances.

The four disposition states are:

State	Meaning
ACCEPTED	Output is accepted. Appended to context window. Stamped `<<<Z::ACCEPTED::T={turn}>>>`
GOLDEN	Output is accepted and marked for permanent record. Written to file. Stamped `<<<Z::GOLDEN::T={turn}>>>`
PRUNED	Output is rejected. Never enters context. ROLE_USER may resubmit same or edited E_T.
EDIT	Output requires targeted revision. Governed by the Edit Protocol.

Only ROLE_USER may assign a disposition state. Disposition is never inferred or assumed.

PIPELINE (PL)¶

A governed Execution Process for multi-stage, sequential execution where the accepted output of each stage becomes the immutable input for the next.

Under PIPELINE: - failure in any stage triggers STAGE_FAILED and halts the entire chain - intermediate outputs MUST be explicitly accepted before the next stage begins - no unvalidated data may propagate between stages - the mode governs multi-model orchestration, RAG pipelines, and cross-modal handoffs

PIPELINE prevents unvalidated outputs from silently contaminating downstream execution stages.

Primed¶

A Vial type containing an OIL_CONTRACT and an INVOKER, but no Execution Transmission has yet been provided.

A Primed vial: - is governance-ready - is awaiting task intent from ROLE_USER - MUST NOT execute until charged with an Execution Transmission

Primed vials may be pre-authored and stored on the Shelf for repeated use.

Probabilistic Reasoning¶

Reasoning produced by sampling from probability distributions over possible outputs.

Probabilistic Reasoning is inherently non-deterministic and may vary across Executions even with identical inputs. Within this framework, Probabilistic Reasoning is treated as powerful but unsafe unless governed.

Governance ensures Probabilistic Reasoning remains bounded and accountable.

Process Mode¶

A declared Execution behavior that defines how Probabilistic Reasoning is permitted to occur.

Supported Process Modes include: - SINGLE_PASS (SP) - MULTI_TURN (MT) - INTERACTIVE (IX) - PIPELINE (PL) - VERIFICATION (VF) - REVISION_AUGMENTED (RA)

Exactly one Process Mode MUST be active per INVOKER. Process Modes are a primary mechanism for Entropy Gating.

Process Mode Invariant¶

A mandatory rule stating that exactly one Process Mode governs an Execution from start to termination.

Under the Process Mode Invariant: - process modes MUST NOT be combined - process modes MUST NOT be switched mid-execution - violations require Refusal or execution termination

This invariant preserves determinism of interaction structure and prevents uncontrolled entropy escalation.

PRUNED (Disposition State)¶

An output disposition state indicating that ROLE_USER has rejected the output.

A Pruned output: - NEVER enters the context window - is routed to garbage - is inadmissible — ROLE_ASSISTANT MUST treat it as absent from context - carries no anchor stamp

ROLE_USER MAY resubmit the same E_T or provide an edited E_T to continue after pruning.

Pruning¶

The deliberate removal of rejected or invalid outputs from the interaction context.

Pruning is performed by: - editing the prior ROLE_USER Execution Transmission - removing references to rejected outputs - retrying Execution from a clean state

Pruning resets Interaction-Level Entropy and prevents contamination from failed Probabilistic Reasoning.

Quasi-Deterministic¶

Behavior that is not mathematically deterministic but produces consistent, repeatable outcomes under equivalent inputs, constraints, Process Modes, and Acceptance decisions.

Quasi-Determinism is achieved through: - Entropy Gating - explicit Acceptance Boundaries - disciplined Pruning - controlled Retries

The framework governs interaction to achieve quasi-determinism, not to guarantee determinism.

QUERY (Edit Type)¶

An Edit Protocol interaction type used when ROLE_USER wishes to ask a question about a prior output without changing it.

The message structure contains no ⟨REVISE⟩ tags — their absence signals a question, not a revision. ROLE_ASSISTANT MUST NOT re-generate or alter any prior output and MUST answer the question only.

REVISE (Edit Type)¶

An Edit Protocol interaction type used when ROLE_USER wishes to change part of a prior output.

The message MUST be structured as:

ROLE_ASSISTANT_OUTPUT:
[prior ROLE_ASSISTANT output, reproduced verbatim]
⟨REVISE⟩[region requiring revision]⟨/REVISE⟩

ROLE_USER_CONTENT:
[revision instruction targeting the marked region]

Only content within ⟨REVISE⟩...⟨/REVISE⟩ tags re-enters probabilistic generation. All content outside those tags is implicitly accepted verbatim and MUST NOT be modified.

ROLE_ASSISTANT¶

A probabilistic language model operating under constraint within the framework.

ROLE_ASSISTANT: - performs Execution under constraint - generates Probabilistic Reasoning outputs - has no Authority - must halt or refuse under violation - cannot assume intent or perform implicit State Promotion - MAY generate outputs only within the permissions and constraints defined by the active OIL_CONTRACT

ROLE_SYSTEM¶

The role that enforces the rules of the OIL_CONTRACT.

ROLE_SYSTEM enforces governance but does not perform tasks, supply domain knowledge, or define Execution Transmission intent.

ROLE_USER¶

The human operator with sole Authority over Execution.

ROLE_USER is responsible for: - sealing the OIL_CONTRACT - arming the INVOKER - declaring intent through an Execution Transmission - providing inputs and scope - performing Acceptance or Rejection - performing Pruning and initiating Retries - activating, revoking, or terminating the contract

All Governance decisions are human-directed. ROLE_USER authority MUST NOT be assumed, inferred, or delegated by ROLE_ASSISTANT.

Sealed¶

A Vial type containing an OIL_CONTRACT for combining with an INVOKER and E_T in order to establish governance for the session.

A Sealed vial: - has not yet had an INVOKER armed - MUST be sealed

Sealed is the first state in the vial lifecycle.

SESSION_TIMESTAMP¶

A timestamp field in OIL_CONTRACT element 1 recording the authoritative reference point for the session.

Behavior: - If filled: ROLE_ASSISTANT MUST record it as the session reference and MUST NOT assume events or facts that postdate it are within reliable knowledge - If unfilled ({TIMESTAMP}): ROLE_ASSISTANT MUST treat the session date as unknown and flag it during acknowledgment

The SESSION_TIMESTAMP check is item 8 of the seal acknowledgment checklist in OIL_CONTRACT element 7.

Shelf¶

The directory structure used to organize and store Vials and Capsules within the framework repository.

The Shelf contains: - sealed/ — vials at the Sealed state - primed/ — vials at the Primed state - charged/ — vials at the Charged state - capsules/ — standalone single-artifact capsule files

The Shelf enables repeatable, organized access to governance artifacts without requiring reassembly from scratch for each session.

SINGLE_PASS (SP)¶

A deterministic, atomic, one-shot Execution Process.

SINGLE_PASS: - executes once using inputs provided in the active E_T - permits no clarification questions - permits no iterative refinement - produces one bounded output - is stateless — ROLE_ASSISTANT MUST NOT reference any data outside the immediate E_T payload

If ROLE_ASSISTANT cannot satisfy the E_T requirements with the provided inputs, it MUST report:

STATUS:  FAILED
REASON:  [explicit statement of what input is missing or insufficient]

No partial output is produced on failure. ROLE_USER MAY edit the active E_T and resubmit.

SINGLE_PASS is used when inputs are complete and one governed output is required.

State Promotion¶

The act of allowing an output to influence subsequent Probabilistic Reasoning, decisions, or Execution.

State Promotion occurs only through explicit Acceptance by ROLE_USER. Implicit State Promotion is prohibited.

Structural Authority¶

The rule defined in OIL_CONTRACT element 4 that Markdown structure is binding and authoritative across all governance artifacts.

Under Structural Authority, ROLE_ASSISTANT MUST treat the following as load-bearing structural declarations — not formatting preferences: - heading levels (#, ##, ###) — define element hierarchy and set boundaries - ordered lists (1., 2., 3.) — define sequence-dependent requirements - unordered lists (-) — define non-sequential constraint sets - paragraph boundaries — define discrete logical units - explicit line breaks — define structural separation

Alteration of heading levels in any governance artifact constitutes a contract violation. When ambiguity exists between natural language interpretation and Markdown structure, Markdown structure takes precedence.

Uncontrolled Entropy¶

The accumulation of uncertainty resulting from failures to enforce Governance, Acceptance, and Pruning discipline during governed interaction.

Uncontrolled Entropy is caused by: - implicit assumptions - silent retries without Pruning - context contamination from failed executions - reuse or reference of rejected outputs - implicit State Promotion

Uncontrolled Entropy represents a failure of Governance, not a failure of the underlying model.

Use Case¶

A documented, concrete application of the framework demonstrating governed Execution against a real or realistic scenario.

Use Cases include: - artifacts - Execution Transmissions - outputs - evaluation

Use Cases establish credibility through demonstrated discipline.

Validation¶

The act of evaluating outputs against declared constraints, requirements, and expectations.

Validation is performed by ROLE_USER and precedes Acceptance.

VERIFICATION (VF)¶

A governed Execution Process in which ROLE_ASSISTANT is prohibited from generating new content and may only validate, compare, and report.

Under VERIFICATION: - output is restricted to VALID | INVALID and supporting reasoning - no new probabilistic generation is permitted - this mode represents zero-entropy output — the most constrained expression of Entropy Gating

VERIFICATION is used when auditability and correctness verification are the sole objectives.

Vial¶

A composed governance artifact that packages an OIL_CONTRACT, an INVOKER, and optionally an Execution Transmission into a complete, ready-to-use execution unit.

A Vial can be of three three types: - Sealed — Contains an OIL_CONTRACT - Primed — Contains an OIL_CONTRACT and INVOKER - Charged — Contains an OIL_CONTRACT, INVOKER, and E_T.

Vials exist in two implementation variants:

Gaffer — the EGAF gaffer populates the integrity anchor field with a SHA-256 hash. HEARTBEAT: ACTIVE is expected. Intended for API use.
Manual — the integrity anchor field reads MANUAL. HEARTBEAT: ACTIVE is still expected. Intended for chatbot UI use.

In both variants, HEARTBEAT: INACTIVE indicates a configuration problem — specifically an unfilled {INTEGRITY_HASH} field — and MUST halt execution.

Vials are stored on the Shelf. They differ from Capsules, which are standalone single-artifact files.

Z_HEARTBEAT_ACTIVE¶

The canonical integrity and continuity marker for the OIL_CONTRACT, appearing as:

⊢ Z_HEARTBEAT_ACTIVE | {field} ⊣

Heartbeat states are determined by the anchor field value:

HEARTBEAT: ACTIVE — field contains a SHA-256 hash (gaffer mode) or the literal value MANUAL (manual mode); anchor is present and valid; execution may proceed
HEARTBEAT: INACTIVE — field is unfilled ({INTEGRITY_HASH}); anchor is not valid; execution MUST halt immediately; no task output is produced

The anchor MUST appear exactly as written. It MUST NOT be reproduced, inferred, or regenerated by ROLE_ASSISTANT.

An unfilled {INTEGRITY_HASH} field MUST be flagged during acknowledgment (OIL_CONTRACT element 7, item 7).