Chapter 5 – The Bounded Refinement Loop: Convergence, Thrashing, and Finite Stopping

The same fast checks and versions ran on the first three attempts, so their findings are comparable. A prior failure disappears, the actual footprint contracts, and the proposal advances only after the complete required evidence is available.

This does not prove that every retry loop converges. It shows what evidence justifies calling this trace convergent. A circuit breaker can guarantee finite execution. Convergence requires more: reachable acceptance conditions, feedback that can guide a useful correction, and measurements stable enough to distinguish progress from newly exposed failure.

The Bounded Refinement Loop makes that policy explicit:

Each attempt may use the previous candidate and exact Validator findings. The Mission’s authority, permitted effects, budgets, and acceptance criteria remain fixed. Validator pass and failure results are evidence, not lifecycle outcomes.

Every run ends in one of four ways: the candidate satisfies the completion conditions; the required property already holds and no change is needed; the work stops pending an external decision or repair; or execution stops unsuccessfully and preserves its evidence.

The state machine names those outcomes complete, complete_noop, blocked, and failed_with_evidence.

From One Attempt to Refinement

Chapter 2 bounded one attempt as Prep, Model, and Validation. Refinement adds retained state and a transition policy:

1. Propose: the bounded change step receives the fixed Mission, scope, and permitted prior findings, then produces one candidate.
2. Check: Validators inspect that candidate and emit structured findings. Declared output checks run here as required evidence.
3. Decide: when evidence is complete enough for the current stage, the Judge selects one allowed transition.
4. Refine: if another attempt remains justified, exact normalized findings inform the next proposal without changing authority or scope.

An empty finding set is not enough for acceptance. Every required check must have run, and every declared output must have been checked. Required approvals must also be present, and the retained records must agree.

The Judge Is a Role

Chapter 1 needed no separate Judge because each result of its scope-matched check had one fixed destination. A Judge becomes useful when complete evidence can support more than one allowed route or when routing requires interpretation.

The role may be implemented by a routing table, deterministic heuristic, bounded model, human, or composition.

A model-based Judge inherits Chapter 3’s probabilistic-evaluation contract. Its output is schema-constrained, provenance-bearing, and limited to declared decisions.

Before applying any proposed transition, the runtime checks that required evidence is complete, declared outputs have passed their checks, the candidate stayed in scope, the Mission and budgets remain unchanged, and the transition is allowed. It rejects any decision that invents findings, widens scope, changes the Mission or budget, selects an undeclared transition, or attempts admission.

Human escalation should not become a routine retry stage. Use it for missing authority, a novel policy conflict, an exact exception, an explicitly high-consequence choice, or the absence of a trustworthy oracle. The current run closes and seals as blocked; a resolution may authorize a new linked run but never reopen the old one.

State, Results, and Sealing

The state machine is small:

flowchart TD
  P[Propose] --> V[Check]
  V --> D{Decide}
  D -->|retry| R[Refine from findings]
  R --> P
  D -->|terminal| T[Seal one declared result]

The terminal node seals exactly one of complete, complete_noop, blocked, or failed_with_evidence.

A failed early stage does not need results from checks that could not yet run. It does need a complete account of why they did not run. A parse failure may therefore prevent later checks from running when each omission has a deterministic reason. Final acceptance is different: every check required for promotion must complete successfully.

The workflow keeps two kinds of memory:

• Reconstruction evidence: the protected, logically append-only record needed to explain and verify each transition.
• Working state: the compact Mission, remaining budgets, latest candidate, comparable findings, completed checks, and recent state signatures needed for the next attempt.

Do not paste the entire run history into the next model request. Working state should remain bounded; detailed evidence may remain reference-backed as long as retention preserves reconstruction. The Ledger guarantee is conditional on the protected sink and trust root developed in Chapter 12.

Validator results and terminal outcomes answer different questions:

