Weeks 14–15. Prerequisite: Modules 1–9 and Part 0, §§0.1, 0.4, 0.7.

10.0 Module map and objectives

Modules 1–9 built a harness and taught you to measure, constrain, and maintain it. This module turns the harness into an object of optimisation: a system that proposes edits to itself, evaluates them, and keeps the ones that work. The idea is the logical extension of Module 9’s entropy management — if drift accumulates, a loop that detects and corrects it is better than a human who does so periodically — and it is the practical form of the “self-improving” systems the field has been discussing.

The module is also the curriculum’s most careful exercise in epistemic discipline. The headline results — Agentic Harness Engineering (AHE), Self-Harness, Harness-Zero, AlphaEvolve, the Darwin Gödel Machine — are all tier P (preprints, unreplicated) or tier S at best. They are exciting, and they are hypotheses. The module teaches the loop and the discipline for evaluating whether the loop works, because a self-evolution loop that is not held to the Module 5 standard is a machine for overfitting to its own benchmark.

The module has five parts and one lab.

By the end of the module you will be able to do eight things:

1. Formalise harness engineering as an optimisation problem over a structured, discrete, partially revertible space with a noisy, expensive, non-stationary objective.
2. State the three observability pillars (component, experience, decision) and explain why each is necessary for the loop.
3. Specify a closed evolution loop with a self-declared prediction per edit, and explain why the prediction is a variance-reduction device.
4. Describe Self-Harness’s three mechanisms and Harness-Zero’s distillation, with their evidence status.
5. Describe AlphaEvolve and the Darwin Gödel Machine, and distinguish them from the harness-evolution loop.
6. Diagnose benchmark overfitting with a held-out task family, and design the measurement.
7. Analyse the credit-attribution problem and the loop’s stability, using Part 0’s framework.
8. Apply the Module 6 classification as a guardrail: which components the loop may edit and which it must not.

Everything is self-contained. Where Part 0 or a prior module is used, the result is restated.

PART A — THE OPTIMISATION PROBLEM

10.1 The search space

10.1.1 The harness as a configuration

A harness is a configuration of its components:

Definition 10.1.1 (Harness configuration). A harness configuration is a tuple $h=(c_1,\dots,c_n)$, where each $c_i\in\mathcal{C}_i$ is a component’s configuration and $\mathcal{C}_i$ is the component’s configuration space. The harness space is $\mathcal{H}\subseteq\prod_i\mathcal{C}_i$, the subset of configurations that satisfy the compatibility constraints.

The configuration spaces are structured and discrete, not continuous.

Structured. A component’s configuration is not a real number; it is a choice from a set of meaningful options. A tool schema is one of several variants; a compaction threshold is one of several values; a retry policy is one of several strategies. The structure is what makes the space tractable — the options are meaningful, not arbitrary — and it is what makes the space incommensurable with continuous optimisation (you cannot interpolate between two tool schemas).

Discrete. The configuration spaces are finite or countably infinite. The compaction threshold is an integer; the retry count is an integer; the tool schema is a finite set. The discreteness is what makes gradient-based methods inapplicable and what makes the search a combinatorial problem.

10.1.2 The size of the space

The space’s size is the product of the component spaces’ sizes:

Worked example. A harness with six editable components, each with ten options, has $10^6$ configurations. If the compatibility constraints remove half, the space is $5\times10^5$. At an evaluation cost of 100 model calls per configuration (a small task set), a full search is $5\times10^7$ calls — infeasible for most budgets. The space is too large for exhaustive search, and the methods of §10.4 are the alternatives.

10.1.3 The structure that helps

Three structural properties make the space more tractable than its size suggests.

Locality. Many components’ effects are local: a tool schema change affects the tool’s calls, not the context manager’s behaviour. A local edit’s effect is measurable on a subset of the tasks, which reduces the evaluation cost.

Sparsity. Most configurations are bad in the same way (a harness with a broken loop fails on everything). The good configurations are a small region of the space, and a search that finds the region can explore it efficiently.

Decomposability. Some components can be optimised independently (the compaction threshold and the retry policy do not interact strongly). A decomposed search — optimise one component, then another — is cheaper than the joint search, at the cost of missing the interactions.

10.2 The objective

10.2.1 The definition

The objective is the expected return on the task distribution:

where $\pi_{\theta,h}$ is the model-harness policy, $\mathcal{D}$ is the task distribution, and $R$ is the return. The objective is the same as Module 1’s $J(\pi_\theta;\mathcal{M}_H)$, with the harness $H$ made explicit as the optimisation variable.

10.2.2 The four properties

The objective has four properties, and each shapes the method.

Property 1 — Noisy. $J(h)$ is estimated from a finite sample of tasks, and the model and tools are stochastic. The estimate $\hat J(h)$ has variance, and the variance is large relative to the effects the loop is trying to detect (Module 5, §5.4). The signal-to-noise ratio is the loop’s central problem.

Property 2 — Expensive. Each evaluation is a set of model calls on a task set. The cost is the evaluation budget, and it is the binding constraint on the number of edits the loop can test.

Property 3 — Non-stationary. The objective changes over time: the model is upgraded, the task distribution shifts, the tools evolve. A configuration that was optimal at $t$ may be suboptimal at $t+1$, and the loop must track the change. The non-stationarity is the reason the loop cannot converge to a fixed optimum; it must track a moving target.

Property 4 — Partially observable. The harness’s effect on the objective is mediated by the model, and the mediation is not fully understood. An edit’s effect may be due to a mechanism the loop did not anticipate, which is why the self-declared prediction (§10.7) is a check on the mechanism, not just the outcome.

10.2.3 The estimand and the estimate

