PaperlayerView exact revision on arXiv

Source-linked AI summary

Harness^2: Recursive Agent Harnessing for an Open World

Ruiyao Xu, Yanfei Chen, Zhongying CuiZhu, Bhavana Dalvi Mishra, Yifei Ming, Han Yu, Rujun Han, Chen-Yu Lee, Tomas Pfister

arXiv:2610.14224v1cs.AIcs.CLcs.LG

TL;DR

Open-world harness evolution faces missing reliable verifiers and difficulty carrying task-specific improvements to future tasks. Harness2 refines current-task harnesses through contrastive recursion and retains refinement experience for later tasks. Across three benchmarks and four configurations, it consistently improves base configurations, with gains up to 11.5 points on WorkBuddy-Bench.

  • Problem

    Open-world tasks lack reliable verifiers for guiding harness edits, and task-specific refinement does not automatically improve how future tasks are refined.

    Source: §1 · p. 2

  • Method

    Harness2 uses contrastive task-level Propose–Probe–Compose recursion to refine a current harness, then updates a continual improvement harness with reusable refinement experience.

    Source: §1 · p. 2

  • Results

    Across three professional benchmarks and four configurations, Harness2 consistently improves base configurations, with one-step gains up to 11.5 points on WorkBuddy-Bench, 4.5 on JobBench, and 11.8 percentage points in LAB Partial pass rate.

    Source: §1 · p. 3, §6 · p. 13

  • Takeaways & Limitations

    Task-level exploration can support future harness edits: larger-budget libraries improve later edits without more probing, and a JobBench library improves WorkBuddy-Bench performance.

    Source: §1 · p. 3

    Execution-based feedback and model judgment remain sensitive to execution variability and shared model biases, and do not guarantee correctness or transfer to another task.

    Source: F. Limitations · p. 29

Abstract

from arXiv · show

LLM agents' capabilities depend not only on their underlying models but also on their execution harnesses. Recursive self-improvement (RSI) offers a promising approach to automatically evolve these harnesses. However, deploying RSI in open-world settings still faces two critical challenges. First, open-world tasks are typically unseen during the harness design phase and novel at test time, leaving no ground-truth verifiers to reliably guide online harness edits. Second, the RSI process remains highly task-specific and fails to generalize to novel scenarios. We introduce Harness^2, a plug-and-play, recursive agent harnessing framework that addresses these challenges through two connected levels of recursion. Task-level recursion refines the current task's harness using a contrastive Propose-Probe-Compose step that reliably guides edits without ground-truth verifiers, and can be scaled further via parallel or sequential recursion. Harnessing-level recursion then extracts experience from these edits to update a continual improvement harness, enabling the agent to better adapt to future tasks. Across three professional benchmarks and four model-harness configurations, a single step consistently improves GLM-5 and Gemini 3.5 Flash over their base harnesses, yielding gains of up to 11.5 points on WorkBuddy-Bench, 4.5 points on JobBench, and 11.8 percentage points on LAB, with further gains as the task-level recursion budget increases.

1. Introduction

Agent effectiveness depends on both the model and its harness, while open-world harness evolution must cope with unseen tasks and missing verifiers. Harness2 asks whether recursive self-improvement can refine the current harness and improve how future harnesses are refined.

1. Introduction

  • The framework is motivated by harnesses shaping agent effectiveness and by the repeated engineering effort required to meet diverse task and operational demands.Source: §1 · pp. 1–2
  • Prior harness RSI either optimizes fixed tasks before deployment or adapts per task, but open-world tasks lack reliable verifiers and task-specific edits may not generalize.Source: §1 · p. 2
  • Harness2 couples task-level refinement through contrastive Propose–Probe–Compose with harnessing-level updates that retain reusable lessons for future refinement.Source: §1 · pp. 2–3
  • Harness2 evaluates recursive harnessing across three professional benchmarks and four executor–harness configurations, including cases where one model serves as executor and editor.Source: §1 · pp. 2–3
  • One contrastive step improves all three benchmarks in every configuration, with gains up to 11.5 points on WorkBuddy-Bench, 4.5 points on JobBench, and 11.8 percentage points in LAB Partial pass rate.Source: §1 · p. 3

2. Harness2

Harness2 couples task-level execution-harness refinement with across-task updates to the improvement harness. It supports contrastive, parallel, and sequential refinement, then retains adopted harnesses and supported lessons for later tasks.

2.1. Recursive Agent Harnessing

  • With model weights frozen, recursive agent harnessing couples task-level execution-harness refinement to cross-task improvement-harness updates and exposes eight editable runtime components.Tasks arrive without ground-truth answers or labeled validation feedback, and each starts from a common execution harness.Source: §2.1 · pp. 3–4

2.2. Task-Level Recursion

  • Task-level recursion refines the current task’s execution harness using execution evidence, while the improvement harness remains fixed during that task.The approach guides revisions without ground-truth feedback and can extend the contrastive step through parallel or sequential recursion.Source: §2.2 · p. 4

2.2.1. A Contrastive Improvement Step

  • Propose creates invariant and domain-specific executable candidates; Probe compares behavior with a reference, not correctness; Compose selectively adopts supported edits and executes the successor.Probe runs candidates on the same task under matched model and environment configurations; composition may also revise conflicting edits or preserve the current harness.Source: §2.2.1 · p. 5

2.2.2. Parallel and Sequential Recursion

  • Parallel recursion composes successors independently from a shared candidate pool, whereas sequential recursion chains steps with accumulated evidence; k controls width or depth.Parallel recursion performs one population update; sequential steps can retain, revise, or correct earlier changes using current and previous evidence.Source: §2.2.2 · p. 6

2.3. Harnessing-Level Recursion

  • After each task, reflection extracts lessons only when execution contrasts support them, and the improvement library retains adopted harnesses and supported lessons.Selecting an output alone does not establish transferability.Source: §2.3 · p. 7
  • Later tasks start from the common execution harness, while library components and accumulated experience guide selective reuse or adaptation rather than automatic inheritance.Each library entry pairs an executable harness with an experience record describing applicable situations, lessons, and supporting evidence.Source: §2.3 · p. 7

3. Experiments

The experiments evaluate Harness2 across three professional benchmarks and four executor–harness configurations. A single improvement step yields consistent gains, and parallel task-level recursion adds further gains, although results vary by benchmark and model.

3.1. Experiment Setup

  • Evaluation covers WorkBuddy-Bench’s Code, Web, and Office domains, long-execution professional tasks in JobBench, and legal work in LAB, where Partial is the per-criterion pass rate.Main tables report means and standard deviations over three runs with shuffled task order.Source: §3.1 · p. 7
  • The four configurations pair frozen Gemini 3.5 Flash and GLM-5 executors with OpenCode or Codex, while the baselines include fixed harness, offline optimization, retrieval memory, and per-task harness evolution.The default editor is Claude Opus 4.8 under OpenCode; the improvement library starts empty for each benchmark stream.Source: §3.1 · p. 7

3.2. Main Results

  • A single Harness2 step improves GLM-5 and Gemini 3.5 Flash under OpenCode and Codex, with gains up to 11.5 points on WorkBuddy-Bench, 4.5 points on JobBench, and 11.8 percentage points in LAB Partial pass rate.Harness2 exceeds compared baselines on WorkBuddy-Bench Avg. and JobBench Score in all four configurations; Meta-Harness leads on LAB Partial for Gemini 3.5 Flash under Codex.Source: Table 1 · p. 8, §3.2 · p. 8, Table 2 · p. 9
  • GLM-5 receives larger absolute gains than Gemini 3.5 Flash on WorkBuddy-Bench and LAB, but Gemini gains more on JobBench under both initial harnesses.On JobBench, Gemini gains 4.5 and 1.4 points under OpenCode and Codex, versus GLM-5’s 3.6 and 1.2 points.Source: §3.2 · p. 8
  • Parallel task-level recursion at k=5 adds 2.9–3.9 points on WorkBuddy-Bench, 3.0–4.2 points on JobBench, and 2.6–6.7 percentage points in LAB Partial over a single step.Recursion does not uniformly close gaps between initial harnesses: GLM-5’s WorkBuddy-Bench gap increases from 0.2 to 1.3 points, while Gemini’s falls from 2.1 to 0.4.Source: §3.2 · p. 9

4. Analysis

The analysis tests task-level scaling, component ablations, harnessing-level recursion, and same-model editing. It reports gains from recursive refinement and accumulated experience, alongside a JobBench case study showing targeted edits addressing procedural failures.

Task-level recursion

  • At k=2, both recursive Harness2 forms outperform every plotted k=5 baseline on WB-code and WB-office; at k=5, parallel recursion finishes above sequential recursion.Sequential recursion is higher on Code at k=2, while ReasoningBank fluctuates and Harness Scaling regresses from k=2 to k=3 on both domains.Source: Figure 5 · p. 9, §4 · p. 10

Compute–performance trade-off

  • Figure 6 frames compute against performance on JobBench and WorkBuddy-Bench; parallel proposal and composition sessions can run concurrently, but realized latency depends on concurrency and rollout duration.Source: Figure 6 · p. 10

Ablation Study

  • Removing the improvement library lowers WorkBuddy-Bench and JobBench scores by 3.1 and 1.8 points; removing scoped editors costs 2.9 and 3.7, and removing composition costs 1.6 and 1.9.The ablation uses Gemini 3.5 Flash with OpenCode at k=1; each component contributes to performance.Source: §4 · p. 10, Table 3 · p. 10

Analysis of Harnessing-Level Recursion

  • Direct refinement without reference executions, candidate probes, or the improvement library drops Code from 73.4 to 63.2 and Web from 69.9 to 65.0; a library accumulated at k=1 restores base performance.The analysis examines whether updating a continual improvement harness benefits subsequent refinement and how the benefit scales with task-level exploration.Source: §4 · pp. 10–11, Figure 7 · p. 11

Same Model as Executor and Editor

  • All five models improve on every benchmark when the same model serves as executor and editor with OpenCode at k=2, showing refinement need not rely on a stronger editor.Opus 5 gains 3.3, 5.5, and 3.0 points on WorkBuddy-Bench, JobBench, and LAB; GLM-5 gains 13.7 points on LAB.Source: Figure 8 · p. 11, §4 · p. 11

Case Study

  • The JobBench case study’s targeted process guardrails and domain skill address unreconciled source files and missing output verification, raising the re-run score from 43.1 to 77.8.The improved harness retained all four edits from the two interventions.Source: §4 · p. 11, Figure 9 · p. 12

5. Related Work

Prior work optimizes harnesses offline, adapts them at test time, or accumulates experience across tasks. Harness2 combines contrastive task-level refinement with updates to an improvement harness across a deployment stream.

Harness Optimization and Evolution

  • Offline harness optimization searches candidate harnesses using reusable training tasks and evaluation feedback, while other approaches train harness editors or generators with task rewards (Chen et al., 2026; Zhang et al., 2026d,e; Shao et al., 2026; Zhang et al., 2026a).Source: §5 · p. 12
  • Open-world approaches refine task-specific harnesses from execution feedback or carry evolving harnesses across unlabeled batches (Lee et al., 2026a; Nie et al., 2026b; Wang et al., 2026a).Persistent improvement state has also been studied with delayed task-outcome feedback (Liu et al., 2026).Source: §5 · pp. 12–13

Recursive Self-Improvement

  • Harness2 combines contrastive task-level refinement and improvement-harness updates in a one-pass deployment stream without ground-truth supervision or model updates.Unlike benchmark-guided RSI approaches, it contributes task-specific refinements and experience to guide subsequent improvement.Source: §5 · pp. 12–13

6. Conclusion

Harness2 refines a task’s execution harness and learns from that process to guide future harnessing. The experiments support recursive harnessing as a way to make task-specific refinement reusable across open-world tasks.

6. Conclusion

  • Harness2 couples task-level recursion, which refines the current execution harness, with harnessing-level recursion, which updates the improvement harness using adopted harnesses and refinement experience.Source: §6 · p. 13
  • Across three professional benchmarks, two executors, and two initial harnesses, experiments show consistent gains over base configurations; ablation and transfer studies support scoped proposals, composition, and accumulated experience.Source: §6 · p. 13

A. Comparison of Harness Improvement Methods

Harness-improvement methods differ in what they edit, when and with what supervision they learn, how they process task streams, and whether they scale refinement or update the improver. Harness2’s distinction is combining label-free task-stream refinement of both harnesses with learning from task-level exploration.

A.1. Comparison Criteria

  • Object distinguishes component-level edits from joint revision of the execution harness and improvement harness.The execution harness governs task execution; the improvement harness guides harness refinement.Source: §A.1 · p. 17
  • Stage separates offline optimization on fixed tasks from learning on arriving deployment tasks, which Harness2 processes with an initially empty improvement library.Offline preparation may support test-time adaptation, but does not incorporate requirements first encountered during deployment.Source: §A.1 · p. 17
  • Label records external correctness feedback, whereas Harness2 uses behavioral contrasts without immediate or delayed correctness labels and reserves benchmark scores for evaluation.Model judgments and execution traces can guide revisions without establishing correctness.Source: §A.1 · pp. 17–18
  • Streaming covers one-pass task or batch updates; Harness2 processes tasks individually, permits rerunning the current task, and does not replay completed tasks.Earlier harnesses and experience remain available without rerunning their source tasks.Source: §A.1 · p. 18
  • Scaling captures explicit test-time exploration: Harness2 composes parallel candidates or carries a refined harness and evidence into sequential recursion.The comparison also tracks improver updates, which are persistent changes to editing guidance, editor parameters, or experience beyond the execution artifact; Harness2 updates its improvement harness after each task without correctness labels, while model weights and the improvement algorithm remain fixed.Source: §A.1 · p. 18
  • Harness2 combines label-free task-stream refinement of both harnesses with learning from task-level exploration.The comparison distinguishes this combination from streaming, experience reuse, or improver updates considered alone.Source: §A.1 · p. 18

B. Benchmarks

The evaluation uses three professional benchmarks with different task types, grading procedures, and test splits. It also compares harness-improvement methods along six stated dimensions.

B. Benchmarks

  • WorkBuddy-Bench tests Code, Web, and Office datasets, reporting test halves of 40, 35, and 25 tasks, respectively.The domains span coding, web interaction, and office workflows; each dataset is split in half by category.Source: B. Benchmarks · p. 18
  • Table 4 compares methods on Object, Stage, Label, Streaming, Scaling, and Improver Update; Label denotes external correctness supervision.Both denotes offline preparation and test-time adaptation.Source: Table 4 · p. 19
  • JobBench uses 34 test tasks from a frozen 31/34 split, scored by Claude Opus 4.8 against a weighted deliverables rubric hidden from the pipeline models.Its task score is the total weighted score over the maximum score, using the benchmark’s own metric.Source: B. Benchmarks · p. 19
  • LAB reports per-criterion pass rate (Partial) on 100 held-out legal tasks judged by Claude Sonnet 4.6; its 24-task development set is used only by Meta-Harness.The benchmark has 1,251 tasks across 24 practice areas and four work types; the held-out set covers the full range of context sizes.Source: B. Benchmarks · pp. 19–20
  • Harness2 and other baselines process test tasks as streams, while only Meta-Harness uses the WorkBuddy-Bench and JobBench training halves; scores average three independent streams.The number of executor-session model turns is reported as #Steps.Source: B. Benchmarks · p. 20

C. Baselines

The baselines range from repeated execution and memory retrieval to verifier-blind revision and offline search. All share the same frozen executor, initial harness, test stream, and judge.

C. Baselines

  • All baselines use the same frozen executor and initial harness, process the same test stream, and are evaluated by the same judge.Revision and reflection use Claude Opus 4.8, matching the editor.Source: C. Baselines · p. 20
  • Best-of-k runs the base harness independently k times per task, then uses Harness2’s selector to choose a deliverable without score access.Source: C. Baselines · p. 20
  • ReasoningBank retrieves up to three similar past-task memories, then distills self-judged rollout trajectories into a domain-specific bank.For k > 1, it uses shared-memory rollouts, best-of-k deliverable selection, and contrastive distillation over the labeled trajectories.Source: C. Baselines · p. 20
  • Harness Scaling revises the harness per task using the base rollout and subsequent trajectories, without scope splitting, aggregation, a library, or score access.The final revised tree is deployed; if deployment produces no output, the base run is submitted instead.Source: C. Baselines · p. 20
  • Meta-Harness optimizes offline on a search set, accepts candidates only when they beat the frontier by a margin, and deploys the result unchanged on the test stream.It distills every candidate into lessons for the next search round.Source: C. Baselines · p. 20

D. Implementation Details

The implementation uses frozen executors and editable runtime harness components, with separate sessions for editing and selection. Supplementary experiments test component contributions, experience reuse, transfer, reliability, alternative harnesses, and failure cases.

D. Implementation Details

D.1. Executors and Initial Harnesses

  • The executor is a frozen model in an off-the-shelf coding agent, and the initial harness is its stock configuration extended with benchmark reference instructions.Under OpenCode, editable components include always-on files, on-demand skills, subagents, scripts, and TypeScript plugins; Codex uses AGENTS.md for always-on text.Source: §D.1 · p. 21

D.2. Improvement Sessions and Library Configuration

  • Claude Opus 4.8 runs the editor and selector sessions; each domain library retains adopted harness trees and EXPERIENCE.md explanations for later tasks.Invalid trees are retried once with validator feedback, then fall back to the starting tree if still invalid.Source: §D.2 · p. 21

D.3. Editable Harness Components

  • Table 5 groups eight editable harness components by the runtime part they modify; each component is a file that can be changed by a diff.Activation describes when a component reaches the model.Source: Table 5 · p. 22

C4 Tool guidance

  • Tool guidance specifies when and how existing tools should be used, while delegated subagents add an inference context of their own.A specialist procedure is loaded only when invoked, avoiding context cost on tasks that do not need it.Source: C4 Tool guidance · p. 22, C8 Plugin · p. 22

C7 Scripts

  • Scripts provide deterministic capabilities, while plugins interpose code around tool calls and turn boundaries to enforce behavior outside the model’s discretion.Source: C8 Plugin · p. 22

E. Supplementary Experiments and Analyses

  • The supplementary experiments examine individual component contributions and experience reuse, then cross-model transfer, tool-use reliability, alternative production harnesses, and qualitative failure cases.Source: E. Supplementary Experiments and… · p. 23

E.1. Contributions of Harness Components

  • The full harness beats every ablation in all three domains; skills removal loses most on Code and Web, while scripts removal loses most on Office.On the three-domain average, skills, scripts, and prompt-group ablations lose 5.3, 3.7, and 1.5 points, respectively; every ablation still exceeds the base, and the results do not establish additive effects.Source: §E.1 · p. 23, Table 6 · p. 23

E.2. Reuse of Harnesses and Improvement Experience

Across the reuse, transfer, reliability, and production-harness analyses, Harness2 adapts existing harnesses, transfers gains across executors, and improves tool reliability. Its comparison with fixed production harnesses shows gains across all three WorkBuddy-Bench domains, with additional test-time compute.

E.2. Reuse of Harnesses and Improvement Experience

  • Library provenance appears in 22% of modified files on LAB and WB-office and 47% on JobBench, while only 2–10% retain at least half their lines from a library entry.Skills and scripts account for roughly half the edits on each benchmark, indicating adaptation is more common than extensive copying.Source: Figure 10 · p. 23, §E.2 · p. 24
  • In an offline leave-one-out rerun, WorkBuddy-Bench rises from 77.5 to 79.4 and JobBench from 36.0 to 37.7; later-task entries and repeated execution may contribute.Because the rerun can use entries from both earlier and later tasks, it does not estimate online gains.Source: §E.2 · p. 24, Figure 11 · p. 24

E.3. Transfer Across Executor Models

  • A Gemini 3.5 Flash harness transfers without adaptation: GLM-5 gains 17.3 points on Code (58.5→75.8), while Gemini 3.7 Flash and Opus 4.8 also improve on Code and Office.Gemini 3.7 Flash gains 0.3 on Code and 6.4 on Office; Opus 4.8 gains 2.6 and 1.1 points, respectively.Source: Figure 12 · p. 24, §E.3 · p. 24

E.4. Tool-Use Reliability

  • Tool-error rates fall on all three benchmarks after one improvement step, with the largest drop on JobBench (14.4%→9.1%), while call counts decrease only on WorkBuddy-Bench.Calls increase on JobBench and LAB, distinguishing improved tool reliability from fewer calls.Source: §E.4 · p. 25, Table 7 · p. 25

E.5. Comparison with Production Harnesses

  • Harness2 exceeds the strongest fixed alternative by 4.6, 5.8, and 4.9 points on WorkBuddy-Bench Code, Web, and Office, respectively.The fixed harnesses have no single domain leader; Harness2 starts from OpenCode and uses additional test-time compute.Source: Figure 13 · p. 25, §E.5 · p. 25

E.6. Failure Analysis

The failure analysis groups regressions into candidate-selection errors, propagated assumptions, and other execution or evaluation effects. The case studies show how diagnosed behaviors inform targeted harness edits, from a single tool-guidance file to coordinated runtime changes.

E.6. Failure Analysis

  • Nine regressions arise from weaker candidate selection, incorrect assumptions shared across candidates, or execution and evaluation effects that complicate attribution.Examples include choosing a score-55 output over a score-95 output and LAB coverage narrowing from 54 to 26; proposed responses include balancing coverage and precision and probing shared assumptions.Source: §E.6 · pp. 25–26, Figure 14 · p. 26

E.7. Qualitative Case Studies

  • On WorkBuddy-Bench, forbidding pseudo-calls raises Code from 60.0 to 100.0, while Office and Web harness edits raise scores from 23.6 and 64.0 to 100.0.The Office edit pins aggregation grain and cleaning rules; the Web edits re-derive changing state and check offline artifact opening.Source: Figure 15 · p. 27, Figure 16 · p. 27, §E.7 · p. 27
  • On LAB arbitration, recording deletions and insertions as in-body markup and loading it for redline tasks raises the score from 44.4 to 94.5.Source: §E.7 · p. 27, Figure 18 · p. 28
  • In a JobBench research-assistant case, a composed harness with edits across all eight components raises the score from 72.0 to 100.0.Edits include a warning after repeated tool calls without an artifact, a subagent returning citable tables, and durable domain memory.Source: §E.7 · p. 27, Figure 19 · p. 29

F. Limitations

This section discusses the costs and limits of Harness^2 refinement and the evidence checks and retention options used to guide harness edits. It also identifies adaptive recursion and improvement-harness management as future directions.

F. Limitations

  • Increasing recursion budget adds inference cost; parallel sessions can reduce latency but not computation, and experiments cover bounded budgets rather than a universally optimal allocation.The trade-off is between the additional executions and editor sessions needed to propose, probe, and compose harness changes and their potential benefits.Source: F. Limitations · p. 29
  • Without ground-truth supervision, behavioral contrasts and model judgment remain sensitive to execution variability and shared biases, so adopted changes are not guaranteed correct or transferable.These signals help assess a proposed change but do not establish that it will work on a different task.Source: F. Limitations · p. 29

G. Future Directions

  • As its indexed library grows, the improvement harness could consolidate overlapping components, revise outdated experience, and refine retrieval to keep it compact and relevant.Management should preserve context needed to reuse earlier discoveries.Source: G. Future Directions · p. 29
  • Future work could adapt exploration to task difficulty and prior experience, or stop when probes yield little new evidence, balancing refinement cost against future value.The current recursion form and budget are specified in advance.Source: G. Future Directions · p. 29

H. Prompts

  • The shared prompts place improver sessions in a workspace containing task evidence and harness materials, while benchmarks append domain-specific descriptions and constraints; they assume no rubric or grader exists.The prompts direct the model to act on that evidence rather than embedding it in the prompt.Source: H. Prompts · p. 30
  • The prompts divide harness editing into workflow and practitioner dimensions, require edits to trace to trajectory evidence, and have agents modify harness files in place as their proposal.The editor prompt assigns procedure and tool use to one dimension and practitioner knowledge to the other; unsupported changes can be left unapplied.Source: H. Prompts · pp. 30–33
  • Compose from trajectory evidence: repeated base failures are stronger evidence than a defect in one base rollout, while each candidate has only one rollout and a single outcome is weak evidence.Treat non-delivery as a serious downside, and regard `KEEP_BASE` as valid when the evidence does not justify adaptation.Source: H. Prompts · pp. 33–34
  • In sequential adaptation, compose each checkpoint using shared base evidence, current candidates, and prior rounds; the current checkpoint’s rollout is on-policy evidence, and an earlier checkpoint may be restored.Notes identify which rounds’ edits survive or are dropped; `KEEP_BASE` preserves the current checkpoint rather than restoring the original harness.Source: H. Prompts · p. 34
  • Select anonymous candidate artifacts against the request and source, prioritizing delivery, exact conformance, and fidelity over how they were produced or how impressive they sound.Check internal consistency as well; a contradiction within the artifact is a defect even when its correct value is unclear.Source: H. Prompts · p. 35
  • Use `confounded` when a single rollout or bundled edits do not isolate an effect, and cite the run and trajectory divergence rather than inventing attribution.For lessons, use edit rows as evidence; adoption alone does not establish that an edit helped or will transfer.Source: H. Prompts · pp. 36–37
  • A durable lesson needs a reusable situation cue and a checkable operation naming the harness component; if no concrete reusable execution contrast exists, write `NO_ENTRY`.A lesson based only on confounded rows should be narrowed to what the record shows or declined.Source: H. Prompts · pp. 36–37

Related papers

Loading 2610.14224v1…