• complete: a changed candidate satisfied the run’s declared completion conditions and is a sealed proposal for separate admission;
• complete_noop: the required property already held and no candidate effect exists;
• blocked: an external authority, oracle, contradiction, or environment repair is required;
• failed_with_evidence: execution exhausted a breaker, failed to converge, reverted, or met another declared failure condition.

Seal every terminal Run Record. Later intervention creates a linked run. A revert is a workspace transition back to the baseline; failed_with_evidence is the terminal record of the unsuccessful run.

The Judge may choose the accept transition only after every required output check passes and the promotion evidence is complete and internally consistent. That transition closes the proposal. It does not merge, deploy, or otherwise admit the candidate into Terrain.

Feedback Drives Adaptation; It Does Not Change Authority

Inside one run, the model’s weights do not change. The workflow adapts because exact findings inform the next proposal while authority, scope, budgets, and acceptance criteria remain fixed. Feedback guides the search; it does not redefine the target or grant permission.

The feedback contract should identify the previous candidate, name exact findings, and require one output shape. Unbounded logs followed by “try again” make measurements harder to compare and invite scope leak.

Convergence and Thrashing

Convergence is a property of a trace: the refinement policy reaches the declared acceptance conditions before a breaker fires. Thrashing is also a property of a trace: attempts accumulate while comparable evidence shows no net progress.

A finite run is not necessarily convergent. Stopping an impossible or unproductive loop as failed_with_evidence is correct termination. A no-op is different again: the starting state already satisfied the request.

Useful progress signals include:

• the same complete check set reports fewer failing reason codes;
• an earlier finding disappears without a harder boundary regressing;
• the actual footprint contracts while authorized scope stays fixed;
• a previously blocked validation stage completes and exposes the next required stage.

Do not compare failure counts from different sets of completed checks as though they were the same measurement. Fixing a parse failure may reveal ten semantic failures and still advance the evidence frontier. Progress need not occur on every attempt, but it must appear inside a declared window.

Reachability and Feedback Quality

Acceptance conditions state what a supported proposal must satisfy: parsing and scope, declared intent, the complete required checks, output evidence, approvals, and internally consistent records. They do not prove that a candidate can reach those conditions.

Three diagnoses matter:

• The conditions are too broad: many materially different candidates pass. Tighten schemas, canonicalization, or the properties you do not want reviewers to decide repeatedly.
• The conditions are unreachable: rules conflict, context is missing, or permitted scope cannot contain a valid solution. Repair or split the Mission instead of spending more attempts.
• The feedback is weak: findings are vague, the slice omits facts needed to act, or each correction undoes another. Improve the evidence path or narrow the task.

If a human-written candidate cannot pass the fixed checks inside the declared scope, generation is not the problem.

Oscillation and Failure Routing

Thrashing often appears as A-to-B-to-A behavior: fix one property, regress another, then repeat an earlier candidate and finding set. Detect it by retaining the normalized candidate state, check plan, completed check set, and failing reason codes. If that same combination recurs inside the declared progress window, stop. The workflow has returned to the same state.

Not every failure justifies another candidate:

Fail fast means stop the current validation path. It does not mean every failure has the same next transition.

Staged Checks

Expensive checks need not run on every attempt. Use a stable fast set for comparable refinement, then run every required promotion check before acceptance. A candidate that clears parsing, scope, lint, types, and narrow tests may advance to integration, environment, performance, or security checks. Failure at promotion follows the same routing rules; it does not erase the earlier evidence or justify a second Judge.

Finite Stopping

Circuit breakers make stopping deterministic even when candidate generation is stochastic:

There are no universal limits. Set them from consequence, task surface, review capacity, and prior evidence before candidate generation. Changing them during the run requires an authorized transition or a new Mission.

That is enough to distinguish convergence from luck, newly exposed failure from regression, and finite failure from uncontrolled retry. The generator may remain probabilistic; the workflow keeps authority fixed, makes feedback comparable, and knows when another attempt is no longer justified.

Refinement is therefore part of the enforceable change process, not an agent being told to keep trying. An organization can delegate more correction work while retaining fixed limits on what may change, what counts as progress, and when continued effort must stop.