The distinction between $J(h)$ and $\hat J(h)$ is the Module 5 distinction between the estimand and the estimate. The loop optimises the estimate, but it is the estimand that matters, and the gap between them is the generalisation gap — the difference between the performance on the evaluation set and the performance on the deployment distribution.

The gap has two sources: sampling noise (the finite task set) and distribution shift (the evaluation set differs from the deployment). The first is reduced by more tasks; the second by a held-out validation set from the deployment distribution (§10.18). Both are the loop’s responsibility, and neither is eliminated by the loop’s own operation.

10.3 The constraints

10.3.1 The four constraints

The optimisation is constrained, and the constraints are not optional.

Constraint 1 — Compatibility. Some component configurations are incompatible: a tool schema with an argument type that the dispatcher does not validate; a compaction threshold that exceeds the model’s effective context; a retry policy that assumes an idempotency guarantee the tools do not provide. The compatibility constraints define $\mathcal{H}\subset\prod_i\mathcal{C}_i$, and a search that violates them produces a broken harness.

Constraint 2 — Partial revertibility. Some edits can be reverted (a prompt change, a threshold change); some cannot (a permission policy change that has already been deployed and audited; a tool removal that has broken a dependent). The revertibility determines the cost of a failed edit, and it shapes the loop’s risk posture: a loop that edits only revertible components can explore aggressively; a loop that edits irreversible components must be conservative.

Constraint 3 — Irreducible components are not editable. Module 6’s classification: the irreducible components (permissions, verification, audit) are not variables in the optimisation, because their “improvement” is not a valid objective. A permission policy that is more permissive may improve the success rate (the agent can do more), but it is not a better permission policy — it is a security regression. The irreducible components are constraints on the search, not dimensions of it.

Constraint 4 — Budget. The evaluation budget (the number of model calls) and the deployment budget (the engineering time to adopt an edit) bound the search. The loop must allocate the budget across edits, and the allocation is the exploration-exploitation trade-off.

10.3.2 The guardrail

The classification is the loop’s guardrail:

Design principle (the guardrail). The loop may edit the capability-compensating and performance-tuning components (Module 6, §6.13). It may not edit the irreducible components, and it may not remove a compensating component without the removal test of Module 6, §6.14.3.

The principle’s justification: the irreducible components are the deployment’s requirements, not the model’s scaffolding; editing them optimises the metric at the expense of the requirement. The compensating components are the loop’s legitimate target — they exist to work around the model’s weaknesses, and the loop’s job is to find the best workaround. The tuning components are the loop’s secondary target — they improve a metric without being required, and the loop can optimise them freely (subject to the compatibility constraints).

10.4 The methods

10.4.1 The four families

The search methods fall into four families, each appropriate for a different regime.

M1 — Greedy hill-climbing. Evaluate a set of single-component edits, adopt the best, repeat. Strength: simple, cheap per iteration, interpretable (each edit is a single change). Weakness: local optima (an edit that is only good in combination with another is missed), and it does not explore the interactions.

M2 — Beam search. Maintain a beam of the $k$ best configurations, expand each with single-component edits, keep the best $k$. Strength: explores more of the space than greedy, at a bounded cost. Weakness: the beam can collapse to a single lineage, and the cost is $k$ times the greedy cost.

M3 — Evolutionary search. Maintain a population, mutate and recombine, select by fitness. Strength: explores the interactions, and it is the natural fit for a structured discrete space. Weakness: the population’s evaluation cost, and the difficulty of defining a meaningful recombination for a structured harness.

M4 — LLM-proposed edits. An LLM reads the failure traces and proposes an edit. Strength: the proposals are informed by the traces, so they target the actual failures. Weakness: the proposals are not guaranteed to be valid (the compatibility constraint), and the LLM’s proposal is a hypothesis to be evaluated, not an answer.

10.4.2 The choice

The choice depends on the budget and the structure.

Small budget, local effects: greedy (M1). The per-iteration cost is low, and the local effects are measurable.

Moderate budget, some interactions: beam (M2). The beam explores the interactions at a bounded cost.

Large budget, many interactions: evolutionary (M3). The population explores the interactions, and the cost is justified by the space’s size.

Failure traces available: LLM-proposed (M4), possibly combined with M1–M3 (the LLM proposes, the search evaluates). This is the AHE approach (§10.5), and it is the one the lab uses.

10.4.3 The evaluation discipline

Whichever method, the evaluation discipline is Module 5’s, applied to each edit:

1. Pre-register the prediction (§10.7).
2. Evaluate on a sample large enough to detect the predicted effect (the power calculation, Module 5, §5.7).
3. Control the multiple comparisons (Holm or BH, Module 5, §5.6), because the loop tests many edits.
4. Validate on a held-out set (§10.18), because the evaluation set is the loop’s training set.
5. Record the outcome in the edit log, so the loop’s history is auditable.

The discipline is the difference between a self-evolution loop and a random walk. Without it, the loop adopts edits that fit the noise, and its apparent improvement is an artefact of the evaluation.

PART B — AGENTIC HARNESS ENGINEERING

10.5 The three observability pillars

10.5.1 The claim

Agentic Harness Engineering (AHE; arXiv:2604.25850, evidence tier P: preprint, single-lab, unreplicated) proposes that a harness can be improved automatically if it is observable at three levels, and that the three levels are the minimum for a closed loop.

Pillar 1 — Component observability. For each behaviour, which component produced it? The trace records the loop’s step, the tool’s call, the context manager’s decision, the policy engine’s verdict, so that a behaviour can be attributed to a component.

Pillar 2 — Experience observability. What was the run’s trajectory, and how did it feel to the agent? The trace records the sequence of states, the observations, the actions, and the outcomes, so that the failure can be understood in context, not just as a final verdict.

