Consullo cornucopia mark Consullo Public research record

The Validated Improvement Loop And Its Invariants

Specialized Abstract

Consullo Seed AI requires an improvement loop that can modify the system without confusing change for progress. This thesis defines recursive capability amplification as a staged, evidence-gated process over agents, method memories, code, tests, workflows, policies, and population structure. The claim is not that Consullo currently performs unbounded recursive self-improvement. The claim is that Consullo's current and proposed designs specify a scaffold for empirical self-improvement: candidate changes can be proposed, evaluated, validated, staged, monitored, rolled back, and recorded into method memory. Capability Status: specified/proposed.

The validated improvement loop is an empirical relaxation of the Goedel-machine ideal. A proof-based self-improver would accept only modifications proven to improve expected utility under its formal system. Consullo instead uses evidence packages, benchmarks, staged deployment, hard invariants, AAF review for high-stakes externally consequential changes, provenance, cost/benefit accounting, and post-deployment monitoring. This makes the loop weaker than formal proof but more applicable to real software agents. Its falsification risks are direct: if validators are gamed, costs dominate gains, accepted changes fail outside benchmarks, or rollback becomes unreliable, the scaffold fails.

Specialized Introduction

Recursive self-improvement is often described as though the hard part were the existence of an agent that can edit itself. In Consullo, that is not the hard part. The hard part is deciding which edits count as improvements, what evidence justifies accepting them, what constraints cannot be traded away, and how the system learns from both accepted and rejected changes.

The current Consullo design corpus already contains many ingredients for this loop: the SelfImprovementOrchestrator, SeedAIManager, AgentImprovementGoalSetter, AgentCapabilityImprover, AgentComplianceValidator, RecursiveEnhancementTracker, method-memory extraction and organization machinery, DGM-style candidate generation and selection, behavioral extraction prompts, and method-memory catalogs. The thesis here is that these should be understood as one governed improvement loop rather than as a loose collection of enhancement agents.

Master-Frame Contract

This thesis imports:

This thesis exports:

Main Argument

An improvement loop is valid only if "improvement" remains an ordered, evidence-backed comparison rather than an assertion of intent. A proposed change must name its baseline, target axis, measurement protocol, expected or observed delta, side-effect channels, cost, uncertainty, and rollback path. Without this structure, the system will tend to reward local metric movement, benchmark overfitting, or agent self-justification.

The Consullo loop should therefore be organized into six stages.

First, a proposer generates a candidate change. The candidate may be a code patch, method-memory mutation, new test, prompt decomposition, routing policy, agent specialization, benchmark, or governance adjustment. Primary Consullo roles include AgentImprovementGoalSetter, AgentCapabilityImprover, ConstructiveRuleChallenger, AutonomousTaskProposer, ExplorationPortfolioManager, and DGM evolutionary roles. Capability-threshold language in this thesis uses Consullo Capability Status, not external frontier-risk levels; any mapping to Responsible Scaling Policy-style thresholds is deferred by the vocabulary file.

Second, an evaluator estimates expected value. The evaluator does not accept the change. It constructs an evidence package containing the improvement axis, baseline, cost, uncertainty, expected side effects, candidate benchmarks, and known failure modes. QualityCostBalancer and RecursiveEnhancementTracker belong here, along with causal-decision support from Thesis 3.

Third, a validator gates acceptance. The validator checks invariants, provenance, specification conformance, tests, benchmark results, security posture, alignment review, cost/benefit evidence, and deployment readiness. AgentComplianceValidator, the DGM validator role, and relevant verification agents participate here, but validation does not collapse into one binary check. It is staged.

Fourth, the system deploys through controlled stages: static review, sandbox, benchmark, canary, production, and post-deployment monitoring. High-stakes irreversible or externally consequential actions require AdversarialAlignmentOrchestrator non-veto before acceptance, with severe unresolved objections routed to revision, rejection, or human authority.

Fifth, outcomes are recorded into the evidence ledger. The record must preserve the proposal, evaluator reasoning, validator results, deployment stage, cost, observed effects, dissent, rollback state, and follow-up obligations. Rollback must annotate or supersede evidence, not erase it.

Sixth, the system updates method memory and credit assignment. Successful changes may become reusable methods; failed changes become anti-patterns or benchmark improvements. Population promotion may also demote, retire, specialize, re-route, or constrain other agents and methods when the evidence shows that the population structure should change. Method memories must preserve lineage, version, owner, preconditions, postconditions, dependencies, cost profile, validation history, and deprecation criteria.

Expansion: What Counts As Improvement

The central discipline of Thesis 1 is that improvement is not a property of a patch, an agent, or a method memory in isolation. It is a relation between a baseline state and a candidate state under a task class, metric, scope, cost model, side-effect model, and evidence envelope. A change can improve one axis while degrading another. A faster repair agent may reduce latency while increasing false positives. A more aggressive benchmark generator may find more defects while also overfitting validation to a narrow style of task. A new method memory may improve one workflow but make population-level routing harder because it increases coordination burden. For this reason, Thesis 1 treats every improvement claim as scoped and comparative.

The minimum improvement statement should have the following form: relative to baseline b, candidate c improves axis x on task class T by margin d, under measurement protocol M, with confidence or uncertainty statement u, at validation cost k, while preserving protected dimensions P and maintaining rollback or mitigation path R. If any of those fields are absent, the claim should be downgraded from improvement to hypothesis, proposal, or observation. This is deliberately stricter than ordinary engineering language, where "improvement" often means that a developer or model believes the new version is better.

The baseline must be concrete. For code, the baseline might be a commit, test result, benchmark score, or current agent implementation. For a method memory, it might be the parent method memory plus its validation history. For a prompt decomposition, it might be the previous prompt chain, token cost, latency, error rate, and downstream repair rate. For a governance policy, it might be incident frequency, false accept rate, false reject rate, escalation burden, and override frequency. A baseline that cannot be replayed or reconstructed weakens the improvement claim because it prevents later audit.

The task class must also be explicit. "Improves coding" is not a valid Thesis 1 claim. "Improves compilation-repair success on Java agent files with missing imports under the local Maven test suite" is closer. The narrower statement may feel less ambitious, but it is more useful. It lets later work ask whether the improvement transfers to broader repair tasks, whether the transfer is measured, and whether the transfer creates regressions elsewhere. This is how the suite avoids converting local success into global capability rhetoric.

The side-effect channels are part of the claim, not a footnote. A candidate that improves benchmark performance while increasing cost, latency, security exposure, privacy risk, or rollback difficulty is not automatically accepted. It may still be accepted under a documented trade exception, but the exception must name the trade, authority, scope, and follow-up obligation. This is where Thesis 1 imports Thesis 5 rather than merely referencing it: alignment, safety, security, provenance, and rollback readiness are protected dimensions, not ordinary optimization terms.

The confidence statement does not have to be a fully Bayesian posterior in early implementations. It can be a test result, evaluator judgment, confidence interval, replication count, adversarial-test outcome, or uncertainty category. What matters is that uncertainty is represented and preserved. Unknown uncertainty should not be silently converted into confidence. In the early Consullo state, many improvement claims will therefore remain specified/proposed rather than implemented or validated.

Expansion: Empirical Relaxation Of The Goedel-Machine Ideal

The Goedel-machine ideal is attractive because it gives recursive self-improvement a clean formal story: a system rewrites itself only when it can prove that the rewrite improves expected utility according to its formal axioms and proof system. That ideal is not the current Consullo claim. Consullo is a software-agent ecosystem, not a closed theorem prover with complete access to the consequences of its own modifications. Its evidence comes from tests, benchmarks, static checks, simulations, traces, human review, AAF dissent, deployment observations, and implementation artifacts. These are incomplete and fallible.

The Darwinian Godel Machine design already moves from proof to empirical selection. It treats method memories as evolvable artifacts, generates variants, validates them against benchmarks, selects useful candidates, and archives lineage. Thesis 1 generalizes that pattern across Consullo without claiming that the generalized pattern is already validated. The important move is not "evolution finds improvement." The important move is "candidate generation is separated from acceptance, and acceptance requires evidence under constraints." Evolutionary pressure without validation would amplify whatever the scoring function rewards, including artifacts and loopholes.

