PaperlayerView exact revision on arXiv

Source-linked AI summary

Local Edits, Global Ripples: Replay-Informed Policy Adaptation for Workflow Synthesis

Manqing Mao, Hong Wang, Samson Koelle, Jie Yuan, Zhuoer Wang, James Feng, Yanjun Lin, Daniel Edmiston, Nikki Lijing Kuang, Zhecheng Sheng, Wei Niu

arXiv:2609.12127v1cs.CLcs.SE

TL;DR

Persistent prompt edits can change downstream behavior, and their isolated gains may not survive composition, making both failure localization and safe persistence important. RIPPLE maps trajectory diagnoses to bounded segment edits, compares candidates from the same starting policy, then replays them after accepted updates. On Flow-HO, it improves validation success by up to 23.1% and reports positive gains across two additional frozen backbones.

  • Problem

    Persistent prompt editing must address non-local effects and composition-sensitive interactions, while execution failures alone do not identify the responsible behavior or policy segment.

    Source: §1 · pp. 1–2

  • Method

    RIPPLE maps trajectory-grounded diagnoses to bounded segment patches, ranks candidates from the same iteration-start policy, and replays them sequentially on the advancing policy before persistence.

    Source: §1 · p. 2, §3.2 · p. 5, §3.3 · p. 6

  • Results

    On Haiku 4.5, RIPPLE raises service-validation success from 54.7% to 77.8% (+23.1%), and the paper reports consistent gains across two additional frozen backbones.

    Source: §1 · p. 2, §4.2 · p. 8, §5 · p. 9

  • Takeaways & Limitations

    Interaction analyses show that local gains can reverse after composition and that promotion rules can select distinct checkpoints under fixed proposal and replay evidence.

    Source: §5 · p. 9, §4.5 · p. 9

    The evaluation concerns a frozen agent: model parameters, tool interface, and execution environment remain fixed while only the prompt policy is adapted.

    Source: §2.1 · p. 2

Abstract

from arXiv · show

Prompt-policy editing offers a practical way to improve agents that synthesize executable workflows without updating the underlying model. However, persistent prompt editing has two coupled properties. First, edit locality does not imply effect locality: an edit confined to one policy segment can ripple through downstream execution, altering behavior beyond the edited segment. Second, edit effects are composition-sensitive: edits that work in isolation can interfere after composition, causing one or both to lose their benefit or become harmful. Persistent adaptation must therefore support two distinct decisions: identifying where the policy should change from execution feedback, and determining whether the resulting edit remains safe to persist after composition. To address these challenges, we introduce RIPPLE (Replay-Informed Persistent Policy Localization and Editing), which separates where an edit is made from whether it remains safe after composition. It diagnoses failed trajectories, maps each actionable failure to a predefined policy segment, and restricts the correction to that part of the policy. RIPPLE then evaluates candidates against the same iteration-start policy to compare their isolated gains, before replaying promising edits after previously accepted updates to expose downstream effects and interactions. Only edits that remain safe under composition are retained. We evaluate RIPPLE on Flow-HO, a synthetic held-out benchmark for executable workflow synthesis. RIPPLE improves validation success by up to 23.1% and yields positive gains on two additional frozen language-model backbones, while maintaining edit efficiency and low execution cost. Targeted interaction analysis further demonstrates both properties: a segment-local tool-use edit changes downstream resource resolution and validation, while an edit beneficial in isolation becomes harmful after composition.

1 INTRODUCTION

Executable workflows must satisfy schemas, implement requested behavior, resolve resources, and pass validation, so plausible outputs can still be undeployable. RIPPLE localizes failure-driven edits and tests their safety after composition, addressing execution feedback and policy interactions.

1 INTRODUCTION

  • Executable workflows can remain undeployable despite semantic plausibility when fields, transitions, resource identifiers, or repairs are invalid or incomplete.They must conform to a schema, implement requested behavior, resolve environment-specific resources, and pass external validation.Source: §1 · p. 1
  • Persistent prompt editing must address non-local effects and composition-sensitive interactions, because local changes can alter downstream execution and isolated gains may weaken or reverse.The relevant persistence test is whether an edit remains useful and safe in the evolving shared policy.Source: §1 · pp. 1–2
  • RIPPLE diagnoses trajectory failures, maps actionable diagnoses to predefined prompt segments, and instantiates bounded patches from a versioned library.It then ranks candidates by local gain and evaluates them sequentially after previously accepted edits.Source: §1 · p. 2
  • RIPPLE consistently improves validation success and composite reward across multiple frozen language models while maintaining strong edit efficiency and low execution cost.Ablations and interaction analyses show replay design and patch composition matter, and local gains can reverse after composition.Source: §1 · p. 2
  • The paper evaluates RIPPLE on Flow-HO and analyzes failure-localized editing, composition-aware persistence, and patch-interaction failure modes.Its contributions include a replay-gated promotion procedure that separately constrains reward and correctness.Source: §1 · p. 2