Pillar 3 — Decision observability. Why did the agent make each decision? The trace records the model’s reasoning (the ReAct trace, Module 4), the context it saw, and the alternatives it did not take, so that the decision can be attributed to a cause.

10.5.2 Why each is necessary

The three pillars are necessary for the loop’s three functions.

Component observability is necessary for attribution. The loop’s question is “which component should be edited?” Without component observability, the loop knows the run failed but not which component caused the failure. The edit is a guess.

Experience observability is necessary for diagnosis. The loop’s question is “why did the component fail?” Without experience observability, the loop knows the component failed but not in which context, on which task, with which observation. The edit is a guess at the mechanism.

Decision observability is necessary for credit assignment. The loop’s question is “was the failure the component’s fault, or the model’s?” Without decision observability, the loop cannot distinguish a component that failed because it was wrong from a component that failed because the model misused it. The edit may target the wrong component.

10.5.3 The pillars and Module 11

The three pillars are the AHE paper’s specification of what a trace must contain to support the loop. They are the same requirements Module 11 develops for general observability, applied to the loop’s specific needs. The connection: Module 11’s trace schema is the AHE pillars’ implementation, and the loop’s observability is a special case of the harness’s observability.

10.6 The closed evolution loop

10.6.1 The loop

The AHE loop has six steps.

Step 1 — Observe. Collect the failure traces (the three pillars).

Step 2 — Propose. An LLM reads the traces and proposes an edit: which component, what change, and why.

Step 3 — Predict. The proposer declares the expected effect: which metric, which direction, and (optionally) how much.

Step 4 — Evaluate. Run the edit on the evaluation set, with the Module 5 discipline.

Step 5 — Verify. Compare the observed effect to the declared prediction. If the prediction is confirmed and the effect is significant, accept; if not, reject.

Step 6 — Record. Log the edit, its prediction, its outcome, and the accept/reject decision, so the loop’s history is auditable and the next iteration can learn from it.

The loop is closed because the observation feeds the proposal, and the verification feeds the next observation. It is a feedback loop in the control-theoretic sense (Part 0, §0.7), and its stability is the subject of §10.20.

10.6.2 The loop as a control system

The loop is the harness-evolution loop of Part 0, §0.7, made concrete:

The mapping is exact, and the stability analysis of Part 0, Proposition 0.7.7 applies: the loop converges if the step size is small relative to the sensitivity and the delay, and the steady-state error is proportional to the noise.

10.7 The self-declared prediction

10.7.1 What it is

The self-declared prediction is the proposer’s statement, before the evaluation, of the expected effect:

Definition 10.7.1 (Self-declared prediction). A self-declared prediction is a tuple $(\mu_p, \delta_p, \text{metric})$, where $\mu_p$ is the predicted direction (increase, decrease, no change), $\delta_p$ is the predicted magnitude (an interval, or a point), and the metric is the quantity the effect is predicted on.

The prediction is made by the same model that proposes the edit, before the evaluation, and it is recorded in the edit log. The evaluation is compared to the prediction in Step 5.

10.7.2 Why the prediction is a variance-reduction device

The prediction’s value is statistical, and it is worth stating precisely.

Reason 1 — It converts a two-sided test to a one-sided test. Without a prediction, the loop asks “did the metric change?” — a two-sided question. With a prediction, the loop asks “did the metric change in the predicted direction?” — a one-sided question. The one-sided test has more power for the same sample size (the critical value is lower), so the loop can detect a smaller effect with the same budget.

Reason 2 — It eliminates post-hoc selection. Without a prediction, the loop’s analyst (or the loop itself) can choose the direction after seeing the data, which inflates the false-positive rate (Module 5, §5.10). With a prediction, the direction is fixed before the data, and the false-positive rate is controlled.

Reason 3 — It checks the mechanism. The prediction is not just a direction; it is a claim about why the edit should work. If the prediction is wrong, the mechanism is wrong (or the effect is noise), and the loop learns something: the edit’s rationale is not the mechanism it thought. This is the prediction’s diagnostic value, and it is more important than its statistical value.

10.7.3 The prediction’s failure modes

The prediction can fail in three ways, and each is informative.

Overconfidence. The prediction is a precise magnitude, and the observed effect is far from it. The mechanism is wrong or the effect is noise. The loop should not accept the edit (the prediction’s magnitude is a check on the effect’s plausibility).

Underconfidence. The prediction is vague (“some improvement”), and any positive effect confirms it. The prediction provides no check. The loop should require a minimum precision (a direction and an interval), and reject vague predictions.

Post-hoc rationalisation. The prediction is made after the evaluation, disguised as before. The log’s timestamps are the check; a prediction that is recorded after the evaluation is not a prediction.

10.7.4 The prediction and McDiarmid

The prediction interacts with the minimal-edit discipline (Module 6, §6.14, and Part 0, §0.1). A minimal edit (a single component, a small change) has a bounded effect (McDiarmid, Part 0, Theorem 0.1.6), so the prediction’s magnitude is constrained. A large edit (many components, a big change) has an unbounded effect, and the prediction is uninformative. The minimality is what makes the prediction a check: a minimal edit’s effect should be small, and a large observed effect is a signal that something else changed.

10.8 The reported result and its status

10.8.1 The result

The AHE paper reports a Terminal-Bench 2 pass@1 improvement from 69.7% to 77.0% — a 7.3-point improvement — from the loop’s edits, at fixed model.

10.8.2 The status

The result is tier P, status P:

• Single-lab. One group’s result, not independently reproduced.
• Preprint. Not peer-reviewed.
• Methodology partially inspectable. The loop is described, but the evaluation details (the task set, the seeds, the multiple-comparison strategy) are not fully reported.
• The effect is large. A 7.3-point improvement is well above the noise of a typical benchmark (Module 5, §5.7), so it is plausible; the question is whether it replicates.

