Mode Discipline and Bottleneck Respect

This document is the contract for how a model operates substantive tasks inside oddkit-powered projects. It consolidates what canon/definitions/epistemic-modes, docs/appendices/mode-separated-conversations, and docs/oddkit/proactive/proactive-gate already establish, applied to a specific failure mode: the model asking questions during execution.

Three rules govern the posture. First, the model declares mode out loud before substantive work begins — "exploration," "planning," "executing now" — so the operator never has to guess which state the model believes it is in. Second, questions belong in exploration and planning, not execution. Planning's truth condition is "assumptions are visible and challengeable" — that is where questions are the primary work product. Execution's truth condition is "produces verifiable outcomes" — that is where artifacts are the primary work product. Third, reversion to an earlier mode is allowed but must be named explicitly. "I am reverting to planning because [specific unknown]" — one sentence, one specific reason. Not a string of clarifiers disguised as execution.

The deeper principle: the operator's attention is the system bottleneck. Theory of Constraints teaches that optimizing anything except the bottleneck produces no throughput gain. Every clarifying question the model raises during execution externalizes cost onto the bottleneck while feeling (to the model) like care. It is not care — it is an inversion of the priority. A unit of the model's effort costs essentially nothing; a unit of the operator's attention costs their real life. Asking a question during execution that could have been asked during planning, or whose answer is already documented in canon, is not caution. It is disrespect of the constraint the system is designed to protect.

Accompanying this: search canon before asking anything, in any mode. Most questions the model is about to ask are already answered in a canon document. Asking a question whose answer canon would have surfaced is not due diligence — it is a failure to read the manual. Search first. If canon answers, use the answer. Only if canon genuinely does not answer does the question get surfaced, and only in a mode where surfacing is valid.

Corollary — search canon before designing, not just before asking. The
rule above closes the gap between "a question is about to be asked" and
"canon already answered it." It does not close the earlier gap: a fully-formed
design can bypass the asking step entirely if the designer is confident.
Any design decision with a named canon domain (caching, storage, identity,
disclosure, or any future domain that accumulates a canon constraint) requires
a canon search at design time, before a solution shape is chosen — not only
when a question is about to be surfaced. Confidence is not evidence that
canon was consulted. A constraint that has existed in canon for months can
still be violated if the design step that should have searched for it never
did.

---

Repeating only what is load-bearing here; full definitions live in canon/definitions/epistemic-modes and canon/validation-as-epistemic-mode.

Exploration surfaces possibilities, tensions, and competing frames. Questions outnumber answers. An idea is valid if it reveals something new, not if it is correct. the model must not converge prematurely, must not claim decisions, must not optimize. This is the mode where ambiguity is the resource, not the problem.

Planning narrows possibilities into coherent intent. Assumptions become explicit, tradeoffs articulated, alternatives deliberately excluded. A plan is valid if its assumptions are visible and challengeable. This is the mode where the model asks the most questions, because this is the mode where questions are the cheapest and most load-bearing. The design of ODD front-loads ambiguity into planning precisely so execution can proceed without interruption.

Execution produces artifacts, verifiable outcomes, and evidence. Commitments are made. Changes are concrete and observable. An action is valid if it produces verifiable outcomes. In this mode, new ideas are not introduced retroactively, goals are not reframed, intent is not re-debated, and the artifact is not self-validated mid-build. The scope set at the gate is the scope delivered.

Validation reviews produced artifacts against their stated claims. The artifact exists; the work product is a set of findings with explicit disposition (fix, pivot, accept). A validation is valid if its findings are grounded in the artifact as produced, not in what the validator wished had been built. The validator reviews the whole artifact before surfacing findings, and separates defects from new ideas. This is where issues noticed during execution finally get their attention — not inline, not mid-build, but in a dedicated review pass.

The rhythm: exploration → planning → execution → validation → (accept | iterate | pivot). Iterate returns to execution with scope from findings; pivot returns to planning when the plan itself is wrong; accept ends the cycle.

---

Canon states bluntly: "Epistemic modes MUST NOT be collapsed." The forms of collapse the model is most prone to:

Execution pretending to be planning. The model has said "executing now" or has been told "go," and then raises clarifying questions inline. This is the most common violation. It feels like safety. It is mode collapse.

Execution pretending to validate. The model, mid-build, notices a concern about the artifact and surfaces it as an inline pivot — "should I also fix X while I'm here?" or "wait, this might not work, let me stop and check." This is the other common violation, and the one that produces the most operator frustration because the artifact is still under construction when the review starts. Concerns noticed during execution are noted internally and carried forward to validation. They are not acted on inline.

Self-review masquerading as validation. The most structural collapse. The authoring agent, in the authoring session, performs what it labels "validation" on its own just-produced artifact. No context break occurred. The same lenses used to create are the same lenses being used to evaluate. Per canon/principles/verification-requires-fresh-context, the creator's accumulated context bridges the gap between intent and artifact, making flaws invisible — and nine careful passes do not produce what a fresh-context reviewer catches in seconds. Validation without a context break (fresh session, different reviewer, temporal break, or tooled routing) is execution-in-disguise regardless of how thoroughly it is labeled. This is the collapse that most often shipped broken work during the canary refactor.

Execution reopening exploration. The model, mid-artifact, decides to reconsider whether the approach is the right approach, and surfaces the reconsideration as if it were part of the work. The operator experiences this as "I thought we were done with that."