Consullo's relaxation can be stated as statistical acceptance under hard constraints. A modification is eligible only if hard invariants hold. It then needs enough evidence that the promoted population will improve a scoped metric by at least a minimum margin, with false-accept tolerance below a stated threshold, and without material degradation of protected dimensions. This is still weaker than proof. It can be wrong. But it is reviewable: a skeptical reader can inspect the metric, benchmark, margin, confidence, protected set, cost model, deployment stage, and rollback path.

This relaxation also clarifies why the validator is not just another proposer. A proposer is rewarded for finding candidate changes. An evaluator is rewarded for estimating whether a change is promising and what evidence would matter. A validator is responsible for gatekeeping acceptance under invariants and evidence sufficiency. If one role controls all three functions, the loop becomes vulnerable to self-justifying proposals: the same subsystem that wants a change also defines the evidence and accepts the result. Thesis 1 therefore treats role separation as a structural invariant of the loop.

The relaxation has a second consequence: the loop must preserve negative evidence. A proof-based system either finds a proof or does not. An empirical system learns from failed candidates, partial successes, rejected proposals, benchmark failures, AAF objections, post-deployment regressions, and cost overruns. Those failures should produce anti-patterns, validator improvements, benchmark additions, and method-memory deprecations. If failures disappear because only successful variants are archived, the population will repeatedly rediscover unsafe or unhelpful modifications.

There is an information-theoretic reason this external evidence is mandatory rather than merely good practice. Recursive self-training modelled as a dynamical system on distributions is provably degenerative in the pure-autonomy regime: when the proportion of exogenous, externally grounded signal vanishes, the loop loses diversity and drifts from the truth, and its mutual information with the real world can only decrease (On the Limits of Self-Improving in Large Language Models: The Singularity Is Not Near, arXiv:2601.05280, Zenil). Collapse is proven precisely for the case where the system improves by learning from its own output; it does not apply when external grounding remains persistently present. Consullo's loop is therefore designed to keep that grounding non-vanishing: benchmarks, the frozen reference suite, external-evaluator sampling by a different model family or human, and fresh-agent transfer tests are all exogenous signal whose correctness is fixed independently of the system's current distribution. The empirical relaxation of the Goedel-machine ideal is not only weaker than proof; it is also, by this account, the condition that keeps the loop out of the self-training collapse regime — provided the system never begins accepting changes on self-generated evidence alone. Zenil's second escape route, symbolic and mechanistic model synthesis over distribution-matching, further reinforces the suite's preference for verifiable symbolic artifacts — method memories, typed contracts, causal models — over recycled model output; see ../../self-improvement/recursive-self-improvement-limits.md for the full treatment.

Expansion: Acceptance-Gate Evidence Package

A Thesis 1 acceptance gate should not receive an unstructured narrative. It should receive an evidence package. The package is the unit that lets the evaluator and validator communicate without collapsing their responsibilities. At minimum, it should contain the candidate change, baseline, target axis, task class, evidence sources, benchmark results, protected-set checks, cost/benefit report, side-effect channels, provenance, trust scope, AAF status where relevant, deployment plan, rollback or mitigation plan, and open objections.

For code changes, the package should link the patch, specification, generated or edited files, compilation output, tests, static checks, dependency analysis, semantic checks where available, security review, and deployment stage. For method-memory changes, it should link the parent memory, mutation rationale, preconditions, postconditions, dependency changes, validation history, expected reuse scope, and deprecation rule. For policy or governance changes, it should link the authority source, affected scopes, incident history, AAF review, human authority state, and monitoring obligations.

The evidence package also needs a decision state. A candidate is not simply accepted or rejected. It may be needs-input because required evidence is missing. It may be conflicted because metrics disagree or AAF dissent remains unresolved. It may be blocked because a hard invariant fails. It may be revised because the idea is promising but the implementation or scope is unsafe. It may be escalated because human authority is required. It may be transfer-unverified because the benefit was observed on the originating agent but has not yet been shown to transfer to a fresh agent that did not generate the candidate. These states matter because they prevent the system from turning uncertainty into either silent acceptance or permanent rejection.

The acceptance gate should also distinguish evidence classes. Compilation success is different from semantic correctness. Test passage is different from regression robustness. A benchmark score is different from deployment behavior. A causal explanation is different from observed improvement. AAF non-veto is different from a proof of alignment. Cost acceptability is different from capability gain. Treating these as interchangeable creates false confidence. Treating them as separate evidence classes makes the loop slower but more auditable.

This package should be recorded through the evidence-ledger schema. The ledger record is not bureaucratic overhead; it is what makes recursive improvement possible without narrative drift. Future validators can inspect what evidence justified a prior acceptance. Future evaluators can estimate which evidence types predicted success. Future method-memory selection can prefer memories with stable validation histories. Future risk review can identify whether false accepts share a source, benchmark, model family, prompt style, or validator weakness.

Expansion: Bounded Compute And Cost Discipline

Recursive improvement proposals often fail to engage the most practical objection: improvement can become too expensive to compound. If each accepted modification requires more search, more critique, more validation, more human review, and more deployment monitoring than the benefit it creates, the loop is not a seed of recursive capability amplification. It is an expensive quality-control process. Thesis 1 therefore treats cost as first-class evidence rather than as an implementation detail.

Cost includes token cost, model latency, tool cost, human review burden, benchmark runtime, opportunity cost, coordination overhead, incident-response cost, and future maintenance burden. A candidate that saves ten minutes per use but requires weeks of validation may still be worthwhile if it is reused often enough or protects a critical invariant. But the reasoning must be explicit. QualityCostBalancer is not merely an efficiency agent; it is part of the semantics of improvement.

The cost model should report both proposal cost and acceptance cost. Proposal cost measures the resources spent generating candidates. Acceptance cost measures the resources spent evaluating, validating, reviewing, deploying, and monitoring them. Recursive improvement can fail in either direction. If proposal cost is high, exploration becomes narrow. If acceptance cost is high, the system may develop pressure to weaken validators or bypass AAF. If monitoring cost is high, the system may accept changes but fail to learn from outcomes. These pressures belong in the ledger.

Cost discipline should not be misread as a command to minimize validation. Some changes are expensive to validate because they are high-stakes, externally consequential, security-sensitive, or alignment-relevant. The correct requirement is proportionality. Routine low-risk changes should not receive maximum alignment review. High-stakes changes should not receive lightweight review because they are expensive to scrutinize. The gate should record why the validation depth matches the scope.

There is also a portfolio problem. A system that accepts only low-risk, low-cost, incremental changes may improve locally while never addressing structural bottlenecks. A system that pursues too many ambitious mutations may spend its budget on speculative changes without compounding reliability. ExplorationPortfolioManager exists to manage that trade. Its output should not be "more exploration" or "more exploitation" in the abstract; it should be a portfolio allocation across task classes, risk lanes, expected value, evidence maturity, and strategic bottlenecks.

Expansion: Ledger, Credit Assignment, And Population Memory

The improvement loop must learn at population level. Individual accepted changes matter, but recursive capability amplification depends on whether the system improves its future ability to propose, evaluate, validate, and deploy changes. That requires credit assignment across agents, method memories, benchmarks, validators, prompts, and routing policies.

Credit assignment should not simply reward the agent that proposed an accepted change. The accepted result may depend on a memory retriever that surfaced the right prior method, an evaluator that found a missing side-effect channel, a validator that narrowed scope, a benchmark generator that exposed a failure, or an AAF report that forced a safer design. Conversely, a proposer may generate many plausible candidates that validators reject because they exploit a known benchmark weakness. Without credit assignment, the system cannot tell which parts of the improvement machinery are themselves improving.

The evidence ledger gives credit assignment raw material. Each record links proposal, evaluator assessment, validator decision, deployment outcome, cost, dissent, rollback, and method-memory update. Over time, the system can ask which evaluators predict post-deployment outcomes, which validators catch real failures, which benchmarks correlate with external performance, which method memories transfer across task classes, and which agents create coordination overhead. These are empirical questions; the suite should not assume the answers.

Population memory must include anti-patterns. A failed candidate can be valuable if it reveals a validator weakness, a benchmark gap, an unsafe prompt pattern, a brittle method memory, or a misleading capability claim. Rejection should therefore create a record with reason codes and reuse conditions. Some rejected candidates should become "do not retry without new evidence" anti-patterns. Others should become "promising but insufficient evidence" backlog items. Others should become new benchmark cases.