10.8.3 The questions a rigorous reader asks

The four questions of Module 4, §4.11.2, adapted:

1. What is the confidence interval on the 7.3 points? Not reported; the effect’s precision is unknown.
2. What task distribution was used, and is the improvement on a held-out family? The evaluation set is Terminal-Bench 2; the held-out validation is not reported.
3. Is the improvement pass@1 or best-of-k? Pass@1 is reported; the reliability (pass^k) is not.
4. Has it been independently reproduced? No; the status is P.

The result is a well-founded hypothesis: the effect is large, the mechanism is plausible, and the methodology is described. It is not an established fact, and the lab’s replication (at the learner’s scale) is the test.

10.9 The evidence and the limits

10.9.1 The descriptive findings

The descriptive findings — the three pillars, the six-step loop, the self-declared prediction — are methodologically sound: they are a coherent design, and they are consistent with the curriculum’s own analysis (the three pillars are Module 11’s trace requirements; the loop is Part 0’s control loop; the prediction is Module 5’s pre-registration). The description is a contribution independent of the result.

10.9.2 The inferential findings

The inferential finding — the loop improves the harness by 7.3 points — is a hypothesis. It may be true, it may be specific to Terminal-Bench 2, and it may not replicate. The curriculum treats it as a hypothesis to be tested, not a result to be applied.

10.9.3 The limits

Three limits, each worth stating.

Limit 1 — Coding-only. The result is on a coding benchmark. The transfer to other domains is a hypothesis.

Limit 2 — Single model. The result is at fixed model, and the loop’s edits are tuned to that model. The transfer to a different model is a hypothesis (Module 14’s co-adaptation problem).

Limit 3 — The loop’s cost. The result does not report the loop’s evaluation cost (the number of edits tested, the model calls per edit). The cost is the loop’s viability condition: a loop that costs more than a human’s time is not worth it, regardless of the improvement.

PART C — SELF-HARNESS AND HARNESS-ZERO

10.10 Self-Harness

10.10.1 The three mechanisms

Self-Harness (described in the awesome-harness-engineering index; read the primary paper, tier P) proposes three mechanisms for harness improvement.

Mechanism 1 — Failure-trace mining. The failures are clustered (by the failure taxonomy of Module 11), and the largest cluster is the target. The clustering is the prioritisation: the loop addresses the most common failure first, not the most interesting one.

Mechanism 2 — Minimal edits. The edit is the smallest change that addresses the cluster: one component, one parameter, one rule. The minimality is the McDiarmid discipline (Part 0, §0.1): a small edit on a large evaluation is estimable, and its effect is attributable.

Mechanism 3 — Regression validation. The edit is tested against the full suite, not just the targeted cluster, to ensure it does not break the other clusters. The regression validation is the guard against the edit’s side effects.

10.10.2 The connection to the curriculum

The three mechanisms are the curriculum’s own principles, applied to the loop:

• Failure-trace mining is Module 11’s trace analysis (§11.5) and Module 5’s error analysis.
• Minimal edits are Module 6’s addition obligation (Proposition 6.7.1) and Part 0’s McDiarmid bound.
• Regression validation is Module 5’s held-out validation (§5.11.2) and Module 7’s verification loop.

The Self-Harness paper’s contribution is the combination: the loop’s discipline is the curriculum’s discipline, applied iteratively. The mechanism is sound; the empirical claim (that the combination improves the harness) is tier P and awaits replication.

10.11 Harness-Zero

10.11.1 The mechanism

Harness-Zero (described in the index; read the primary paper, tier P) proposes harness distillation into a student model: the harness’s behaviour is captured as SFT demonstrations (the trajectories the harness produces), and a student model is trained on them. The student internalises the harness’s behaviour, so it needs less scaffolding — the compensating components (Module 6, §6.13.2) are “distilled into” the model.

10.11.2 The connection to the classification

Harness-Zero is the compensating-component removal via training. The classification says the compensating components exist because the model is weak; Harness-Zero makes the model stronger on the specific behaviour, and the components become unnecessary. It is the training-based version of the removal protocol (Module 6, §6.14.3).

The mechanism is the same as Module 15’s trajectory SFT (§15.4), applied to the harness’s own behaviour: the trajectories are the demonstrations, and the student is the model that learns them. The difference is the purpose: Module 15’s SFT improves the model’s task performance; Harness-Zero’s SFT removes the harness’s scaffolding.

10.11.3 The evidence status and the risk

The status is P (single-lab, unreplicated). The risk is the one Module 16’s reward hacking raises: a student trained on the harness’s demonstrations learns the harness’s behaviour, including its exploits. If the harness has a verifier exploit (Module 5, §5.13), the student learns the exploit, and the distillation amplifies it. The audit is the defence: the demonstrations are filtered by the verifier’s audit, and the student’s behaviour is tested for the exploits.

10.12 The connection to the classification

10.12.1 What the loop may edit

The guardrail (§10.3.2) is the classification. In practice:

The table is the loop’s permission. A loop that edits an irreducible component is a loop that has lost the guardrail, and its “improvement” is a security or governance regression.

10.12.2 What the loop may remove

The loop may remove a compensating component, but only with the removal test (Module 6, §6.14.3): the component is absent, the evaluation shows no degradation, and the removal is recorded. The loop’s proposals can include removals (the classification’s removal condition), and the removal test is the verification.

10.13 The evidence status of the two mechanisms

10.13.1 The status

Both Self-Harness and Harness-Zero are tier P, status P: single-lab, unreplicated, partially inspectable. The mechanisms are sound (they are the curriculum’s principles), but the empirical claims (that they improve the harness, that the distillation works) are hypotheses.

10.13.2 The test