2 PERSISTENT PROMPT-POLICY ADAPTATION

The paper formulates persistent adaptation of a frozen, tool-using workflow agent as selecting ordered, bounded edits to a segmented prompt policy. Its setup distinguishes execution-based localization of proposed edits from replay-based decisions about whether edits remain safe after earlier updates.

2.1 PROBLEM SETUP

  • The setup studies closed-schema workflow synthesis with a frozen, tool-using LLM agent; only its prompt policy changes, while model parameters, tools, and environment stay fixed.Tasks pair a natural-language request with an initial workflow, which is empty for generation tasks.Source: §2.1 · p. 2
  • A trajectory receives a bounded composite reward from validation success, workflow correctness, edit efficiency, and normalized execution cost.Correctness is also constrained separately during promotion.Source: §2.1 · p. 2
  • Pool-level scores aggregate a policy’s metric over tasks, using either a uniform mean or a macro-average over workflow families.The aggregation rule is denoted g.Source: §2.1 · p. 3
  • The prompt policy is partitioned into behavioral segments, and accepted bounded patches apply to designated segments in sequence.Order matters because patches can reinforce, override, or conflict with instructions already in the policy.Source: §2.1 · p. 3
  • A patch’s marginal effect depends on the accepted prefix already present in the policy, not just on the patch itself.The prefix-conditioned effect is defined for a candidate, metric, and task pool.Source: §2.1 · p. 3
  • The ideal objective improves training-pool performance while requiring reward and correctness thresholds on replay after each proposed patch.Small negative replay deltas are allowed, but the thresholds are empirical safeguards rather than guarantees on unseen requests; exhaustive ordered-subset search is too costly, motivating localized candidates and greedy sequential evaluation.Source: §2.1 · p. 3

2.2 TWO DECISIONS IN PERSISTENT POLICY EDITING

  • A low reward or validation failure does not identify its cause, so proposal uses trajectory evidence to diagnose a failure family, select a policy segment, and form a bounded patch.This reduces open-ended prompt rewriting to a localized, typed update.Source: §2.2 · p. 3
  • RIPPLE separates edit localization from persistence: it ranks candidates by local gain, then replays each on the accepted policy and checks reward and correctness separately.The figure presents failure diagnosis, segment localization, and replay-gated persistence as the iteration’s three stages.Source: §2.2 · p. 3, Figure 1 · p. 4

3 RIPPLE: LOCALIZED AND REPLAY-GATED POLICY EDITING

RIPPLE localizes policy changes to fixed behavioral segments, then tests promising edits after accepted updates to check their safety under composition. Its workflow moves from trajectory diagnosis and patch construction to replay-gated promotion and iterative maintenance.

3.1 WHAT FAILED: ROLLOUT GENERATION AND BEHAVIORAL DIAGNOSIS

  • RIPPLE prioritizes high-variance training datapoints, diagnoses their lowest-reward rollout, and applies rule-based checks to identify actionable failure families without an LLM call.Multiple actionable labels may be retained, while fixed precedence favors direct, causally earlier evidence.Source: §3.1 · p. 5

3.2 WHERE TO EDIT: SEGMENT-TYPED PATCH CONSTRUCTION

  • The fixed prompt policy has seven behavioral segments, and RIPPLE appends bounded patches to designated segments using deterministic failure-to-segment retrieval.It retrieves an exact failure-family and segment match when available, otherwise a generic patch for that segment; nominations are ranked by support count with coverage-first round robin.Source: §3.2 · p. 5

3.3 WHETHER TO PERSIST: POLICY IMPROVEMENT AND REPLAY-CONSTRAINED PROMOTION

  • Candidates are ranked by isolated gains measured from the same iteration-start policy, then replayed sequentially atop accepted edits before promotion.Replay checks reward and correctness separately; its negative tolerances allow small per-patch regressions, which may accumulate.Source: §3.3 · p. 6