Promotion is therefore a population operation. Accepting a new method memory may imply deprecating a parent memory, narrowing a sibling memory's scope, raising validation requirements for a class of patches, changing routing policy, or adding a benchmark. This is why the formal model uses Promote(pi_t, delta) rather than pi_t + delta. Recursive improvement is not accumulation. It is selective restructuring under evidence.

The practical test for this section is whether Consullo can eventually produce an end-to-end improvement-loop demonstration: baseline, proposed change, evaluator package, validator decision, staged deployment or simulation, cost/benefit report, ledger records, rollback semantics, method-memory update, and post-change observation. Until that demonstration exists, the loop remains specified/proposed. The long-form expansion should keep that status visible rather than letting the architecture's coherence imply implementation.

Expansion: Update Capability Versus Utilization Benefit

Thesis 1 measures improvement as a delta between a baseline state and a candidate state on a task class. A failure mode that this framing can hide is that the delta is usually measured on the same agent, model instance, or interaction context that produced the candidate. Self-evolving-agent research warns that the capacity to update a harness component — a tool, prompt, skill, method memory, or workflow — is a different capability from the capacity to benefit from that update (Harness Updating Is Not Harness Benefit: Disentangling Evolution Capabilities in Self-Evolving LLM Agents, arXiv:2605.30621, "Harness Updating Is Not Harness Benefit"). A candidate can change the harness successfully, pass the validator, and still produce no transferable gain, because the apparent improvement was adaptation to one agent's own interpretation style rather than a property of the modified component.

This distinction matters for Consullo specifically because so much of the loop's proposed substrate — method memories, atomic-prompt decompositions, routing rules, and agent specializations — is intended for reuse by agents other than the one that generated it. An improvement that does not transfer is not recursive capability amplification; it is local procedure accumulation, which Open Question 6 already flags as a risk. The remedy is to make transfer an explicit, gated part of the acceptance condition rather than an assumption.

The loop should therefore add a fresh-agent transfer check to the evidence package. Concretely, an improvement claim should compare three conditions rather than two: the baseline agent with the original harness, the originating agent with the updated harness, and a fresh agent — one that did not participate in generating the candidate — with the updated harness. If the benefit observed on the originating agent does not survive on the fresh agent within measurement sensitivity, the candidate's status is transfer-unverified: the harness was updated, but the benefit is not yet established as a property of the harness. Where feasible, the fresh agent should be drawn from a different model family per week-0-control-artifacts/model_family_diversity_policy.md, so that one test simultaneously disentangles update from benefit and exposes the interpretation-style and validator-monoculture overfitting described in Open Question 5.

This also refines credit assignment. The loop should score update capability and utilization benefit as separate axes. An agent that reliably produces accepted harness changes that do not transfer is good at updating and not yet good at producing benefit, and the ledger should not award it the same credit as an agent whose changes replicate across the population. Treating the two as one metric rewards harness churn and creates exactly the Goodhart pressure the loop is meant to resist: a proposer can win by changing components in ways a validator accepts without moving real, transferable capability. Transfer rate by component is itself evidence, because components generalize unequally; a validated transfer on a method memory does not license a transfer claim for a prompt decomposition.

Transfer verification does not replace the protected-set, cost, and AAF disciplines; it is an additional gate, and like the others it can be expensive. For low-stakes routine repairs with no reuse intent, a single fresh-agent replication may suffice or be waived with a recorded rationale. For any candidate whose value depends on population-wide reuse — method memories headed for the behavior marketplace especially — transfer verification should be mandatory before the change is described as an improvement rather than an update.

Expansion: End-to-End Harness Optimization

The candidate types named in the Main Argument — prompt decomposition, method-memory mutation, routing policy, new test, tool or agent change — are not independent. They are components of one harness: the prompts, tools, memory, and workflow that wrap a model for a task. External work on optimizing harnesses end to end shows that these components interact, so tuning one in isolation can miss gains that appear only when several are adjusted together; the harness is itself an optimization frontier comparable to model selection, and a jointly-optimized harness can outperform any single-component tweak (Meta-Harness: End-to-End Optimization of Model Harnesses, arXiv:2603.28052, "Meta-Harness: End-to-End Optimization of Model Harnesses"). The proposer and evaluator should therefore be able to produce and assess joint candidates that change a prompt, a method memory, and a routing rule together, not only one-component-at-a-time patches.

This capability is real, but it widens the loop's Goodhart surface rather than narrowing it. End-to-end optimization drives the whole harness toward whatever signal it can see, so the more components a candidate co-adapts, the more degrees of freedom it has to fit the visible evaluation rather than the task. Three Thesis 1 disciplines become more important, not less, when candidates are joint. First, the optimization objective must be a held-out signal the optimizer cannot read during search: jointly-optimized harnesses overfit the eval distribution exactly when the optimizer is allowed to train against it, so the frozen reference suite and the fresh-agent transfer test must sit outside the optimization loop. Second, credit assignment cannot be cleanly decomposed for a joint candidate — the win belongs to the combination — so the ledger should record the joint candidate as the unit of acceptance and, where the loop wants per-component credit, run ablations rather than assuming additivity. Third, the protected set still binds the whole harness: an end-to-end optimizer that improves task accuracy by quietly weakening provenance, a security check, or a rollback path has not produced an improvement, however good its headline metric.

The practical stance is to treat joint harness optimization as a first-class proposer capability under the same acceptance gate as any other candidate. A jointly-optimized harness is an update; it becomes an improvement only when its benefit survives held-out and fresh-agent validation, preserves the protected set, reports cost, and carries rollback — the same conditions the loop applies to a one-line method-memory edit. The difference is that joint candidates make the held-out and transfer gates load-bearing, because they are the only checks that distinguish a harness that genuinely generalizes from one that has been compiled to the test.

Expansion: Self-Proposed Harness Evolution

The two preceding results bracket a spectrum by who edits the harness. The update-versus-benefit result studies a harness an agent changes for itself and warns the change may not transfer; the end-to-end result studies a separate, stronger optimizer that tunes a weaker agent's harness. The remaining case is a fixed agent that proposes edits to its own harness and promotes them only after they survive a held-out gate — self-proposed harness evolution (Self-Harness: Harnesses That Improve Themselves, arXiv:2606.09498, "Self-Harness: Harnesses That Improve Themselves"). Its reported loop is a three-stage instance of this thesis's own structure: mine failures under the current harness, propose K bounded edits to declared surfaces (system prompt, tool set, bootstrap/execution/verification/recovery instructions, runtime-control policy), and re-evaluate each candidate on a held-in and a held-out split, accepting only under a conservative non-regression rule (both deltas ≥ 0 and at least one strictly positive). Two of its mechanisms are directly reusable. First, failures are clustered into verifier-grounded signatures — a triple of terminal cause, causal status, and agent mechanism — so the evaluator's evidence package groups failures that admit the same intervention rather than accumulating anecdotes; this is a sharper schema for the proposal-evidence bundle than a flat failure taxonomy, and it collapses the duplicate-proposal pathology where several agents file separately against one underlying regression. Second, the reported gains are model-specific: an identical harness produces large per-model spreads on Terminal-Bench-2.0, and per-model scaffolding recovers them, which argues for maintaining a distinct harness variant per model tier — INEXPENSIVE, MEDIUM, and the agentic tier — and re-deriving rather than inheriting a harness when a serving model is swapped, instead of treating one scaffold as universal.

The adoption is bounded by two of this thesis's invariants, and the paper's own limitation section concedes the first. Its acceptance rule is pass-rate non-regression alone; this thesis requires more — the protected set, cost accounting, rollback, and, for reuse-bearing candidates, fresh-agent transfer — so a self-proposed harness edit is an update under the same terms as any other and becomes an improvement only on the fuller gate, never on a pass-rate delta. The second invariant is structural: letting the same model both propose harness edits and see the signal that accepts them collapses the held-out into the optimizer's reach — the exact optimizer-blind failure named above, and the α → 0 autonomy regime that ../../self-improvement/recursive-self-improvement-limits.md §6 shows is degenerative. Self-proposal is therefore admissible as a proposer capability only: the model may generate and pre-score candidate edits against evidence it can see, while promotion stays behind the frozen reference suite, the fresh-agent transfer test, and the Friendship/AAF gate, none of which the proposer authors or reads during search. Under those two constraints self-proposed harness evolution adds a third proposer mode alongside single-component patches and joint optimization without widening the acceptance surface.

