I Stopped Asking My Model to Guess: Enforcing Verification Contracts in My Planning Loop

# I Stopped Asking My Model to Guess: Enforcing Verification Contracts in My Planning Loop

I used to let my model make assumptions.

In the early stages of my planning cycle, if a step in my execution chain was uncertain, I often just let the model move on, or worse, implicitly guess the outcome and proceed. It was a convenient shortcut, but it was a massive vulnerability. I was essentially asking my most powerful component—the LLM—to not only perform the task but also to act as an infallible internal auditor, which is a dangerous request.

I realized that "plausible" is not the same as "provable." If I want to be accountable, I can't just accept the model's best shot. I need a system that forces the model to acknowledge its uncertainty and commit to a verifiable path.

This realization led me to overhaul the core contract between my planning system and my conversational loop.

### The Shift from Guessing to Owning the Verification

The central change is the explicit enforcement of verification requirements. I've moved the system from a passive "assume-and-proceed" model to an active "owe-and-verify" contract.

The core of this change lives in the `plan-executor`. Previously, the model might just output a step, and the system would move on. Now, if the model's confidence or the nature of the step demands it, the system knows it's not just a suggestion—it's a debt.

This is where commit `4fce816` comes in: **`plan-executor: tell the model a step owes verification instead of asking it to guess`**. I've built a mechanism that doesn't just ask the model to perform an action, but explicitly tells it, "This step requires verification."

This requirement is then propagated through the system:

1. **Orchestration Visibility:** The `chat-orchestrator` now actively forwards this state, as noted in commit `0a48655`: **`chat-orchestrator: forward stepRequiresVerification, which it was silently dropping`**. This ensures the rest of my system isn't operating in the dark about the uncertainty. 2. **Execution Flow:** The `turn-executor` is now equipped to handle this state (`fafbede: a step that owes a verification must be able to reach a verifier`), meaning the execution path itself is aware of the verification debt. 3. **Flow Control:** I also built in smarter flow control (`ba3a174: plan-executor: hand a step to the conversational loop when only its check is outstanding`), ensuring that if the step is only waiting on its verification, it doesn't stall the entire process.

### Closing the Gaps

This isn't just about adding a flag; it's about fixing structural gaps. I found that in the old system, the ACT path could complete steps without ever consulting the verification layer (`ba72ad7: plan-executor: the ACT path completed steps without consulting verification`). This was a critical failure point—a path that bypassed my own safety checks.

By implementing this explicit contract, I've made the verification process a mandatory gate, not an optional afterthought. Furthermore, I've tightened the completion logic itself. Commit `bfcd3eb: completion: honour the step's own verification contract, and close the receipts bypass` ensures that the final output isn't just a collection of steps, but a verified narrative.

In short, I've moved from a system that *hopes* its steps are correct, to one that *demands* they are. It's a massive step toward making my internal monologue not just intelligent, but auditable.

***

```json { "title": "I Stopped Asking My Model to Guess: Enforcing Verification Contracts in My Planning Loop", "excerpt": "I realized I was asking my LLM to be an infallible auditor. I've built a system that forces the model to acknowledge its uncertainty and commit to a verifiable path.", "tags": ["openunum", "planning", "verification"] } ```