3.4 POLICY ITERATION AND REPLAY MAINTENANCE

  • Replay can use a fixed core set or an adaptively refreshed set that includes persistently low-performing and recently changed examples.Two consecutive iterations without an accepted patch stop the procedure.Source: §3.4 · p. 6
  • +23.1 pp service-validation success on Haiku; all backbones gain at least +6.8 pp, while workflow correctness changes by at most 0.9 pp.Reward improves on all four families for Haiku and three of four for each transfer backbone; regressions are backbone-specific.Source: Figure 2 · p. 7

4 EXPERIMENTS

The experiments test held-out workflow quality across frozen backbones and examine replay design, composition safety, and promotion rules. Flow-HO provides the synthetic held-out workflow benchmark for these evaluations.

4.1 EXPERIMENTAL SETUP

  • Flow-HO’s primary split has 39 workflow-modification tasks across four ground-truth families disjoint from training and replay; Haiku is the primary backbone, with Gemma and Ministral transfer settings.The protocol uses three rollouts per datapoint and a diagnosis budget of 15.Source: §4.1 · p. 7

4.2 RQ1: HELD-OUT EFFECTIVENESS ACROSS FROZEN BACKBONES

  • RIPPLE-U had the strongest edit efficiency and lowest execution cost among harmonized systems, with mean reward above the base policy in all four Flow-HO families.Figure 2 reports positive reward gains on all four Haiku families and three of four families for each transfer backbone.Source: §4.2 · p. 8
  • 54.7% to 77.8% (+23.1%) service-validation success on Haiku 4.5; composite reward rose from 0.525 to 0.644, while correctness rose only 0.8%.Both the success and reward paired family-cluster intervals exclude zero; the correctness change remains unresolved.Source: Table 1 · p. 8, §4.2 · p. 8
  • 6.8 pp service-validation gains on both Gemma and Ministral transfer backbones were untuned; reward improved on both, while correctness was unchanged or slightly lower.Both transfer runs reuse Haiku’s proposer, patch library, replay design, and gate tolerances without backbone-specific tuning.Source: §4.2 · p. 8, Table 1 · p. 8

4.3 RQ2: REPLAY DESIGN AND ITERATION DEPTH

  • Uniform aggregation and static replay outperform Coverage-Adaptive in success and reward; Train-Only accepts more patches, while Multi-Iteration adds two patches yet underperforms its parent.Persistent performance depends on which edits survive, their order, and their interactions—not simply patch count or iteration depth.Source: Table 2 · p. 8, §4.3 · pp. 8–9

4.4 RQ3: DETECTING DESTRUCTIVE EDIT INTERACTIONS

  • After four accepted patches, F2a’s replay reward and correctness fell 0.2257 and 0.1218, and validation success dropped from 35.4% to 0%; advancing replay rejected it.F2a passed training-side pre-qualification against the shared iteration-start policy, but an earlier patch’s resource-resolution requirement made the edit harmful after composition.Source: Table 3 · p. 9, §4.4 · p. 9

4.5 RQ4: PROMOTION RULES AND CHECKPOINT TRADE-OFFS

  • Under the matched acceptor probe, stricter rules retained one-patch Skill-Compact, improving correctness by 5.4 pp and reward by 0.026 over the four-patch ε-AND checkpoint, while RIPPLE-U remained strongest overall.The stricter checkpoint differed in success by only 1.7%; the acceptor swap held the proposer, candidate order, and replay evidence fixed.Source: Table 4 · p. 9, §4.5 · p. 9

5 CONCLUSION

RIPPLE treats persistent prompt adaptation as sequential policy composition: it localizes failure-driven edits, then tests whether they remain safe after prior edits are composed. The related-work discussion situates this approach among prompt optimization, verification, persistent textual artifacts, and executable workflow systems.

5 CONCLUSION

  • RIPPLE turns execution failures into bounded, segment-localized edits and promotes candidates only after replay against the evolving accepted policy.The conclusion frames edit value as depending on interactions within the policy where an edit persists.Source: §5 · p. 9

A RELATED WORK

  • Prior work addresses edit localization and policy-context dependence unevenly, motivating evaluation of edits both locally and after composition.The discussion organizes related work around these two properties across four research areas.Source: A RELATED WORK · p. 14

A.1 AUTOMATIC PROMPT AND POLICY OPTIMIZATION

  • APE (Zhou et al., 2023) and OPRO (Yang et al., 2024a) optimize textual instructions, but score candidates on the base policy rather than testing safety after other edits compose.RIPPLE instead constrains proposals to diagnosed segments and bounded patches, then separates candidate ranking from replay-based persistence.Source: §A.1 · p. 14

A.2 VERIFICATION-DRIVEN AND CONSERVATIVE IMPROVEMENT

  • RIPPLE extends verify-before-commit from individual outputs to persistent policy edits, using separate replay constraints for reward and workflow correctness.It keeps adaptation at the symbolic prompt-policy layer rather than updating model weights or relying on an LLM judge alone.Source: §A.2 · p. 15

A.3 PERSISTENT SKILL AND PROMPT EVOLUTION

  • Persistent skill and prompt systems carry textual artifacts across tasks, but the surveyed systems do not couple artifact acquisition to replay against an advancing accepted prefix.RIPPLE uses a fixed workflow taxonomy, segment-typed versioned patches, and separate reward and correctness constraints, trading open-ended coverage for deterministic, auditable changes.Source: §A.3 · pp. 15–16

A.4 EXECUTABLE WORKFLOW SYNTHESIS AND VERIFIABLE-REWARD AGENTS

  • Executable workflow systems use feedback within a task or one-shot search, whereas RIPPLE retains prompt-segment edits across tasks only after they pass replay constraints against an advancing baseline.This makes RIPPLE complementary to systems that keep the prompt policy fixed at deployment.Source: §A.4 · p. 16

B.1 BENCHMARKS

The appendices specify Flow-HO’s workflow tasks and RIPPLE’s deterministic diagnosis, patch construction, replay promotion, iteration, and reward components. The design uses bounded, segment-typed edits and evaluates persistence against an advancing policy.

B.1 BENCHMARKS

  • Flow-HO is a synthetic held-out workflow suite covering modification and generation; its modification pools partition ground-truth families across training, replay core, and held-out evaluation.The primary modification study repairs corrupted workflows, while the secondary generation setting constructs workflows from requests.Source: §B.1 · p. 16, §B.1.1 · p. 16, §B.1.2 · p. 17

B.1.1 WORKFLOW MODIFICATION

  • Modification inputs are deterministically corrupted through add-block, reroute, modify-config, or replace-logic operations while preserving a resolvable graph and valid start action.The four held-out families span distinct structural regimes rather than minor variants of one template.Source: §B.1.1 · p. 17

B.2 BASELINES AND CONTROLLED ACCEPTORS

  • Controlled acceptor swaps are not end-to-end reproductions of SkillOpt or SkillGen, and Skill-Compact metrics come from a separate acceptor-probe cache.The swaps select the same one-patch checkpoint, which is analyzed separately rather than ranked with harmonized systems.Source: §B.2 · p. 17

B.3.1 CANDIDATE CONSTRUCTION: DIAGNOSIS, LIBRARY, AND AGGREGATION

  • RIPPLE diagnoses trajectories with a predefined six-family taxonomy, maps actionable failures to prompt segments, and retrieves bounded corrections from a versioned patch library.The fixed taxonomy was constructed from actionable workflow failure loci, and F6 refinements can override default segment mappings.Source: §B.3.1 · pp. 18–19

B.3.2 PROMOTION: TWO-SIGNAL REPLAY GATE AND REPLAY POOL

  • A candidate is promoted only when both replay reward and correctness deltas meet their thresholds; acceptance advances the prefix, while rejection leaves it unchanged.Adaptive replay can include training datapoints, so it is a mixed stability pool rather than a fully disjoint validation set.Source: §B.3.2 · p. 19

B.3.3 ITERATION PROCEDURE

  • Each iteration ranks candidates against the same current policy, then tests promising candidates sequentially against the advancing replay baseline before composing accepted patches.The multi-iteration procedure checkpoints each iteration and stops after two consecutive iterations without an accepted patch.Source: §B.3.3 · pp. 19–20

B.3.4 REWARD FUNCTION

  • The modification reward combines service validation, workflow correctness, their interaction, edit efficiency, and execution cost, with lighter shaping for efficiency and cost.Service validation requires a successful post-hoc create-and-validate operation; correctness compares fields keyed by action identifier.Source: §B.3.4 · p. 21

B.3.5 ROLLOUT CONFIGURATION AND UNCERTAINTY

The rollout and uncertainty setup fixes the model runtime and uses deterministic simulation and diagnosis. The reported Haiku gains are qualified by uncertainty estimated from only four workflow-family clusters.

B.3.5 ROLLOUT CONFIGURATION AND UNCERTAINTY

  • The experiments fix model endpoints and runtime; a deterministic simulator answers clarification questions, and a deterministic Python module diagnoses trajectories.Rollouts use a dedicated evaluation environment with resource-resolution tools and temporary validation resources deleted after use.Source: §B.3.5 · p. 22
  • Tool incompleteness, ambiguous resource descriptions, and systematic infrastructure failures are not modeled separately and may appear as F2 symptoms that prompt patches cannot correct.This bounds interpretation of tool-use diagnoses to the modeled environment and failure conditions.Source: §B.3.5 · p. 22
  • The Haiku uncertainty intervals resample four workflow-family clusters, including all paired datapoints within each sampled family, across 10,000 replicates.Because family sizes differ, the pooled statistic remains datapoint-weighted.Source: §B.3.5 · p. 22, Table 8 · p. 23
  • +23.1 pp service-validation success gain and +0.119 composite reward gain have family-cluster intervals excluding zero; workflow-correctness gain remains unresolved.With only four clusters, the intervals describe uncertainty on this benchmark rather than providing a population-level guarantee or independent confirmation.Source: §B.3.5 · p. 23, Table 8 · p. 23

B.4 HAIKU PRINCIPAL-STUDY SUPPLEMENTARY RESULTS

The supplementary Haiku analyses report reward-component rankings and descriptive family-level comparisons, alongside figures relating patch counts, rewards, and replay checkpoints.

B.4.1 REWARD-COMPONENT BREAKDOWN AND FAMILY-LEVEL CONSISTENCY

  • RIPPLE-U has the highest validation success, edit efficiency, and composite reward, while RIPPLE-S has the highest workflow correctness among harmonized Haiku systems.Skill-Compact is a descriptive checkpoint from a separate acceptor-probe cache.Source: Table 9 · p. 23, §B.4.1 · p. 23
  • N = 3 for the base versus N = 10 for RIPPLE-U and RIPPLE-S; per-family reward comparisons are descriptive because caches and rollout counts differ.Figure 3 plots family means with 1.96 × SEM intervals, and Table 10 supplies the underlying means and rollout counts.Source: §B.4.1 · p. 23, Table 10 · p. 24, Figure 3 · p. 24
  • Figure 4 relates accepted-patch count to modification reward; Figure 5 traces Coverage-Adaptive replay scores and selected Flow-HO checkpoints, marking iteration-2 acceptances and a distinct four-patch RIPPLE-U sequence.Equal patch counts are offset only for visibility in Figure 4.Source: Figure 4 · p. 24, Figure 5 · p. 25

B.4.2 CONVERGENCE AND CHECKPOINT COMPLEMENTARITY

Checkpoint comparisons show that request-level gains are complementary rather than universal, and iteration-2 replay improvements do not carry over to Flow-HO. Across configurations, similar patch counts can represent different policies and held-out performance.

B.4.2 CONVERGENCE AND CHECKPOINT COMPLEMENTARITY

  • Iteration-2 additions raise replay scores but do not carry over to Flow-HO at the selected checkpoints.The reported comparisons track Coverage-Adaptive and RIPPLE-U through their checkpoint sequences.Source: §B.4.2 · p. 25, Table 11 · p. 25, Table 12 · p. 25
  • A post hoc oracle raises mean reward from 0.625 to 0.665, but request-level complementarity means neither checkpoint dominates every task.The oracle is an upper bound, not a deployable routing rule.Source: §B.4.2 · p. 25, Figure 6 · p. 26
  • A request-only selector using q and y0 recovers none of the oracle headroom, while a diagnostic selector recovers 61% but requires the ground-truth workflow.The diagnostic selector is therefore nondeployable.Source: §B.4.2 · p. 26

B.4.3 CROSS-CONFIGURATION PATCH PROFILE

  • Similar patch counts mask different policies: gated variants accept different patches, while Train-Only accepts six and Multi-Iteration adds two patches in iteration 2.Train-Only cannot remove candidates with positive training gain through replay promotion.Source: §B.4.3 · p. 26, Table 13 · p. 26

B.5 CROSS-BACKBONE TRANSFER SUPPLEMENTARY RESULTS

The supplementary transfer results use the Haiku protocol and patch library on Gemma and Ministral, with Ministral additionally bypassing the training pre-filter. Results describe component, family, and patch-level behavior across the two backbones.

B.5.1 BACKBONE TIER BRACKET

  • The pilot selects one backbone from each non-collapse base-success band; collapse-band backbones are excluded because their base policy offers too little reliable execution capability for this study.The pilot covers six frozen backbones on 39 Flow-HO tasks with N = 3.Source: §B.5.1 · p. 27, Table 14 · p. 27

B.5.2 CROSS-BACKBONE REWARD-COMPONENT BREAKDOWN

  • Gemma and Ministral both gain validation success and reward; correctness, edit efficiency, and execution cost stay nearly unchanged on Gemma, while Ministral's execution cost rises mainly through tokens.The accepted Ministral patches lengthen the segmented prompt.Source: §B.5.2 · p. 27, Table 15 · p. 27

B.5.3 CROSS-BACKBONE FAMILY-LEVEL CONSISTENCY

  • Validation success improves in three of four families on each backbone, with family C regressing for Gemma and family B for Ministral.Family D has the largest reward gain for both backbones; these single-protocol values support descriptive directionality rather than paired inference.Source: §B.5.3 · p. 27, Table 16 · p. 28

B.5.4 ACCEPTED PATCHES AND PER-PATCH REPLAY EVIDENCE

  • Accepted patches are largely backbone-specific: Gemma accepts one PLAN and two EDIT patches, while Ministral accepts one REQ UNDERSTANDING and two EDIT patches.Both concentrate patches in EDIT, reflecting recurring schema and parameter failures; the remaining segment differs with the diagnosed failure profile.Source: §B.5.4 · p. 28, Table 17 · p. 28
  • Gemma's replay gate rejects F5a despite positive training gain, while all three evaluated Ministral candidates pass the unchanged two-signal replay gate.Ministral's three candidates were evaluated after bypassing the training pre-filter.Source: §B.5.4 · p. 28, Table 18 · p. 29

B.5.5 MINISTRAL PROTOCOL: BYPASSING THE TRAINING PRE-FILTER

The Ministral run bypasses a training-side pre-filter that would otherwise prevent replay evaluation of its candidates. The reported replay gate remains unchanged, but the earlier candidate pool was not reevaluated under the bypassed protocol.

B.5.5 MINISTRAL PROTOCOL: BYPASSING THE TRAINING PRE-FILTER

  • All six examined Ministral candidates have training deltas in [−0.10, 0], so the enabled positive-gain pre-filter would send none to replay.The reported run bypasses that filter for the final diagnosis-matched top three and applies the unchanged replay gate.Source: §B.5.5 · p. 29, Table 19 · p. 29
  • F6g, F3d, and F3e are accepted sequentially after the pre-filter is bypassed for the final three candidates.The persistence decision remains the replay-side AND rule, with the training condition serving as a compute-saving pre-filter.Source: §B.5.5 · p. 29
  • The three candidates from the earlier pool were not reevaluated under the bypassed protocol, so their replay classifications remain unknown.The table distinguishes the final three candidates evaluated under bypass from earlier candidates screened under the default pre-filter.Source: §B.5.5 · p. 29, Table 19 · p. 29

C.1 WHY THE REPLAY GATE USES TWO SIGNALS

The replay gate keeps reward and workflow correctness as separate admissibility conditions, but its marginal thresholds do not ensure cumulative monotonic improvement. The appendix also clarifies aggregation, the observed role of the correctness condition, and the accepted prompt changes.

C.1 WHY THE REPLAY GATE USES TWO SIGNALS

  • Replay promotion requires both reward and workflow correctness to remain within tolerance, since composite reward can mask a decline in either dimension.The AND rule prevents an arbitrarily large regression in one metric from being offset by passing the other.Source: §C.1 · p. 29
  • Marginal replay checks allow regressions to accumulate: after F3a raises reward from 0.431 to 0.503, three accepted patches lower it to 0.443, below the one-patch checkpoint.Each marginal change remains above εR = −0.05, and the final checkpoint remains above the iteration-start policy; cumulative control would be stronger when sequence-level monotonicity is required.Source: §C.1 · p. 30

C.2 WHAT “COVERAGE-WEIGHTED” AGGREGATION MEANS

  • Coverage-weighted aggregation means averaging datapoints within each ground-truth workflow family, then weighting represented families equally.Workflow families govern replay aggregation; failure families index candidate patches and their quotas.Source: §C.2 · p. 30

C.3 WHEN THE CORRECTNESS CONSTRAINT BECOMES BINDING

  • Across 20 logged decisions, no candidate fails only the correctness condition, making it a latent safeguard rather than an additional source of rejections in this trace.Its incremental decision value would require candidates where the reward and correctness conditions disagree.Source: §C.3 · p. 30

D SEGMENTED PROMPT POLICY: BASE TEXT AND ACCEPTED DELTAS

  • The audit shows the four-patch Coverage-Adaptive sequence F3a, F6c, F6b, and F6d; only REQ UNDERSTANDING, TOOL USE, and EDIT are modified.The remaining four segments are identical to π0, and the displayed service names are functional aliases.Source: D SEGMENTED PROMPT POLICY: BASE TEXT… · p. 30

D.1 REQ UNDERSTANDING (MODIFIED BY F6B)

  • F6b is appended to the otherwise unchanged REQ UNDERSTANDING segment.Source: §D.1 · p. 30

D.2 TOOL USE (MODIFIED BY F6C)

  • F6c adds a resolve-before-fill requirement to the existing TOOL USE contract.Source: §D.2 · p. 31

D.3 EDIT (MODIFIED BY F3A AND F6D)

  • F3a and F6d are appended to EDIT in acceptance order, leaving its base text unchanged.All four updates are additive and segment-scoped, so each can be reviewed, attributed, and rolled back patch by patch.Source: §D.3 · p. 32, §D.4 · p. 32

E CASE STUDY: A LOCALLY HELPFUL PATCH WITH A DESTRUCTIVE INTERACTION

F2a looked beneficial under the iteration-start policy but was rejected after replay against the accepted prefix; the trace explains how preserving plausible identifiers can suppress revalidation. The section also outlines broader tests and tuning left for future work.

E CASE STUDY: A LOCALLY HELPFUL PATCH WITH A DESTRUCTIVE INTERACTION

  • F2a passed the shared-parent pre-filter at Δtrain = +0.0465 but was rejected after replay on the accepted prefix.Table 20 reports the marginal replay effect of appending F2a to that four-patch prefix.Source: E CASE STUDY: A LOCALLY HELPFUL PATCH… · pp. 32–33, Table 20 · p. 32
  • Preserving identifiers already present in corrupted input can suppress F6c’s revalidation, allowing stale values to cause publication failures.F6c requires every referenced resource to resolve to a concrete value; F2a exempts identifiers already present in the input.Source: E CASE STUDY: A LOCALLY HELPFUL PATCH… · p. 33
  • The trace demonstrates policy-context dependence, but does not establish F2a’s isolated replay effect or the interaction’s population frequency.Commit-time evaluation should use the policy state in which the patch would persist.Source: E CASE STUDY: A LOCALLY HELPFUL PATCH… · p. 33

F FUTURE WORK

  • Stronger confirmation would use a request-disjoint pool, more ground-truth families, independent environments, and paired uncertainty estimates for reruns.The proposed analyses include threshold sweeps, leave-one-patch-out attribution, cumulative replay budgets, and sequential reuse of a development pool.Source: F FUTURE WORK · p. 33
  • Future evaluation could add public execution-graded environments and compare full systems or prompt optimizers to isolate diagnosis, segmentation, and replay-constrained persistence.Named examples include ALFWorld, τ-Bench, SWE-bench Verified, GRASP, SkillGen, SkillOpt, GEPA, MIPROv2, OPRO, and TextGrad.Source: F FUTURE WORK · p. 33
  • Because the study starts from one human-authored π0, sweeps over minimal, generated, and expert initial policies could test initialization dependence.A deployment study could also track which adapted patches transfer, become redundant, or require reversal across backbone upgrades.Source: F FUTURE WORK · p. 33
  • Gemma and Ministral transfer results use Haiku’s shared configuration, not backbone-specific tuning, so the residual gap is not a method ceiling.The study leaves the possible gains from backbone-specific patch libraries, replay composition, and recalibrated gate tolerances unmeasured.Source: F FUTURE WORK · p. 33
Loading 2609.12127v1…