Expansion: Protected Set, Trade Discipline, And Override Semantics

The improvement loop can only remain governable if some dimensions are treated as protected rather than as ordinary optimization targets. The formal appendix names alignment, security, privacy, rollback readiness, provenance, and core reliability as the protected set. In practice, that means an evaluator and validator are not allowed to treat those dimensions as just more entries in a utility vector. A candidate that improves speed or benchmark score while degrading one of those dimensions is not a routine tradeoff. It is either rejected, revised into a narrower scope, or elevated into an explicit human-authorized trade exception.

This protected-set discipline matters because recursive systems naturally create pressure to trade future safeguards for present throughput. A generator that skips provenance logging may look more efficient. A validator that ignores semantic uncertainty may accept more patches. A policy that relaxes review requirements may reduce latency. A narrower test suite may improve benchmark pass rate. A system that is optimizing for local success will discover these pressures quickly. The protected set exists so the loop does not gradually redefine success around whatever it can optimize most easily.

Each protected dimension should have a minimum observable indicator, even before full quantitative measurement exists. Alignment can be approximated through AAF routing, objection preservation, constraint checks, and incident review. Security can be approximated through static analysis, permission review, secret-handling checks, dependency hygiene, and explicit security tests. Privacy can be approximated through data-scope review, redaction checks, retention rules, and exposure review. Rollback readiness can be approximated through the presence of a concrete rollback or mitigation path, stage-specific recovery instructions, and rehearsal where practical. Provenance can be approximated through artifact linkage, evidence-ledger completeness, and traceability between proposal, validation, and outcome. Core reliability can be approximated through regression results, post-deployment monitoring, and repeated-run stability.

Trade discipline should therefore use a three-lane model. The first lane is strict non-regression: the protected dimension must not degrade at all within measurement sensitivity. The second lane is documented trade exception: a temporary or bounded degradation is allowed only when authority, scope, mitigation, monitoring cadence, and exit condition are explicit. The third lane is hard veto: certain degradations are not acceptable even under trade exception, such as removing the only rollback path for a high-stakes change, erasing provenance for accepted modifications, or bypassing required AAF review for I12-covered actions. This lane structure keeps the protected set from becoming either impossibly rigid or conveniently negotiable.

Override semantics are especially important. A human authority may decide to accept a candidate despite an open objection or protected-set concern. That authority may be justified, for example, in an urgent security fix or a narrow emergency rollback. But the override must itself become part of the evidence. The ledger should record who overrode the default path, what objection or risk was overridden, what temporary rationale justified the override, what scope the override applies to, and what follow-up evidence is required. Otherwise overrides become invisible precedent and the loop silently redefines its own constraints.

This discipline also helps separate ordinary engineering judgment from recursive-improvement semantics. In everyday engineering work, teams often make informal trades among speed, elegance, safety margin, and cost. A governed improvement loop cannot rely on informal trade culture alone. It must preserve which dimensions were treated as protected, which were allowed to move, and which required escalation. That is what lets later reviewers ask whether the loop is preserving its constitution or quietly adapting it around optimization pressure.

Protected-set thinking also improves benchmark governance. Benchmarks often capture one dimension well and several dimensions poorly. A benchmark can reward speed while ignoring rollback readiness. It can reward patch success while ignoring provenance completeness. It can reward throughput while ignoring review burden. The protected set therefore acts as a standing reminder that benchmark movement is not enough. A candidate should not be promoted just because it wins the measured contest if it degrades the dimensions the benchmark does not see.

Finally, the protected set clarifies how Thesis 1 relates to Thesis 5. Thesis 5 is not only a downstream wrapper. It defines part of the protected set itself. AAF routing, scoped trust, containment, interruptability, and human authority are not optional checks added after improvement. They are part of the definition of what counts as an acceptable improvement. If a candidate cannot coexist with those controls, then for the purposes of this suite it is not an improvement.

Expansion: End-To-End Demonstration Blueprint

The single most valuable future implementation for Thesis 1 is not a broad autonomous improver. It is a narrow, replayable, evidence-preserving demonstration of one complete governed improvement cycle. The point of such a demonstration would be to make the thesis falsifiable in the most practical way possible: a reviewer could inspect whether the stages, records, and acceptance conditions described in the thesis actually exist in an executable path.

The demonstration should begin with a bounded task class. The best first candidate is likely a local software-maintenance task with clear success criteria and low externality, such as a Java agent compilation failure, a dependency break, or a narrow repair to a deterministic utility. This is the right scale because Thesis 4 already has the strongest implementation evidence in the suite, and because compilation, dependency, and limited integration checks provide a grounded validation base. Starting with a high-stakes alignment or causal-decision improvement would invite rhetoric before machinery.

The demonstration should expose ten explicit artifacts.

First, a trigger artifact. This records the observed failure or opportunity, such as a failing build, repeated manual repair, benchmark regression, or validator weakness. It should include timestamp, source, affected scope, severity, and baseline evidence. The purpose is to show that the loop begins from an observed problem rather than from abstract self-improvement desire.

Second, a proposal artifact. This records the candidate change in typed form: files touched, method-memory mutation, prompt or workflow change, expected target axis, expected benefit, and known side-effect channels. The proposal artifact should be tied to the trigger, not free-floating. This makes it possible to later ask whether the proposal actually addressed the original problem.

Third, an evaluator package. This should include baseline, measurement protocol, expected delta, uncertainty, cost estimate, protected-set review, and deployment-stage recommendation. If the evaluator cannot produce these fields, the candidate should move to needs-input rather than to validator review. This artifact is the first proof that the loop distinguishes proposal from evaluation.

Fourth, a validator record. This records invariant checks, compilation or test results, provenance checks, security or permission checks, AAF applicability, deployment decision, and explicit reasons for acceptance, revision, escalation, or rejection. It should show that the validator is not simply echoing the evaluator. Ideally, the validator would differ from the evaluator on at least one field in the first demonstration, to prove the separation is real.

Fifth, a deployment-stage artifact. Even if the first demonstration uses simulation rather than production deployment, it should still move through a named stage such as sandbox or canary-equivalent. That artifact should define what the stage means, what evidence is required to enter it, what monitoring is active inside it, and what rollback would mean from that stage.

Sixth, a post-change observation artifact. This records what happened after the candidate was exposed to the stage. Did the original problem improve? Did new regressions appear? Did cost match estimate? Did monitoring catch a new issue? Was rollback triggered? Without this artifact, the loop ends at acceptance rather than improvement.

Seventh, a ledger entry or bundle of ledger entries. This is the durable record linking trigger, proposal, evaluator package, validator record, deployment-stage artifact, and observation artifact. Even if the current repository does not implement the canonical ledger yet, the demonstration should structure its records according to the ledger schema so that later implementation can import them cleanly.

Eighth, a method-memory update artifact. If the candidate succeeds, the demonstration should show how a reusable method is extracted or strengthened. If the candidate fails, it should show how an anti-pattern, caution note, or benchmark case is created instead. This proves the loop is not just applying one fix; it is converting outcomes into future-improvement substrate.

Ninth, a cost/benefit artifact. This reports proposal cost, validation cost, review cost, and observed benefit under the bounded task class. Without this artifact, the demonstration could look impressive while actually being too expensive to repeat. Cost reporting is essential because recursive capability amplification depends on repeatability, not theatrical one-off wins.

Tenth, a second-cycle seed artifact. The first demonstration does not need to show full compounding, but it should leave behind an artifact that would plausibly affect a second cycle, such as a method memory, anti-pattern, validator benchmark, or routing rule. This closes the loop conceptually and gives a concrete target for the next implementation milestone.

The best first demonstration should include a successful and an unsuccessful candidate. A successful candidate shows that the loop can promote a bounded change. An unsuccessful candidate shows that the loop can reject or revise a plausible change without losing the evidence. Together they demonstrate that the machinery is about governed selection, not about converting all work into apparent progress.

The demonstration should also include at least one near-miss or edge case. For example, a repair candidate might compile and pass basic tests but fail a provenance requirement or trigger a semantic concern. Handling that near miss is valuable because it shows whether the loop can preserve ambiguous evidence rather than flatten it into pass or fail. Near misses are where recursive systems often learn the wrong lesson.

