improvement-loop

Type: types/tag-readme.md

How improvement candidates are searched for, evaluated with the possibility of rejection, and retained so that later operation depends on them. Assign this tag to work on these functions, their coordination and failure, or their boundary with direct updates that adopt a change without a separate candidate-admission decision. The establishing note is a proposal-selection improvement loop requires search, evaluation, and operative retention. A recurring task loop alone is insufficient: the subject must be how a change becomes a candidate, is selected, or affects later operation. Theory-builder covers the stated theories guiding the work and criticism of their content; work on how that criticism controls candidate search can carry both tags. A child of self-improving-systems.

Loop structure

• A proposal-selection improvement loop requires search, evaluation, and operative retention — the three required functions
• An omitted improvement-loop function and a frozen one need different repairs — five systems with frozen functions, and why a direct update lacks a gate without omitting one
• False-positive generation is filtered; false-positive acceptance becomes operative — why errors at acceptance cost more than errors at generation
• Distinct residue classes require distinct functions in a self-improving architecture — different reasons a decision stays untransferred point to different missing functions

Search and search control

• Open-ended improvement must allocate search before decisive evaluation is available — even a proof-gated loop must first choose what to develop
• Lightweight search control allocates further search without licensing adoption — the authority of a search judgment stops short of an operative change
• Backtracking keeps lightweight search control provisional — restoring an earlier state keeps a heuristic branch choice revisable
• A search controller is tested by what it brings to stronger evaluation — judge the controller by the branches it routes on, not as acceptance claims
• A failure explanation becomes search control only when it changes a later branch decision — the operative test for a retained failure explanation
• Natural-language project state may specialize weight-resident search heuristics — intent, theory, and branch history steer heuristics the model already holds
• The 2026-08-30 Commonplace revision used retained theory to guide computational search — an observed loop: computational search, operator selection

Evaluation and selection

• Choosing what to learn requires both validity and learning-value gates — trustworthy to learn from is a different check from worth learning
• Diagnostic richness constrains outer-loop learning quality — selection needs inspectable failure evidence, not only a winner-picking oracle
• Evaluation automation is phase-gated by comprehension — error analysis and judge discrimination come before automated optimization
• Weakly discriminated qualities tend to be underselected — what an oracle cannot tell apart, selection does not enrich
• Oracle accumulation improves selection for later candidates in its maintained domain — a failure kept as a maintained check improves later selection

Related Tags

• self-improving-systems — the parent: evidence-responsive changes to a system's own organization, whether by proposal selection or direct update
• theory-builder — the theories that guide search; shares the notes on theory-guided search
• software-factory — factory revision is one target a loop can retain changes into
• reflection — loops whose retained changes pass through a self-representation
• warranted-autonomy — which evaluation and acceptance decisions a computational actor is warranted to take
• continual-learning — retention that accumulates across many loop iterations