An omitted improvement-loop function and a frozen one need different repairs

Type: kb/types/note.md · Tags: foundations, self-improving-systems, deploy-time-learning

When a proposal-selection improvement loop underdelivers, the useful first question is which of search, evaluation, and operative retention is doing no work — and then which of two things is wrong with it.

The architecture-neutral causal obligations belong to the self-improving-system definition. Failure there is a missing or unestablished causal link. Omitted is narrower: a function is omitted only relative to an architecture that requires it. In a proposal-selection pathway, an accepted patch that is never installed omits operative retention. A direct update exposes no separate candidate–adoption decision, so adding a reject-capable gate would introduce proposal selection rather than fill an omitted universal function.

A function is frozen when something performs it, but that something sits outside the loop's effective update space — a fixed acceptance rule, a human generalization judgment, a declared edit surface. The loop closes; it cannot revise how it closes. (The word is overloaded in this KB — frozen weights, a frozen tool loop, a frozen taxonomy. Here it means only this: outside the update space of the loop under discussion.) A frozen function is the loop-anatomy view of a human decision deferred rather than removed: externalized into an artifact the pathway consumes but cannot revise.

The two diagnoses are worth separating because their repairs are not the same kind of work. Adding an omitted required function is bounded engineering: connect an accepted proposal to a live authority path, for example, and the loop gains the operative retention it lacked. Unfreezing a function is not, because whatever criterion governs the lift is itself fixed one level up — the open question left standing at the end of learning inside a fixed decomposition. Some functions should stay frozen: machinery persists by warrant, not position, which also argues that what stays permanently external is a function class rather than a component class — the objective, the standing commitments, the adoption no. A frozen acceptance rule may therefore be the warranted kernel rather than the defect. Frozen names where a component sits; it does not by itself convict. And when a freeze is defended rather than merely inherited, the defences split: a protective freeze keeps the component outside the loop to resist a named failure, such as objective hacking; an affordable freeze is a resource compromise, liftable in principle. Lifting them costs different things — a protective freeze needs a replacement defence, an affordable one only budget.

What makes the distinction load-bearing rather than pedantic is that a reported improvement cannot separate them. Headline gains cannot establish whether a required function is absent, present but frozen, or not required by the chosen architecture. Classifying the update architecture and then reading its effective update space is the only way to tell, which is why the readings below are drawn from what each paper declares editable rather than from its headline numbers.

Five proposal-selection systems and one direct-update contrast

The six-path evidence inventory owns the underlying causal-path qualifications and supplied-machinery inventory. This table keeps the distinct update-architecture and lifecycle reading.

System Architecture and update determination Evaluation in proposal selection Operativity and lifecycle evidence
Self-Harness Proposal selection — the same model mines failure signatures and proposes several bounded harness edits. Present and reject-capable, frozen: a fixed two-split pass-count rule, whose "held-out" split the gate consults repeatedly. Gate-passing edits are merged and exercised in later harness evaluations; no criterion-driven retirement path is reported.
Continual Harness Direct update — a Refiner reads recent trajectory windows and directly determines edits to prompts, sub-agents, skills, and memory. Not a separate role in this architecture: no independently rejectable candidate is exposed. Edits enter the next step; prompt and harness changes are exercised, while memory reuse is sparse and most authored skills are unused. Limited deletion and demotion do not establish a system-wide retirement path.
Autogenesis Proposal selection — typed Reflect/Select/Improve operators act over registered resources. Present and typed, frozen: Evaluate can reject, but the objective, acceptance rule, and learnability mask are protocol state the loop does not set. Versioned commit, lineage, and rollback supply the strongest lifecycle controls in this cohort; rollback is not retirement.
Accumulated Behavioral Rules Proposal selection — an engineer generalizes an accepted code-review comment into a candidate rule. Frozen at the instance level: an engineer judges the correction generalizable, and an accepted edit verifies the change, not the rule. The paper reports loading across two interfaces and no recurrence over 74 post-rule exposures, without a control isolating causal uptake. The file is append-friendly and rules are refined; removal is described inconsistently as rare and as prohibited.
Darwin Gödel Machine Proposal selection — a fixed external model reads an archive agent's logs and proposes a descendant edit; benchmark score steers parent sampling. Present as a frozen viability filter: children that compile and retain code-editing ability are admitted even when benchmark score regresses. The archive is monotonic by design — the greedy variant drops from 50.0% to 39.7%, so non-retirement is part of the search mechanism.
HyperAgents Proposal selection — a selected hyperagent rewrites the unified task/meta-agent program that generates later descendants. Present and frozen in the main experiments: fixed viability checks, evaluators, and a handcrafted parent selector govern eligibility, scoring, and later use. An appendix makes parent selection editable, but not evaluation or the outer archive loop. Selected patch lineages are replayed into later generations. Archive lineage preserves variants; no system-wide semantic retirement path is reported.