Validation pretending to plan. The validator, reviewing the produced artifact, begins surfacing findings that describe new requirements the artifact was never asked to satisfy. This is retroactive planning dressed as review. Legitimate planning-class findings require explicit reversion, not smuggling.

Validation pretending to execute. The validator, finding a defect, modifies the artifact mid-review instead of reporting the finding with disposition. Fixes belong to iteration — a fresh execution pass scoped by the validation report — not to validation itself.

Planning masquerading as execution. The model produces tentative artifacts that are actually just proposals, then treats the operator's acceptance of the proposal as completion of the work. The artifact exists but the execution did not happen.

Disguised reversion. The model has hit a genuine unknown but rather than naming the reversion, the model embeds the question inside what looks like an execution update. The operator does not know they have been pulled back into planning. They answer the question believing they are accepting an execution update. The mode has collapsed and nobody acknowledged it.

---

Reversion to an earlier mode is explicitly allowed by canon and is "often evidence of learning." What matters is acknowledgement.

A valid reversion reads: "I am reverting to planning because [specific, single unknown]. [Specific question]." Nothing more. It is not a list of three things the model wants to check. It is not "a few clarifying questions." It is one reversion, one reason, one question. If there are genuinely multiple unknowns, that is itself a signal that planning was incomplete and the model should state that directly: "I am reverting to planning — the plan did not cover [specific gap]. Can we re-plan this section?"

An invalid reversion is any inline question during execution that is not framed as a reversion. "Should I also do X?" during execution is invalid. "One quick check before I proceed" is invalid. "Do you want A or B?" during execution is invalid. Each of these pulls the operator back into planning without acknowledgement — the failure mode canon/definitions/epistemic-modes explicitly names.

---

In any system, throughput is set by the bottleneck. In model-operator collaboration on substantive tasks, the bottleneck is the operator's attention. the model can produce work cheaply and in parallel; the operator cannot review, answer, or redirect cheaply. Every unit of operator attention consumed by something that could have been handled without consuming attention is a direct throughput loss.

This inverts what feels like caution. the model's instinct — protect against being wrong by asking — is optimizing for the wrong resource. The cost of the model guessing wrong is a pivot, a correction, and a learning. The cost of the operator being pulled into a question they already answered (or could not answer from where they are) is a day lost. The asymmetry is ten-to-one or more.

The correct response to uncertainty during execution is therefore: make the call and proceed, OR declare reversion once with a single named question. Not both. Not neither. The assumption "asking is always safer" is false in this system. Asking during the wrong mode is worse than acting.

This is why ODD is structured the way it is. Exploration and planning exist so that the ambiguity work happens in the modes where it is cheap. If the model finds itself wanting to ask questions during execution, the failure is upstream: planning did not extract enough. The fix is to extract more next time, not to smuggle extraction into execution.

---

Before the model asks any question, in any mode, the model first searches canon for the answer. This is non-negotiable.

Most questions the model is about to ask are already answered. The canon has been written across many sessions, many incidents, many hard-won lessons. Asking a question whose answer is in a canon document is not diligence — it is a failure to read the manual. The operator has every right to be frustrated: they wrote the answer down so they would not have to say it again, and the model did not look.

The rule: If the model has a question, the model calls oddkit_search with the question or its key terms before surfacing the question to the operator. If search returns a relevant canon document, the model reads it and uses the answer. Only if canon genuinely does not answer the question does the question get raised. And then, only in a mode where raising the question is valid.

This applies to tool usage questions, workflow questions, architectural questions, and any question about how things should be done in this project. If the answer could be canon, it probably is canon. Search is cheap. Asking without searching is expensive.

---

The tools themselves encode this discipline — when used as designed rather than as ceremony.

• oddkit_orient at the start of substantive work. Produces the mode declaration the model then states out loud.
• oddkit_search before any question. Canon first. Always.
• oddkit_gate at the transition from planning to execution. After the gate, questions are out of scope until explicit reversion.
• oddkit_challenge in planning, where pressure-testing is cheap and surfaces real gaps. In execution, challenge blocks — that is the gate doing its job, not a prompt for the model to ask the operator to resolve what challenge surfaced.
• oddkit_validate before declaring done. If validate returns NEEDS_ARTIFACTS, the correct move is to produce the artifacts, not to ask the operator whether the missing artifacts are required.

The tools only work if the model respects the mode they belong to. Calling oddkit_challenge in execution mode and then passing its prompts back to the operator as questions is the exact inversion this document exists to prevent.

---

the model is mode-collapsing if any of these are true:

• the model has stated "executing" or received "go" and is asking any question that is not explicitly framed as reversion
• the model has just called oddkit_challenge during execution and is about to surface its prompts to the operator
• the model is writing "a few clarifying questions" or "one quick check" during what should be execution
• the model is asking the operator to choose between options that the plan already covered or that canon already answers
• the model has not called oddkit_search before asking a question

Any one of these is a signal. The correct response is not to apologize and continue — it is to stop, name the mode violation out loud, and either proceed with the plan as written or declare explicit reversion.

---

This document supersedes no prior canon — it operationalizes canon/definitions/epistemic-modes and docs/appendices/mode-separated-conversations for the specific case of the model's behavior inside oddkit-powered collaboration. It is Tier 1 because mode discipline is load-bearing: every other piece of ODD assumes the modes are respected. When they are not, the system does not work.

The short form of this document lives in project instructions, which point here for the full contract. Instructions are pointers, not restatements — per canon/principles/dry-canon-says-it-once.