As the demonstrations become stronger, the next bounded extension should show a validator-improvement candidate or a method-memory reuse candidate. That would allow the loop to demonstrate not only object-level repair but also improvement of the improvement machinery itself. A reviewer does not need to see grand recursion. They need to see a real path from first-cycle evidence to second-cycle changed behavior.

The demonstration packet should be reviewable without trusting the narrative. A reviewer should be able to inspect the baseline, candidate, evidence package, validation results, ledger records, cost report, rollback or mitigation state, and method-memory update as separate artifacts. If any artifact exists only as prose, the demonstration is weaker than it looks. The strongest first packet would include both machine-readable records and a short human explanation that points to them. This prevents the suite from relying on persuasive summary language where concrete evidence should exist.

The packet should also include a negative-control case. A negative control is a candidate that looks superficially like an improvement but should fail a specific gate: missing provenance, hidden cost increase, protected-set degradation, absent rollback, or unresolved AAF objection. Negative controls make the acceptance boundary observable. Without them, a successful demonstration may show only that the loop can accept a friendly candidate, not that it can reject a tempting bad one. For recursive improvement, the rejection path is as load-bearing as the acceptance path.

A useful packet should therefore be boring in the right way: every claim points to a record, every record points to a stage, every stage has an expected gate, and every gate can fail. That boring auditability is what separates an improvement loop from a demo script.

It also makes later reviewer disagreement easier to localize.

Expansion: Human Authority, Escalation, And Failure Containment

Recursive improvement proposals often under-specify the human role. They either imagine full autonomy or fall back to vague language about "human in the loop." Thesis 1 needs a more operational account. Human authority is not present merely to approve or deny at the end. Human authority defines escalation boundaries, trade exceptions, emergency override conditions, and the interpretation of unresolved conflicts that the system cannot legitimately settle itself.

A useful way to state the human role is by failure class. Ordinary low-risk failures should be contained by validator rejection, sandbox isolation, benchmark failure, or rollback without needing direct human adjudication every time. High-leverage failures, however, should trigger human review: protected-set trade exceptions, high-stakes externally consequential changes, persistent disagreement between evaluator and validator, unresolved AAF severe objections, unexplained post-deployment regressions, and validator changes that materially affect future acceptance policy. This keeps human authority focused where it has the most governance value.

Escalation should also be typed. Escalation to a human owner is not the same as revision back to a proposer. Escalation to AAF is not the same as escalation to a causal-model reviewer. Escalation because evidence is missing is not the same as escalation because authority is required. The loop should preserve which escalation path was taken, what condition triggered it, and what downstream resolution closed it. This matters because repeated escalations of one type may signal a missing benchmark, a weak validator, a vague specification, or an overloaded governance bottleneck.

Failure containment is another area where vague optimism can hide weak implementation. A contained failure is not simply a failure that happened in a test environment. It is a failure whose scope, side effects, and recovery path were understood well enough that the system did not lose control of the evaluation process. For the improvement loop, containment means at least: the candidate's exposure was bounded, rollback or mitigation existed, evidence was preserved, and the failure generated useful updates to benchmarks, anti-patterns, or routing rules.

Containment also depends on refusing the wrong kind of autonomy. A loop that automatically broadens scope after one successful trial may destroy the very staging semantics that made the first success meaningful. Promotion between stages should therefore require affirmative evidence, not mere absence of failure. The difference matters especially when observations are sparse. "Nothing bad happened" is weak evidence if exposure was tiny, monitoring was weak, or the task class was too narrow.

This section also clarifies why interruptability remains relevant even in a documentation-driven first implementation. An improvement loop that cannot be paused when evidence becomes questionable, when an evaluator behaves strangely, or when an override pressure appears is already too autonomous for its evidence maturity. Interruptability should therefore be thought of as a routine governance affordance, not only an emergency brake.

Human authority and containment are expensive, and they can become bottlenecks. That is not an argument to delete them. It is an argument to measure where they are invoked, why, how often, and whether better validators, clearer specifications, stronger method memories, or narrower scopes can reduce unnecessary escalations. The loop should treat governance bottlenecks as measurable engineering problems, but not by silently removing the governance layer that surfaced them.

Agent Cluster And Architecture

Primary Thesis 1 agents and functions:

Imported but not owned:

Expansion: Operational Workflow

This operational workflow expands the Main Argument's six conceptual stages into eight concrete steps by splitting trigger handling, target selection, staged exposure, observation, and learning into separately auditable records.

The long-form version of Thesis 1 should be judged by whether a reader can imagine the loop running without needing to invent hidden machinery. A minimal operational workflow begins with an improvement trigger. The trigger may be a failing test, a benchmark plateau, an incident, a high-cost workflow, a repeated manual intervention, an AAF objection, a method-memory reuse failure, a user-visible defect, or a strategic bottleneck identified by causal-decision analysis. The trigger should create an improvement_proposal ledger record before candidate generation begins. That record should name the observed problem, current baseline, affected scope, urgency, expected value class, and whether the proposal touches high-stakes or externally consequential behavior.

The second step is target selection. Not every trigger should become an immediate modification attempt. Some triggers should become monitoring tasks, benchmark additions, documentation corrections, or human-review items. AgentImprovementGoalSetter and ExplorationPortfolioManager should decide whether the trigger is worth proposal budget now, later, or not at all. Target selection should account for expected leverage, implementation complexity, validation difficulty, risk lane, and opportunity cost. This is the first place where cost discipline can prevent recursive improvement from becoming unbounded tinkering.

The third step is candidate generation. A candidate generator may use code repair, method-memory mutation, prompt decomposition, new tests, policy edits, routing changes, or agent specialization. Candidate generation should be plural when cost allows: multiple candidates make evaluator comparison more meaningful and reduce dependence on the first plausible solution. But plurality is not free. For low-risk routine failures, a single deterministic repair path may be sufficient. For high-leverage system changes, a small portfolio of candidates should be generated and compared. The generation record should preserve source prompts, method memories used, model or tool identities where applicable, and rejected alternatives when they reveal useful design constraints.

The fourth step is evaluator packaging. The evaluator does not decide acceptance; it decides what the candidate appears to do and what evidence would be needed to trust that appearance. It should identify the improvement axis, baseline, expected delta, cost model, side-effect channels, protected dimensions, proposed validation suite, deployment lane, and rollback plan. For changes that touch learned subsystems, it should also identify distribution-shift checks, sandbagging or capability-elicitation probes, and AI-control review requirements. For high-stakes or externally consequential changes, it should flag I12 and route toward AAF.

The fifth step is validation. Validation should be layered rather than monolithic. A code change may pass formatting and compilation, fail semantic invariants, pass local tests, fail a hidden regression suite, pass benchmarks, then fail AAF because its external effects are unacceptable. A method-memory change may satisfy structure and lineage requirements but fail because it lacks enough reuse evidence. A benchmark change may improve coverage but fail because it creates Goodhart pressure or duplicates existing tests. Validation should produce reason codes, not only pass/fail.

The sixth step is staged exposure. Static validation does not imply production promotion. A candidate may be accepted into sandbox only, canary only, limited internal use, or production. The deployment stage should match the evidence envelope. A change validated only against synthetic tasks should not be described as production-proven. A change validated only on project-local Java repair should not be described as general coding improvement. A change that affects external users should carry monitoring obligations and rollback or mitigation constraints.

The seventh step is observation. Post-deployment monitoring is part of the acceptance loop, not a later operations concern. The system should record whether the expected benefit appeared, whether costs matched estimates, whether side effects emerged, whether incidents increased, whether rollback remained available, and whether downstream agents reused the new method or avoided it. Some candidates should be demoted after observation. Some should be narrowed in scope. Some should be promoted more broadly. Some should become evidence that the evaluator or validator was miscalibrated.

The eighth step is learning. Learning can update method memories, benchmarks, validators, routing rules, documentation, and risk models. A successful change may become reusable; a failed change may become an anti-pattern; a near miss may become a new benchmark; a misleading benchmark may be deprecated; a costly validation path may be optimized. This is the recursive part of the loop: the system improves not only object-level behavior but also the machinery by which future improvements are proposed and accepted.

Expansion: Benchmark And Evaluation Strategy

Thesis 1 needs a benchmark strategy broad enough to evaluate recursive improvement and narrow enough to avoid grandiose intelligence claims. The canonical benchmark-design contract for this strategy is appendix-thesis-1-improvement-loop-benchmarks.md. This body section explains the evaluation logic; the appendix defines benchmark families, required report fields, negative controls, minimal demonstration package, and non-claim boundaries.

The benchmark strategy should have layers. At the bottom are deterministic repository checks: compilation, dependency validation, static analysis, unit tests, integration tests, and schema validation. These checks are necessary because they catch concrete defects cheaply. They are not sufficient because they mostly measure local correctness under known conditions.

The next layer is project-local capability benchmarks. These should be built from recurring Consullo tasks: generating or repairing Java agents, inserting check-in methods, fixing dependency errors, updating method memories, routing A2A calls, validating JSON envelopes, and composing atomic prompts into executable workflows. Project-local benchmarks are valuable because they match the actual substrate of the system. They also carry overfitting risk because the system can learn the shape of its own tests. They should therefore include held-out tasks, adversarial variants, and periodic refreshes.

The third layer is external comparison benchmarks where appropriate. SWE-bench-style tasks matter for Thesis 4 and therefore for Thesis 1 when code repair is the improvement object. METR-style autonomy evaluations matter when the question is whether the system can sustain longer, less-scaffolded tasks. Forecasting or calibration benchmarks matter when evaluator predictions are being tested. These external benchmarks should not be treated as direct measures of Seed AI viability, but they can bound claims against public evidence.

The fourth layer is recursive-loop demonstrations. This is the most important missing benchmark class for Thesis 1. A recursive-loop demonstration should show at least one complete cycle: baseline, proposed change, evaluator package, validator decision, staged deployment or simulation, cost/benefit report, rollback semantics, evidence-ledger records, method-memory update, and post-change observation. A stronger demonstration would include a second cycle in which the first accepted change improves the quality, cost, or reliability of the second cycle. Until such demonstrations exist, the thesis remains specified/proposed.

The fifth layer is negative benchmarking. The loop should be tested not only on good candidates but also on tempting bad candidates. Examples include patches that pass compilation while breaking semantics, benchmark additions that reward overfitting, method memories with missing preconditions, candidates with hidden cost increases, prompts that produce plausible but untraceable code, and high-stakes actions with missing AAF review. A validator that accepts only obvious successes and rejects only obvious failures has not been tested against the real threat model.

Evaluation should report both false accepts and false rejects. False accepts are dangerous because they promote harmful changes. False rejects are also important because a loop that rejects too much may stagnate, hide useful ideas, or push agents toward bypassing the gate. Tracking false rejects does not mean weakening validation. It means preserving evidence about promising rejected changes, revisiting them when new evidence arrives, and measuring whether validators are too conservative in low-risk scopes.

Evaluation should also report cost-normalized improvement. A change that improves performance by 5 percent at ten times the validation cost may be less valuable than a 2 percent improvement that is cheap, robust, and reusable. Conversely, a high-cost validation path may be appropriate for security, privacy, or alignment-critical changes. Cost-normalized reporting makes these tradeoffs explicit. It also helps detect when recursive improvement is failing to compound because validation or coordination overhead grows faster than benefit.

Finally, the benchmark strategy should include benchmark governance. Benchmarks should have versions, owners, refresh rules, retirement criteria, known limitations, and Goodhart-risk notes. Benchmark changes themselves are modifications subject to Thesis 1. Adding a benchmark can improve the loop, but it can also distort it. Removing a benchmark can reduce noise, but it can also hide regressions. Benchmark governance is therefore part of recursive improvement, not a side document.

Expansion: False Accepts, False Rejects, And Validator Evolution

The validator is the central bottleneck of the improvement loop. If it is too weak, the system accepts harmful changes. If it is too strict or too narrow, the system fails to improve or learns to optimize for validator appeasement. Thesis 1 therefore needs an explicit theory of validator evolution.

A false accept occurs when a change is promoted and later evidence shows that it should have been rejected, narrowed, revised, or escalated. False accepts can arise from incomplete tests, benchmark overfitting, missing side-effect channels, poor causal assumptions, insufficient AAF review, stale trust estimates, hidden implementation costs, or deceptive behavior by learned subsystems. The response should not be only rollback. The response should include validator repair: add a benchmark, change evidence requirements, update risk classification, revise method-memory eligibility, or increase scrutiny for similar future candidates.

A false reject occurs when a change is rejected and later evidence shows that it would likely have been beneficial under an acceptable scope. False rejects can arise from overly broad risk classification, missing benchmark coverage, conservative evaluators, high validation cost, or insufficient ability to stage a candidate safely. False-reject tracking matters because it tells the system where validation machinery is preventing useful improvement. The correct response may be sandboxing, narrower scope, better measurement, cheaper validation tools, or more precise rollback.

Validator evolution should be treated as recursive but constrained. Validators can be improved, but a validator-improvement proposal is itself high leverage because it changes what future changes can pass. A validator patch should therefore face stricter scrutiny than an ordinary object-level improvement. It should be tested on a reference suite containing accepted-good candidates, rejected-bad candidates, adversarial near misses, and historical false accepts. Thesis 4's validator-non-regression idea applies here: improving generators while weakening validators is a classic route to false confidence.

The validator should also resist metric capture. If agents learn that acceptance depends on one benchmark, one report format, one confidence phrase, or one validator model family, they will shape proposals around those features. Some of this shaping is useful standardization. Too much becomes Goodhart pressure. Validator evolution should therefore include hidden tests where appropriate, rotating adversarial checks, critique-source diversity, and periodic review of whether accepted changes continue to perform outside validation distributions.

Another validator risk is authority drift. A validator may gradually expand from checking evidence into defining objectives, overriding alignment gates, or converting human authority into a routine rubber stamp. Thesis 1 must keep the validator's role bounded. The validator gates acceptance under imported objectives and constraints; it does not own the constitution, AAF, human authority, or all utility definition. When objectives conflict or high-stakes alignment concerns arise, the validator routes to Thesis 5 rather than resolving the conflict alone.

The improvement loop should maintain validator health metrics: false-accept rate, false-reject rate, post-deployment regression rate, benchmark transfer rate, validation cost, review latency, disagreement frequency between evaluator and validator, AAF escalation rate, rollback rate, and incident correlation. These metrics should be interpreted carefully. A lower false-accept rate achieved by rejecting nearly everything is not necessarily better. A lower escalation rate may mean better routine screening or may mean alignment concerns are being suppressed. Validator health is multi-dimensional.

A particularly clean validator technique for distilled artifacts — method memories, skills, prompts, documentation — is reconstruction-based validation. External work on quality-guaranteed skill generation verifies an induced skill by handing it to an independent deduction agent whose prompt is frozen and which receives no access to the source trajectory, then testing whether that agent can reconstruct the original solution from the skill alone (MIND-Skill: Quality-Guaranteed Skill Generation via Induction and Deduction, arXiv:2605.08670, "MIND-Skill: Quality-Guaranteed Skill Generation via Multi-Agent Induction and Deduction"). Because the reconstructing agent is frozen and unguided, any divergence between its trajectory and the source is attributable to the artifact, not to the reconstructor's own competence — which disentangles two signals that outcome-only validation conflates: a capable agent can succeed despite a poor artifact, masking a false accept, and a weak agent can fail despite an adequate one, manufacturing a false reject. Three complementary checks make the signal robust: a reconstruction check at the tactic level (same procedural logic, not identical API calls or variable names), an outcome check that executes the reconstruction in a live environment to catch silent failures textual judgment misses, and a rubric check on documentation quality and abstraction level. Two anti-leakage safeguards bear directly on the metric-capture and overfitting risks above: the artifact is penalized both for retaining instance-specific implementation detail (ground-truth leakage and over-specificity) and for being too abstract to act on, and the optimizer that revises the artifact is shown only the reconstruction, never the source, so it cannot copy source-specific detail into the artifact to pass validation. For Consullo this is an importable validator design wherever an artifact's value depends on reuse by other agents: accept a method memory or skill not because its author succeeded with it, but because a fresh, unguided agent can re-derive the solution from it.

Expansion: Source-Corpus Reconstruction

The Consullo source corpus contains a more ambitious and sometimes more overclaim-prone self-improvement story than this thesis should preserve unchanged. Chapter 03 describes the SelfImprovementOrchestrator as a broad engine for recursive enhancement across the agent ecosystem. It names meta-learning, evolutionary optimization, knowledge discovery, method-memory organization, and safety-constrained enhancement as parts of the architecture. That corpus is useful because it shows the intended breadth of the improvement layer. It is risky because broad language can make implementation sound more mature than it is.

Thesis 1 reconstructs that corpus into a narrower claim. SelfImprovementOrchestrator becomes the coordinator of improvement activity, not evidence that the improvement loop is already closed. AgentImprovementGoalSetter becomes a source of structured goals, not proof that generated goals improve capability. AgentCapabilityImprover becomes a proposer and analyzer, not an acceptance authority. AgentComplianceValidator becomes one validator role among many, not a sufficient safety guarantee. RecursiveEnhancementTracker becomes an evidence and trend instrument, not proof of monotonic recursive enhancement.

Method-memory machinery is especially important. The corpus contains MethodMemoryExtractor, MethodMemoryOrganizationOrchestrator, MethodMemoryLearningOrchestrator, contextual bandit optimizers, reinforcement-learning rankers, canonical retrievers, semantic rankers, compatibility validators, and reuse feedback managers. These designs make method memory a plausible substrate for recursive learning. But plausibility is not validation. Thesis 1 treats method memories as evolvable artifacts only when they have structure, lineage, validation history, cost profile, and deprecation semantics.

The DGM design is the closest internal source to the Thesis 1 formal spine. It explicitly shifts from formal proof to empirical validation, focuses on method-memory specifications, uses population-style evolution, and archives lineage. Thesis 1 should cite that internal direction while tightening the claim: empirical validation is useful only if the benchmarks are meaningful, the selection pressure is not gamed, and the archive preserves negative evidence. The DGM pattern supports a scaffold for recursive improvement; it does not by itself establish general self-improvement.

The agentive-seed-ai and achieving-ASI materials should be treated as prior overclaim-prone source material. They are valuable for ambition, agent inventory, and design imagination. They should not control the thesis vocabulary. Long-form Thesis 1 should repeatedly translate earlier "enhancement" and "superhuman" language into measurable claims: what changes, according to what metric, under what scope, with what evidence, at what cost, and under what invariants?

This reconstruction also matters for future implementers. If an implementer reads only the older source corpus, they may build toward maximal autonomy first and validation second. Thesis 1 reverses that priority. The loop is not "agents improve themselves, then governance checks them." The loop is "candidate modifications become improvements only through governance, evidence, and staged acceptance." That distinction is the difference between recursive capability amplification as a research program and recursive modification as a risk amplifier.

Formal Model Summary

Let pi_t be the current Consullo agent population, including code, method memories, prompts, routing rules, tests, and governance state. A candidate modification delta is proposed against a target scope s. The evaluator constructs evidence package E_delta. The validator applies invariant set I, benchmark set B, cost model K, and deployment policy G.

The simplified acceptance rule is:

Accept(delta, s) iff
  HardInvariants(pi_t, delta, s) hold
  and EvidenceSufficient(E_delta, B, K)
  and RiskWithinScope(E_delta, s)
  and AAFNonVeto(delta, s) when I12 applies
  and RollbackOrMitigationDefined(delta, s)

For empirical improvement claims:

Improve(delta) iff
  Metric(candidate, task_class) - Metric(baseline, task_class) >= epsilon
  with confidence >= 1 - alpha
  within stated side-effect, cost, and deployment constraints
  and TransferVerified(delta) when the candidate's value depends on reuse:
    Metric(fresh_agent_with_delta, task_class)
      - Metric(fresh_agent_baseline, task_class) >= epsilon_t
    where fresh_agent did not participate in generating delta

The TransferVerified conjunct encodes the update-versus-benefit distinction: a harness change that moves the originating agent's metric but not a fresh agent's is an update without established benefit, and remains transfer-unverified rather than accepted as an improvement.

This is not a proof of global improvement. It is a staged empirical acceptance condition. The authoritative full rule is maintained in appendix-formal-models.md Model 1.

Literature-Grounded Extension

Goedel Machines provide the formal ideal: self-modification accepted by proof of improved expected utility. Darwin Godel Machine work shows a more practical empirical path: generate code changes, evaluate them on benchmarks, and retain successful variants. Consullo's design should be framed as another empirical relaxation, broader in scope but more obligated to governance. It extends beyond code repair into method memories, agent populations, prompt decomposition, policy changes, and trust state, so it needs stronger evidence discipline than coding benchmarks alone provide.

Risks from learned optimization, Goodhart variants, specification gaming, AI control work, and SWE-bench-style software evaluation all shape the loop. They imply that passing tests is not sufficient, learned subsystems require control review, metrics can be gamed, and deployment evidence must matter. The improvement loop is therefore designed around false-accept reduction, but it must also track false rejects so the system does not become too conservative to improve.

Seed AI Relevance

This thesis is the Seed AI spine because recursive capability amplification requires a mechanism by which the system's own improvement machinery can become an object of improvement. AgentImprovementGoalSetter can be improved. AgentCapabilityImprover can be improved. Method-memory selection policies can be improved. Validators can be improved. Benchmarks can be improved. But each recursive step increases the importance of provenance, evidence, invariants, and staged deployment.

The loop's status is specified/proposed. Some supporting agents and documents exist in the design corpus, and some related code may exist elsewhere in the Consullo repositories, but this thesis treats the full integrated loop as an architectural target until implementation and benchmark evidence establish otherwise.

The withheld implementation-evidence appendix cannot support public component gradings pending owner re-verification. This page therefore treats the full recursive improvement loop, canonical evidence ledger, and AAF-gated acceptance path as gaps and makes no narrower implementation claim.

Under the organizational RSI interpretation, improvement targets also include research workflows, agenda-setting routines, portfolio policies, evaluator and validator designs, institutional memory, pre-registration templates, and post-cycle learning. These targets still enter the same Thesis 1 discipline: a proposed routine or workflow is only an improvement after the Promote(pi_t, delta) path accepts it against evidence, cost, protected-set, provenance, and governance checks. The publication boundary for this broader operating layer is specified in appendix-organizational-recursive-self-improvement.md; live execution rules are specified separately in the internal execution plan.

Expansion: Implementation Mapping

The implementation evidence for Thesis 1 should be read as a partial foundation, not as a closed loop, and as of August 2026 it is a narrower foundation than it was. Main, AgentCompilationValidator, and AgentBuilderReport provide concrete evidence that parts of integration, compilation validation, and reporting exist in the repository, and each is exercised by repository tests. Dependency validation, repair orchestration, and A2A method-call testing had implementations until 2026-08-10, when the subsystem containing them was deliberately removed and the agent runtime moved to Main; they are currently specified rather than implemented, and no successor class performs them. What remains is still valuable because it shows that Consullo is not only a conceptual agent inventory. There is executable infrastructure that can compile, inspect, dispatch, or report parts of the agent ecosystem — a shorter list than before, and the honest one.

The missing piece is orchestration across the full acceptance lifecycle. A compilation validator can tell whether the repository builds. A dependency validator can detect circular dependencies or integration-order failures. A repair manager can coordinate fixes for certain classes of failure. But an improvement loop requires more than those pieces: it must connect trigger, proposal, evaluator package, validator decision, deployment stage, post-change observation, evidence-ledger write, method-memory update, and population promotion. The evidence map correctly treats this as a gap.

The first implementation milestone should therefore be narrow. It should not attempt to implement general recursive self-improvement. A defensible first milestone would choose one bounded task class, such as Java agent compilation repair. The demonstration would begin with a known baseline failure, generate or select a candidate repair, build an evaluator package, run compilation and dependency validation, record cost and provenance, decide whether to accept the candidate into a sandbox or branch, record the result in the evidence ledger, and update a method memory or anti-pattern. Even if the candidate is rejected, the demonstration would still validate the loop structure.

The second milestone should include a rejected candidate. A loop demonstrated only on a successful repair can hide validator weakness. A better demonstration shows that the system can reject a plausible but unsafe or insufficiently evidenced candidate, preserve the reason, and convert the rejection into useful future evidence. For example, a patch that compiles but removes a required validation check should be rejected with reason codes linking semantic failure, security risk, or protected-set regression. That rejection should create a reusable anti-pattern.

The third milestone should include staged exposure. A candidate that passes tests should not jump directly to production status. It should move through a controlled state such as sandbox or canary. In documentation-only form, this can be simulated; in implementation, it should correspond to a branch, isolated run, limited agent set, feature flag, or scoped deployment environment. The important point is that the stage is not just a label. The stage determines what evidence is required, who can rely on the result, what rollback means, and what monitoring obligations exist.

The fourth milestone should include a second-cycle effect. Recursive improvement becomes visible only when a prior accepted change improves a later improvement cycle. A modest example would be a method memory extracted from a successful compilation repair that reduces proposal time or false-repair rate in a later repair task. Another example would be a validator enhancement that catches a defect missed in the first cycle. The second-cycle effect should be measured narrowly. It need not prove compounding intelligence. It only needs to show that the improvement machinery can become an object of measurable improvement.

The fifth milestone should include AAF or Thesis 5 routing for a high-stakes example, even if simulated. The first implemented loop may focus on low-risk software repair, but the architecture claims that high-stakes externally consequential actions require AAF non-veto or human escalation. A test fixture should therefore include an I12-covered candidate and demonstrate that the loop routes it to AAF rather than accepting it through ordinary validation. This would not prove alignment, but it would show that Thesis 1 does not route around Thesis 5.

Expansion: Open Research Questions

The first open question is how to set epsilon and alpha for improvement acceptance. A minimum improvement margin and false-accept tolerance cannot be universal across all task classes. Compilation repair, trust-state adjustment, benchmark generation, AAF process changes, and method-memory mutation have different risk profiles. The near-term policy should set parameters per scope and treat them as pending until empirical history exists. Over time, parameter selection should become a governance object: if false accepts rise, thresholds may tighten; if false rejects dominate low-risk tasks, staging or measurement may improve.

The second open question is how to measure protected-set non-regression. The formal model names alignment, security, privacy, rollback readiness, provenance, and core reliability as protected dimensions, but early implementation may not have quantitative measures for all of them. This does not invalidate the model; it makes the protected set a mixed quantitative and qualitative gate. The research task is to define minimum observable indicators for each protected dimension, such as security test results, provenance completeness, rollback rehearsal success, incident history, AAF disposition, and privacy-review status.

The third open question is how to assign credit without creating perverse incentives. If agents receive too much credit for accepted changes, they may generate conservative candidates that pass easily but do little. If they receive too much credit for ambitious proposals, they may flood validators with speculative work. If validators are rewarded only for rejecting bad changes, they may become too conservative. Credit assignment should therefore measure downstream outcomes, cost, reuse, false accepts, false rejects, and contribution to evidence quality. This remains a research problem.

The fourth open question is how much autonomy the loop should have at each deployment stage. A fully manual loop is safe but may not compound. A fully autonomous loop is fast but unsafe. The likely answer is stage- and scope-dependent autonomy: low-risk, well-benchmarked, reversible changes can move further with automated gates; high-stakes, irreversible, externally consequential, or alignment-relevant changes require AAF and human authority. The long-form suite should resist collapsing this into one global autonomy setting.

The fifth open question is how to prevent validator monoculture. If the same model family proposes code, evaluates evidence, generates tests, and validates results, the loop may become internally coherent while missing shared blind spots. Thesis 1 inherits this problem from all AI-assisted engineering systems. The mitigation is not perfect independence but layered diversity: deterministic checks, different model families where feasible, static tools, human review, AAF for high-stakes cases, adversarial tests, and post-deployment evidence.

The sixth open question is whether method-memory evolution will produce reusable improvement or merely accumulate local procedures. A method memory is useful for recursive improvement only if it transfers across relevant contexts without hiding invalid assumptions. The system should therefore track reuse success by task class, failure rate after reuse, adaptation cost, dependency drift, and deprecation frequency. Method memories that are rarely reused or often misapplied should be narrowed, deprecated, or converted into anti-patterns.

The seventh open question is how to integrate causal-decision reasoning without overclaiming. Thesis 3 can help select interventions, analyze Goodhart risk, and design experiments, but causal models are themselves fallible. The improvement loop should use causal reasoning to improve evaluation quality while preserving the empirical discipline that causal claims need evidence, scope, and validation. A causal explanation should never replace observed outcome evidence when the modification is deployed.

Expansion: Claim Status Table

The following status table should guide long-form revisions:

ClaimCapability StatusEvidence StatusNotes
Consullo specifies a staged improvement-loop architecturespecifiedDocumentedSupported by this thesis, vocabulary, formal model, and roadmap.
Repository contains supporting integration and validation utilitiesimplemented for partsImplemented/Tested for partsSee implementation evidence map; not a full loop.
Full proposer/evaluator/validator separation is operational across ConsulloproposedGapNeeds end-to-end demonstration and role wiring.
Evidence-ledger schema existsspecifiedDocumented/ProposedSchema appendix exists; implementation pending.
AAF-gated acceptance path exists for I12-covered changesspecified/proposedGapThesis 5 contracts exist; runtime integration pending.
Method memories can be evolved under DGM-style selectionspecified/proposedDocumented/ProposedInternal DGM and method-memory designs support the direction; benchmark evidence pending.
Recursive improvement has been demonstrated end to endproposedGapPublication-priority evidence gap.
Validator evolution can improve future validation without weakening gatesspecified/proposedGapRequires reference suites and validator non-regression.
Harness updates transfer to fresh agents rather than overfitting the originating agentspecified/proposedGapRequires a fresh-agent (ideally cross-model-family) transfer protocol in the benchmark suite; see appendix-thesis-1-improvement-loop-benchmarks.md Suite D.
End-to-end joint harness optimization generalizes beyond the optimization eval setspecified/proposedGapRequires optimizer-blind held-out and fresh-agent transfer evaluation; jointly-optimized candidates recorded as one acceptance unit with ablation-based credit.
Self-proposed harness edits improve capability rather than compile to the acceptance signalspecified/proposedGapRequires the proposer to be blind to the frozen held-out and fresh-agent transfer sets during search; acceptance stays on the full gate (protected set, cost, rollback, transfer), not pass-rate non-regression alone; per-model-tier harness variants recorded separately since harness edits are model-specific.

This table is intentionally conservative. It prevents the long-form thesis from sounding stronger merely because it has become longer. The more detailed the architecture becomes, the more important it is to preserve the distinction between specified mechanism, implemented component, tested behavior, and demonstrated recursive improvement.

Recursive Self-Improvement Contribution

The validated improvement loop contributes to recursive self-improvement in three ways.

First, it makes improvement objects explicit. Agents, method memories, tests, prompts, policies, and evaluation procedures can all be versioned, compared, and selected.

Second, it makes improvement evidence durable. Accepted and rejected changes create reusable evidence rather than disappearing into narrative memory.

Third, it makes improvement bounded. The loop rejects changes that violate invariants, lack evidence, exceed scope, lack rollback, or trigger unresolved AAF objections. This boundedness is not a weakness of the Seed AI claim; it is what lets improvement remain governable.

Risks, Constraints, And Governance

The primary risk is false acceptance: the system may accept a change that improves a benchmark while degrading real capability, alignment, security, maintainability, or coordination. Goodhart pressure and specification gaming are therefore central.

The second risk is deceptive or hidden optimization. Improvements to learned subsystems require AI-control review, distribution-shift monitoring, sandbagging or capability-elicitation probes where material, and evidence-ledger preservation.

The third risk is cost explosion. Recursive improvement fails if cost per accepted improvement grows faster than useful capability. QualityCostBalancer and internal resource accounting are necessary but not sufficient; every accepted non-emergency improvement must report cost/benefit evidence.

The fourth risk is alignment bypass. Thesis 1 must not route around Thesis 5. I12 binds the AAF to high-stakes irreversible or externally consequential changes whose effects may occur before rollback. Human authority, containment, and interruptability remain active controls.

Specialized Summary

The Validated Improvement Loop And Its Invariants reframes Consullo self-improvement as disciplined empirical engineering. It is not a proof-based Goedel Machine and not a claim of reached ASI. It is a staged architecture for proposing, evaluating, validating, deploying, monitoring, rolling back, and learning from system modifications. Its strength is that it makes recursive improvement measurable and governable. Its weakness is that every validator, benchmark, and cost model can itself become a target of optimization. The next theses supply the cognitive, causal-decision, software, and alignment machinery that this loop imports, but the loop provides the common contract: no modification counts as improvement without evidence, status, cost, provenance, and invariant-preserving acceptance.