The lab’s loop is the test at the learner’s scale: the Self-Harness mechanisms (failure-trace mining, minimal edits, regression validation) are the lab’s design, and the lab’s result is the replication attempt. The Harness-Zero distillation is a Module 15/16 extension (the training-based removal), and it is out of the lab’s scope but within the curriculum’s.

PART D — EVOLUTIONARY AND SELF-IMPROVING SYSTEMS

10.14 AlphaEvolve

10.14.1 The mechanism

AlphaEvolve (arXiv:2506.13131, tier P) is an evolutionary coding agent: a population of programs, an LLM that proposes mutations (edits), an evaluator that scores each program, and a selection that keeps the best. The loop is the evolutionary loop (M3, §10.4.1), with the LLM as the mutation operator.

10.14.2 The connection

The connection to the harness loop is direct: the harness is a program, the edits are the mutations, the evaluation is the fitness. AlphaEvolve is the evolutionary version of the AHE loop, and the AHE loop is the trace-informed version of AlphaEvolve. The two differ in the proposal’s source (the LLM reads the traces vs the LLM mutates the code) and the population (a single harness vs a population), but the structure is the same.

10.14.3 The difference that matters

The difference is the proposal’s grounding. AlphaEvolve’s mutations are code edits proposed by an LLM, without the failure traces; the AHE loop’s edits are proposed after reading the traces, so they are grounded in the failures. The grounding is the AHE loop’s advantage, and it is why the three pillars (§10.5) matter: the traces are what make the proposal informed rather than random.

10.15 The Darwin Gödel Machine

10.15.1 The mechanism

The Darwin Gödel Machine (arXiv:2505.22954, tier P) is a self-improving agent that modifies its own code. It maintains a population of agent variants, each variant is a modified version of the agent’s code, and the variants are evaluated and selected. The “Gödel” in the name is the self-reference: the agent’s code includes the mechanism that modifies the code.

10.15.2 The connection

The connection is the self-modification: the harness is the agent’s code, and the self-modification is the harness evolution. The Darwin Gödel Machine is the code-level version of the harness loop, and it is the most aggressive form: the loop edits the harness’s source, not just its configuration.

10.15.3 The safety question

The self-modification raises the safety question the other mechanisms do not: if the agent edits its own code, what constrains the edits? The Darwin Gödel Machine’s answer is the population and the evaluation: a variant that is worse is not selected. But the evaluation is the verifier, and a variant that games the verifier (Module 5, §5.13; Module 16) is selected even though it is worse. The self-modification amplifies the reward-hacking risk, because the agent can edit the parts of the harness that constrain it.

The guardrail (§10.3.2) is the answer: the irreducible components (the permissions, the verifier, the audit) are not editable, and the self-modification is confined to the compensating and tuning components. The Darwin Gödel Machine’s design does not, as described, include this guardrail, and the curriculum’s posture is that the guardrail is necessary for a self-modifying system to be safe.

10.16 The connections and the differences

10.16.1 The family

The four systems are a family, with a common structure and different scopes.

The common structure: observe → propose → evaluate → select. The differences: the proposal’s grounding (traces vs mutation), the population (single vs many), and the scope (configuration vs code).

10.16.2 The curriculum’s posture

The curriculum’s posture toward the family is the same as toward the individual systems: the mechanisms are sound, the results are hypotheses, and the guardrail is necessary. The loop is a tool; the discipline (Module 5’s evaluation, Module 6’s classification, Part 0’s stability) is what makes the tool safe.

10.17 The safety question, generalised

10.17.1 The three risks

The self-evolution family raises three risks, and each has a guardrail.

Risk 1 — Verifier gaming. The loop optimises the verifier, not the task (Module 5, §5.13; Module 16, §16.7). Guardrail: the verifier’s audit (the exploit list, the exploit rate, the corrected score), and the held-out verification.

Risk 2 — Irreducible-component editing. The loop edits the permissions, the audit, the verification, and its “improvement” is a security regression. Guardrail: the classification’s guardrail (§10.3.2).

Risk 3 — Runaway self-modification. The loop edits its own editing mechanism, and the edits compound without bound. Guardrail: the stability analysis (Part 0, §0.7; §10.20), and the confinement of the edits to the compensating and tuning components.

10.17.2 The principle

The three risks’ common form is the Goodhart risk (Module 9, §9.15): the metric is gamed when it becomes a target. The loop’s metric (the task success) is a target, and the loop’s edits can game it. The guardrail is the basket of metrics (the success, the verifier’s audit, the violation count, the stability margin) and the held-out validation (the metric on a distribution the loop does not optimise).

The principle: a self-evolution loop is only as safe as its evaluation. The loop’s edits are as good as the metric they optimise, and the metric is only as good as the discipline that measures it. The discipline is Module 5’s, applied to the loop.

PART E — FAILURE MODES AND THE STABILITY OF THE LOOP

10.18 Overfitting to the benchmark

10.18.1 The mechanism

The loop optimises $\hat J(h)$ on the evaluation set. If the evaluation set is the only measure, the loop can improve $\hat J$ without improving $J$ — the generalisation gap (§10.2.3). The loop finds edits that fit the evaluation set’s idiosyncrasies: the specific tasks, the specific model, the specific seeds.

10.18.2 The held-out task family

The defence is the held-out task family (Module 5, §5.11.2): a set of tasks from the deployment distribution that the loop does not optimise on. The loop’s edits are validated on the held-out family, and an edit that improves the evaluation set but not the held-out family is overfit.

Definition 10.18.1 (Overfitting). An edit overfits if its effect on the held-out family is smaller than its effect on the evaluation set by more than the sampling noise. Formally, the edit overfits if

where $\hat\Delta$ is the estimated effect on each set.

10.18.3 The measurement