Three readings follow from the table.

Classify the update architecture before diagnosing omission. Self-Harness, Autogenesis, Accumulated Behavioral Rules, the Darwin Gödel Machine, and HyperAgents expose rejectable candidates and can therefore be read through search, evaluation, and operative retention. Continual Harness directly determines its successor. Its absent rejection stage is architectural, not an omission; its evidential limits lie in the fixed evidence-to-edit machinery and uneven evidence that individual retained artifacts affect later behavior. This cohort therefore supplies no clean omitted-function example. Omission remains a valid diagnosis within proposal selection, but it is not instantiated by these six systems.

Evaluation is frozen in the five proposal-selection cases. Each has reject-capable admission or acceptance machinery outside the update space it governs; none searches over its own acceptance criterion. Continual Harness instead holds its evidence-to-edit rule and surrounding decomposition fixed, but has no evaluator to freeze. The papers justify these placements unevenly. The Darwin Gödel Machine separately hides a hallucination evaluator against objective hacking and freezes its exploration controller as an affordable compute compromise; neither defence establishes that its ordinary viability gate should remain fixed. Accumulated Behavioral Rules argues for human validation because authoritative bad rules amplify errors, but its data do not validate the engineer's generalization judgment. Self-Harness and Autogenesis do not separately defend why their gates remain outside the update space. Autogenesis at least makes the boundary unusually legible: its learnability mask exposes what is editable. HyperAgents supplies the sharpest partial unfreezing elsewhere: its main experiments also keep parent selection fixed, while an appendix installs evolving parent-selection code that governs later iterations. This moves search allocation rather than the acceptance criterion. The learned selector does not significantly beat random selection and remains below the handcrafted selector, so bringing a function inside the update space demonstrates operative reach without demonstrating a better function. Version lineage and rollback establish recoverability, not whether the accepting oracle was sound, because warranted autonomy is bounded by oracle domain, not by commit reversibility.

None of the six descriptions establishes a system-wide, criterion-driven retirement path across all retained artifact types. Continual Harness reports limited deletion and demotion, while Accumulated Behavioral Rules supports in-place refinement and describes removal inconsistently. The Darwin Gödel Machine and HyperAgents deliberately retain archive lineages because discarding apparently bad agents can foreclose stepping stones. Retirement is therefore an unresolved lifecycle placement, not a universally omitted stage of one improvement episode. The proposal-selection decomposition asks whether an accepted change becomes operative, not whether an operative change can later stop being one; it has no settled place for the operations catalogued in retire, redact, supersede, relax.

Scope

  • These are readings of published descriptions, taken through this KB's ingest reports rather than from code. Code-grounded reviews exist for Autogenesis and HyperAgents; the Darwin Gödel Machine code has not been inspected here, and the remaining three systems have not been independently reproduced. A code-grounded audit could move any cell.
  • "Omitted" applies only after the architecture has been classified. Within a reported proposal-selection loop, omission means that the published account establishes no implementation of a required role. A direct pathway does not omit evaluation merely because it has no rejection stage.
  • The six sit in one research neighbourhood — 2025–26, mostly fixed-weight editing of readable harness, rule, or scaffold artifacts, one of them observational production data. The five proposal-selection rows instantiate frozen evaluation, while Continual Harness supplies an architecture-boundary contrast; the sample contains no empirical omitted-function case and supports no claim about the field's distribution.
  • Search, evaluation, and operative retention describe proposal selection, not the universal anatomy of self-improvement. The architecture-neutral obligations belong to self-improving system: a direct pathway can freeze its update rule or fail a general causal link, but it does not omit an evaluator it never required. Retirement remains a separate lifecycle-placement question, and whether any coarse function list can serve as a cross-system ontology is still open.

Open Questions

  • Is retirement a fourth loop function, a second requirement inside operative retention, or a property of the retained artifact's lifecycle that sits outside the loop entirely?
  • Is there a system in this neighbourhood whose acceptance criterion, rather than only its search or parent-selection policy, is inside its own update space, and what stops the resulting regress from being vacuous?

Relevant Notes: