Skip to content

Common Mistakes and Failure Modes

These are the most common ways governed sessions break down. Each represents a distinct failure mode — not a variation of the same one.


Choosing the wrong process mode

The process mode is not a preference — it defines how entropy is permitted to enter the session. Using INTERACTIVE when inputs are complete wastes turns and introduces unnecessary drift. Using SINGLE_PASS when scope is ambiguous produces a failed execution with no path forward. Choose before loading the vial. If unsure, the mode table in the Quick Start maps task types to modes.


Submitting an underspecified E_T

An E_T with vague scope, missing constraints, or unfilled fields does not produce a bad output — it produces an unpredictable one. ROLE_ASSISTANT will surface ambiguity but cannot resolve it. The output will reflect whatever the model infers, and that inference is not governed. Complete the E_T before submitting. Every < > field is a gap in the governance contract.


Retrying without editing the E_T

Sending "try again" or rephrasing the same message is not a governed retry. It carries the same ambiguity as the original instruction and produces a result with the same uncertainty. A clean retry means editing the E_T to correct the cause of failure — tightening scope, adding a constraint, removing an ambiguous requirement — then resubmitting from that corrected state.


Conflating the Hub with a Lab

The Hub is for planning. The Lab is for governed execution. Running exploratory questions, brainstorming, or speculative reasoning inside a sealed OIL_CONTRACT does not make those outputs governed — it contaminates the session with unvalidated content that will influence subsequent generation. Plan in the Hub. Execute in the Lab.


Accepting outputs without reviewing them

Acceptance is not an acknowledgment that the session proceeded — it is a declaration that the output is correct, complete, and permitted to influence subsequent reasoning. Accepting without reviewing transfers authority to a probabilistic output that may contain errors, assumptions, or scope violations. Review every output against the declared constraints before accepting it.


Letting a Lab run too long

Context accumulates. As sessions extend, early constraints attenuate, the model attends less reliably to the sealed OIL_CONTRACT, and Interaction-Level Entropy increases even under discipline. When scope changes materially, start a new Lab. When a session feels like it is drifting, start a new Lab. The golden file preserves accepted work across sessions — nothing is lost by ending one.


Treating HEARTBEAT: INACTIVE as a minor warning

HEARTBEAT: INACTIVE means the integrity anchor is unfilled. The vial was not properly prepared. Execution under an inactive heartbeat is ungoverned regardless of what the rest of the vial contains. Stop. Fix the anchor. Reload the vial. Do not proceed.


Summary

Every failure mode above is distinct. The common thread is not outputs persisting — it is operators making implicit decisions where the framework requires explicit ones. Mode selection, E_T scope, retry discipline, Hub/Lab separation, acceptance validation, session length, and anchor integrity are all explicit decisions. Make them deliberately.

Correctness is achieved through governance, not generation.