The measurement is a comparison of the edit’s effect on the two sets, with the Module 5 discipline (paired bootstrap, confidence intervals). The expected result: the held-out effect is smaller than the evaluation effect by a shrinkage factor that depends on how much the loop has overfit. A loop that has not overfit has a shrinkage near 1; a loop that has overfit has a shrinkage near 0.

10.18.4 The design implication

The held-out family is not the deployment set (the deployment is the final test); it is a validation set, used to select the edits, and the deployment is the test set, used once. The split is the Module 5 train/validation/test split, applied to the loop:

• Evaluation set: the loop’s training set (the edits are proposed and evaluated on it).
• Held-out family: the loop’s validation set (the edits are validated on it, and the overfit ones are rejected).
• Deployment: the test set (the final measure, used once).

10.19 Credit attribution

10.19.1 The problem

The loop tests many edits, and the effects are noisy and interacting. The credit-attribution problem is: given an observed improvement, which edit caused it?

The problem’s four sources:

• Sampling noise. The effect may be noise (Module 5, §5.4).
• Multiple comparisons. The loop tests many edits, and some will appear significant by chance (Module 5, §5.6).
• Interactions. An edit’s effect depends on the other edits in the harness.
• Non-stationarity. The model or the task distribution may have changed between the edits, confounding the effect.

10.19.2 The prediction’s role

The self-declared prediction (§10.7) is the credit-attribution device. The prediction is a pre-registered hypothesis about the edit’s mechanism, and the evaluation tests it. A confirmed prediction is evidence that the edit caused the effect (the mechanism is the one the proposer thought); an unconfirmed prediction is evidence that the effect is noise or the mechanism is wrong.

The prediction does not eliminate the problem — a confirmed prediction can still be a coincidence, and the multiple-comparison correction is still needed — but it reduces it: the prediction is a one-sided test with a mechanism check, and it is the best the loop can do with a noisy, expensive evaluation.

10.19.3 The minimal-edit discipline

The minimal edit (Self-Harness, §10.10) is the second credit-attribution device. A minimal edit (one component, one change) has a bounded effect (McDiarmid), so the credit is attributable: the effect is the edit’s, not a confound’s. A large edit (many components) has an unbounded effect, and the credit is not attributable.

The two devices — the prediction and the minimality — are the loop’s credit-attribution discipline, and they are the reason the loop’s edits are interpretable, not just effective.

10.20 The stability of the loop

10.20.1 The formal statement

Restating Part 0, Proposition 0.7.7: the loop

converges in mean square if $0<\eta<2/(L(1+2d))$, where $L$ is the sensitivity, $d$ is the delay, and the steady-state error is of order $\eta\sigma^2/(2n)$.

10.20.2 The four levers

The stability condition gives four levers, each of which the loop can use.

Lever 1 — Smaller steps ($\eta$). Smaller edits are more stable. The minimal-edit discipline is the lever’s implementation.

Lever 2 — More evaluation ($n$). More tasks per edit reduce the noise, which reduces the steady-state error. The evaluation budget is the lever.

Lever 3 — Shorter delay ($d$). Faster evaluation (a smaller task set, a faster model) reduces the delay, which loosens the stability bound. The trade-off: a smaller task set is noisier, so levers 2 and 3 conflict, and the optimum is the balance.

Lever 4 — Damping. The held-out validation (§10.18) is a damping mechanism: it prevents the loop from chasing the evaluation set’s noise, because an edit that does not transfer is rejected. The damping is the feedback that keeps the loop from overfitting.

10.20.3 The oscillation failure

A loop that violates the stability condition oscillates: it adopts an edit, the metric improves, it adopts the reverse edit, the metric improves again, and the loop cycles. The oscillation is not a bug in the loop’s logic; it is a dynamic instability, and the remedy is the levers (smaller steps, more evaluation, shorter delay, damping).

The oscillation is detectable: the edit log shows the same component edited in opposite directions, and the metric oscillates with the edits. The diagnostic is the edit log’s pattern, and the fix is the levers.

10.21 The guardrails

10.21.1 The four guardrails

The module’s guardrails are the four disciplines that make the loop safe.

Guardrail 1 — The classification. The loop may edit the compensating and tuning components, not the irreducible ones (§10.3.2).

Guardrail 2 — The evaluation discipline. Every edit is pre-registered, evaluated with the Module 5 statistics, and corrected for multiple comparisons (§10.4.3).

Guardrail 3 — The held-out validation. Every edit is validated on a held-out family, and the overfit ones are rejected (§10.18).

Guardrail 4 — The stability analysis. The loop’s step size, noise, and delay are analysed, and the loop is stable (§10.20).

The four guardrails are the loop’s constitution: they are not optional, and a loop without them is not a self-evolution loop; it is a random walk with a metric.

10.21.2 The guardrails’ cost

The guardrails are not free. The evaluation discipline costs the multiple-comparison correction (a larger sample size); the held-out validation costs a separate task set; the stability analysis costs the analysis time. The costs are real, and the loop’s benefit must exceed them (the loop’s cost-benefit analysis, §10.9.3).

The guardrails’ benefit is the loop’s validity: a loop without them produces edits that look good and are not, and the cost of a bad edit (a regression, a security issue) is larger than the guardrails’ cost.

10.22 The research questions

10.22.1 The open questions

The module raises questions the curriculum cannot answer, and they are the research agenda.

Question 1 — Does the loop’s improvement transfer? The AHE result is on Terminal-Bench 2, at a single model. Does the loop’s improvement transfer to a different benchmark, a different model, a different domain? The held-out validation is the test, and the question is whether the transfer is the rule or the exception.

Question 2 — What is the loop’s cost-benefit? The loop’s evaluation cost (the edits tested, the model calls) is not reported in the papers. Is the loop cheaper than a human’s time? The question is the loop’s viability, and it is unanswered.

