Quick Start¶

Entropy-Gated AI Framework¶

Who is this for¶

The Entropy-Gated AI Framework is for anyone who interacts with a language model and needs the output to be correct, controlled, and auditable.

Use it when:

correctness matters more than speed
results must be reviewable and auditable
retries must not accumulate hidden context
probabilistic behavior must be controlled

Core idea in one paragraph¶

The framework governs language model interactions through a three-part composition called a vial. Each set is a document in its own right, with sections called elements — each element defines a specific rule, requirement, or grouping of the two that governs how the session runs. A vial is loaded in sequence: the OIL_CONTRACT seals governance, the INVOKER arms an execution process, and the E_T defines what work is performed. Each position advances the vial state — Sealed, then Primed, then Charged — at which point execution is permitted. Every output is non-authoritative until ROLE_USER explicitly accepts it. Unaccepted outputs are pruned by editing the prior user turn before retrying, which architecturally removes them from context and prevents entropy accumulation.

What a vial is¶

A vial is a composed governance artifact that packages the three framework positions into a ready-to-use execution unit.

Position	Artifact	Role
1 of 3	`OIL_CONTRACT`	Governance law — authority, constraints, rules
2 of 3	`INVOKER`	Execution process declaration — how execution occurs
3 of 3	`E_T`	Execution Transmission — what work is performed

All three vial types must be used in sequence to reach a Charged state. Each type is a separate file stored on the Shelf and contains a specific subset of the three positions:

Type	Contents	What it needs next
Sealed	`OIL_CONTRACT` only	INVOKER, then E_T
Primed	`OIL_CONTRACT` + `INVOKER` (process armed)	E_T only
Charged	`OIL_CONTRACT` + `INVOKER` + `E_T`	Nothing — ready to execute

The reason vials are separated into distinct files rather than delivered as a single artifact is customization. A user may want to inspect or edit the OIL_CONTRACT before selecting a process mode, or review and modify the INVOKER before committing to an E_T. Loading one position at a time keeps each component editable before the next is introduced.

Pre-composed vials are stored on the Shelf at shelf/vials/. Two variants exist for each type:

Manual — paste into a chatbot interface
Gaffer — delivered programmatically via the EGAF gaffer

Process modes¶

Exactly one process mode must be declared in the INVOKER. Choose the mode before selecting a vial.

Mode	Description
`SINGLE_PASS`	Atomic, one-shot execution. Stateless. One output, no retries.
`MULTI_TURN`	Iterative execution across multiple turns. Each turn derives from the last accepted output only. Hysteresis halt after 3 consecutive rejections.
`INTERACTIVE`	Governed conversational mode. Relaxed output structure. Passive entropy monitoring.
`PIPELINE`	Sequential multi-stage orchestration. Accepted output of each stage becomes immutable input for the next. Stage failure halts the chain.
`VERIFICATION`	Zero-entropy, read-only audit mode. ROLE_ASSISTANT may only validate, compare, and report. No new content generated.
`REVISION_AUGMENTED`	A sliding context window architecture for iterative, revision-driven execution

Step-by-step (manual, minimal)¶

1. Choose a process mode¶

Decide which process mode fits the task. When uncertain, SINGLE_PASS is the default for fully-defined tasks. INTERACTIVE is the default for governed general use.

2. Get a vial from the Shelf¶

Navigate to shelf/vials/ and choose a starting point based on how much customization you need.

Start from Primed if you want to use the default OIL_CONTRACT as-is and only need to choose a process mode:

primed/manual/VIAL_SP_PRIMED.md — SINGLE_PASS
primed/manual/VIAL_MT_PRIMED.md — MULTI_TURN
primed/manual/VIAL_IX_PRIMED.md — INTERACTIVE
primed/manual/VIAL_PL_PRIMED.md — PIPELINE
primed/manual/VIAL_VF_PRIMED.md — VERIFICATION
primed/manual/VIAL_RA_PRIMED.md — REVISION_AUGMENTED

Start from Sealed if you want to inspect or edit the OIL_CONTRACT before selecting a process mode. After pasting the Sealed vial and receiving acknowledgment, paste the INVOKER of your choice on the next turn.

Fill the SESSION_TIMESTAMP field if applicable before pasting.

3. Open a Lab and paste the vial¶

Open a new chat to act as the Lab. Paste the entire primed or charged vial.

ROLE_ASSISTANT will read the contract sequentially, acknowledge it, confirm the seal, verify the heartbeat anchor, and confirm the INVOKER is armed.

Vial state: Primed. No execution has occurred.

4. Paste the Execution Transmission¶

On the next ROLE_USER turn, paste a completed E_T. All fields must be filled, altered, or removed before pasting. ROLE_ASSISTANT will surface any unfilled field as ambiguity and will not infer values for it.

Vial state: Charged. Execution begins.

5. Review the output¶

All outputs are non-authoritative by default. Review before taking any disposition action.

6. Dispose of the output¶

ROLE_USER must explicitly dispose of every output before the session advances. Four disposition states are defined:

State	Meaning
`ACCEPTED`	Output enters context. Stamped `<<<Z::ACCEPTED::T={turn}>>>`
`GOLDEN`	Output accepted and written to permanent record. Stamped `<<<Z::GOLDEN::T={turn}>>>`
`PRUNED`	Output rejected. Never enters context. Routed to garbage.
`EDIT`	Output requires targeted revision. Governed by the Edit Protocol.

How pruning works¶

Pruning is performed by editing the prior ROLE_USER turn and retrying.

This removes the unaccepted ROLE_ASSISTANT output from the active message history before the next execution begins. Pruning is not an instruction to the model to ignore something — it is an architectural removal. The output never enters the context used for the next turn.

Pruning resets interaction-level entropy and is mandatory for clean retries.

How the Edit Protocol works¶

Two edit types are defined for targeted revision of prior outputs without discarding the entire response.

REVISE — use when changing part of a prior output:

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

ROLE_USER_CONTENT:
[revision instruction targeting the marked region]

Only content inside ⟨REVISE⟩ tags re-enters probabilistic generation. Everything outside is implicitly accepted verbatim and must not be modified.

QUERY — use when asking a question about a prior output without changing it. The absence of ⟨REVISE⟩ tags signals a question, not a revision. ROLE_ASSISTANT answers only and does not regenerate any prior output.

ROLE_ASSISTANT_OUTPUT:
[prior output reproduced verbatim]

ROLE_USER_CONTENT:
[Question about prior output]

Common mistakes to avoid¶

Expecting execution after pasting the vial — it does not begin until E_T is submitted
Submitting an E_T with unfilled fields — ROLE_ASSISTANT will surface ambiguity and will not infer values
Retrying without pruning — unaccepted outputs remain in context and corrupt subsequent execution
Letting a Lab grow too large — start a new Lab when scope changes
Using INTERACTIVE when a structured output mode is required

When to end a Lab¶

End the Lab when:

results are accepted and work is complete
retries are exhausted and scope needs to change
the task definition changes materially

Start a new Lab for new work.

Final reminder¶

This framework enforces correctness only when you use it correctly.

Discipline produces quasi-deterministic outcomes.