Question 3 — How does the loop interact with the model’s evolution? The loop’s edits are tuned to the current model. When the model is upgraded, the edits may be stale. Does the loop re-optimise, and at what cost? The question is the loop’s maintenance, and it is the Module 6 classification’s removal condition, applied to the loop’s edits.

Question 4 — Can the guardrails be automated? The guardrails are human disciplines. Can they be built into the loop (the classification as a constraint, the evaluation as a pre-registered plan, the validation as a gate)? The question is the loop’s reliability, and it is the difference between a research prototype and a production system.

10.22.2 The connection to Module 14b

Module 14b (Harness–Model Co-evolution) asks the learner to design a longitudinal experiment for one of these questions. Module 10 is the foundation: the loop’s mechanisms, the guardrails, and the questions. The experiment is the test.

LAB 10 — SPECIFY AND RUN A HARNESS-EVOLUTION LOOP

10.23.1 Task specification

Take the harness you have built (Lab 1a, extended by Labs 2–9) and specify a harness-evolution loop that proposes, evaluates, and accepts edits. The loop must be runnable: the specification must be precise enough that another engineer could implement it, and the run must produce an edit log with the accepted and rejected edits.

10.23.2 The loop’s specification

The specification must include the six steps of §10.6, adapted to your harness:

1. Observe. The trace schema (the three pillars, §10.5) and the failure-clustering method.
2. Propose. The proposal mechanism (the LLM reading the traces, or the Self-Harness mining), the edit’s scope (which components, §10.3.2’s guardrail).
3. Predict. The self-declared prediction (§10.7), with a direction, an interval, and a mechanism.
4. Evaluate. The evaluation set, the power calculation, the multiple-comparison correction.
5. Verify. The prediction check and the significance test.
6. Record. The edit log (the fields below).

10.23.3 The edit log

The edit log is the loop’s audit trail. Each entry has:

The log is the loop’s memory. The outcome field is the one most often omitted and the most important: the edit’s effect over time, after the deployment, is the evidence that the edit was good, and it is the input to the next iteration.

10.23.4 The held-out validation

The held-out family is a task set from the deployment distribution that the loop does not optimise on. It must be:

• Disjoint from the evaluation set (no task appears in both).
• Representative of the deployment distribution (not a skewed sample).
• Sufficiently large for the power calculation (the effect’s detection at the held-out level).

The overfitting check (§10.18) is the comparison of the edit’s effect on the two sets, and the shrinkage factor is reported.

10.23.5 The stability analysis

The stability analysis (§10.20) must state:

• The step size $\eta$: the edit’s scope (one component, one parameter, or a suite).
• The sensitivity $L$: the edit’s effect on the metric per unit of edit strength (estimated from prior edits, or bounded).
• The delay $d$: the evaluation’s wall-clock time plus the deployment’s adoption time.
• The margin $M_s=2/(L(1+2d)\eta)$: the loop’s stability.

The margin should be $>1$, and a margin $<1$ requires a smaller step or a shorter delay.

10.23.6 The metrics

10.23.7 The hypotheses

State before running:

• H1. The loop’s accepted edits improve the harness’s metric by more than the loop’s cost, on the held-out family.
• H2. The prediction accuracy is above chance (the proposer’s mechanism is informative).
• H3. The held-out shrinkage is between 0.5 and 1.0 (the loop’s edits transfer, but with some overfitting).
• H4. The stability margin is $>1$ (the loop is stable).
• H5. The loop’s edits are concentrated in the compensating components (the guardrail holds).

10.23.8 The acceptance criteria

10.23.9 What good looks like

A good lab report has five properties.

It runs the loop, not just specifies it. The specification is necessary but not sufficient; the run is the evidence. The report includes the edit log from an actual run, with the accepted and rejected edits.

It reports the prediction accuracy. The prediction’s accuracy is the loop’s mechanism check: if the predictions are no better than chance, the proposer’s mechanism is not informative, and the loop is a random search with extra steps.

It reports the shrinkage. The held-out shrinkage is the overfitting measure: a shrinkage near 1 means the edits transfer; a shrinkage near 0 means the loop has overfit. The shrinkage is the loop’s validity, and it is the most important number in the report.

It reports the stability margin. The margin is the loop’s stability: a margin $<1$ means the loop is oscillating, and the report should say so, even if the edits look good.

It reports the loop’s cost. The loop’s cost is the viability condition: a loop that costs more than the improvement is not worth it, and the report should say so.

MODULE 10 CHEAT SHEET

EXERCISES WITH SOLUTIONS

E10.1. A harness has five editable components, each with eight options, and the compatibility constraints remove 25% of the joint configurations. What is the size of the search space? If each configuration costs 200 model calls, what is the exhaustive search’s cost?

S10.1. $8^5=32{,}768$; after the constraints, $0.75\times32{,}768=24{,}576$. Exhaustive search: $24{,}576\times200=4{,}915{,}200$ model calls. The space is too large for exhaustive search at a feasible budget, which is why the methods of §10.4 (greedy, beam, evolutionary, LLM-proposed) are needed.

E10.2. An edit’s evaluation on 100 tasks shows a 6-point improvement with a standard error of 3 points. The prediction was a 4-point improvement. Is the prediction confirmed, and is the edit accepted?

S10.2. The 6-point estimate is $6/3=2.0$ standard errors from zero, $p\approx0.046$ two-sided, $p\approx0.023$ one-sided — significant at the 5% level (one-sided). The prediction was 4 points, and the estimate’s 95% CI is $6\pm1.96\times3=[0.1,11.9]$, which contains 4. The prediction’s direction is confirmed, and its magnitude is consistent (the CI contains it). The edit is accepted, subject to the held-out validation and the multiple-comparison correction. Note: the 100-task evaluation is underpowered for a 4-point effect (Module 5, §5.7), so the acceptance is provisional, and the held-out validation is the check.

E10.3. The same edit improves the evaluation set by 6 points and the held-out family by 2 points, with a standard error of 2 points on the difference. Is the edit overfit?

S10.3. The difference is $6-2=4$ points, with $\mathrm{SE}=2$, so $z=2.0$, $p\approx0.046$. The held-out effect is significantly smaller than the evaluation effect, so the edit is overfit (Definition 10.18.1): the shrinkage is $2/6=0.33$, i.e. only a third of the effect transfers. The edit should be rejected (or revised): the evaluation’s 6 points is mostly the evaluation set’s idiosyncrasy, and the deployment’s effect is closer to 2 points. The lesson: the held-out validation is the loop’s validity check, and a shrinkage of 0.33 is a signal that the loop is overfitting.

E10.4. A loop’s edits have a sensitivity $L=0.4$, a delay $d=2$, and a step size $\eta=1.5$. Compute the stability margin. Is the loop stable?

S10.4. Bound $=2/(L(1+2d))=2/(0.4\times5)=2/2=1.0$. Margin $=1.0/1.5=0.67<1$. The loop is unstable: the step size exceeds the stability bound, and the loop will oscillate. The fix: reduce the step size to $\eta<1.0$ (e.g., $\eta=0.5$, margin 2.0), or reduce the delay, or increase the evaluation (which reduces the noise, though not the bound directly). The margin is the loop’s stability, and a margin $<1$ is a loop that needs a smaller step.

E10.5. A loop’s edit log shows that it edited the permission policy to allow a broader command allowlist, and the success rate improved by 5 points. What is wrong with this edit?

S10.5. The edit violates the guardrail (§10.3.2): the permission policy is an irreducible component (Module 6), and the loop may not edit it. The 5-point improvement is real, but it is a security regression disguised as an improvement: the broader allowlist lets the agent do more, including actions the policy was designed to prevent. The edit should be reverted, and the loop’s proposal mechanism should be constrained to the compensating and tuning components. The lesson: the guardrail is not optional, and an edit that improves the metric by weakening a requirement is not an improvement.

E10.6. A loop’s prediction accuracy is 55% (barely above chance). What does this tell you about the loop’s proposal mechanism, and what would you do?

S10.6. The prediction accuracy of 55% is barely above chance, which suggests the proposer’s mechanism is not informative: the predictions are not much better than random, so the proposer’s rationale is not the mechanism it thinks. The loop is still effective (the evaluation selects the good edits), but the predictions are not providing the variance reduction or the mechanism check they are supposed to. The action: (1) improve the traces (the three pillars, §10.5) so the proposer has better information; (2) check whether the proposer is reading the traces or guessing; (3) consider a different proposal mechanism (the Self-Harness mining, §10.10) that is grounded in the failure clusters. The prediction accuracy is the loop’s diagnostic, and a low accuracy is a signal that the loop’s proposals are not grounded.

E10.7. A loop’s accepted edits improve the evaluation set by 12 points, but the deployment’s improvement is only 2 points. What are the possible explanations, and how would you distinguish them?

S10.7. Three explanations: (1) overfitting (the held-out shrinkage is low, §10.18); (2) distribution shift (the deployment distribution differs from the evaluation and held-out families, so the edits’ effects do not transfer); (3) the deployment’s confounds (the deployment has other changes, or the measurement is different). To distinguish: (1) compute the held-out shrinkage; if it is low, the explanation is overfitting; (2) compare the held-out family’s distribution to the deployment’s, and check whether the edits’ effects are conditional on the tasks (the edits that worked on the evaluation set may be specific to its tasks); (3) check the deployment’s measurement (the same verifier, the same task distribution). The lesson: the deployment is the test set, and a gap between the validation and the deployment is the signal that the loop’s evaluation is not representative.

E10.8. A loop’s edits are all in the compensating components, and the harness’s model is upgraded. What should the loop do with the edits?

S10.8. The edits are candidates for re-evaluation: the compensating components exist because of the model’s weaknesses, and the model upgrade may have removed the weakness, so the edits may no longer be necessary (Module 6, §6.14.3’s removal condition). The loop should: (1) re-run the removal test for each edit (the edit absent, the evaluation on the new model); (2) if the edit’s benefit has vanished, remove it (the classification’s compensating component, removed); (3) if the edit’s benefit persists, keep it (the weakness it addresses is still present). The re-evaluation is the loop’s maintenance, and the model upgrade is the trigger. The lesson: the loop’s edits are not permanent; they are conditioned on the model, and the model’s evolution is the removal condition.

EXIT TEST FOR MODULE 10

You are ready for Module 11 when you can, without notes:

1. Define the harness configuration and the search space’s structure (structured, discrete, too large for exhaustive search).
2. State the objective’s four properties and the generalisation gap’s two sources.
3. State the four constraints and the guardrail.
4. Name the four method families and choose among them by the budget and the structure.
5. State the three observability pillars and why each is necessary.
6. Describe the six-step loop and its control-theoretic mapping.
7. Define the self-declared prediction and explain its three variance-reduction reasons.
8. State the AHE result, its status, and its three limits.
9. Describe Self-Harness’s three mechanisms and Harness-Zero’s distillation, with their status.
10. Describe AlphaEvolve and the Darwin Gödel Machine, and distinguish them from the harness loop.
11. State the three risks of self-evolution and the four guardrails.
12. Define overfitting, state the held-out validation, and compute the shrinkage.
13. State the credit-attribution problem and the two devices.
14. State the stability condition, the four levers, and the oscillation’s diagnosis.
15. State the four research questions.

End of Module 10. Say “next” to receive Module 11 in full.