Iterative Patching Protocol Overview

• Iterative patching protocol is a repair methodology that employs repeated cycles of diagnosis, proposal, validation, and refinement to generate and improve software patches.
• It is applied across various domains such as automated program repair, continuous vulnerability repair, and firmware updates, optimizing patch performance via feedback loops.
• The protocol balances depth and breadth by integrating multiple feedback signals and collaborative agent systems to enhance repair reliability and manage operational constraints.

Searching arXiv for papers on iterative patching protocols and related automated repair systems. arXiv search query: "iterative patching protocol automated program repair vulnerability repair LLM" Iterative patching protocol is a repair methodology in which patch generation is embedded in a repeated control loop of diagnosis, proposal, validation, and refinement rather than treated as a one-shot act. In the literature, the loop is instantiated in several distinct ways: test-suite–based automatic program repair for Java, continuous vulnerability repair downstream of fuzzing, concurrent execution of patched and unpatched software in production-like environments, OTA firmware deltas for low-power devices, hotpatch synthesis for real-time embedded systems, and rule-based repair of security protocols from formal attack traces (Ruiz et al., 5 May 2025, Kim et al., 24 Jan 2026, Groš et al., 2021, Salehi et al., 2024, Simone et al., 19 May 2025, Hutter et al., 2013). Across these settings, the protocol differs in feedback source and deployment substrate, but it consistently treats intermediate repair states as actionable objects rather than terminal failures.

1. Definition and recurrent structure

A common abstraction across the cited work is an iterative cycle of validation-driven update. In LLM-based automated patching, the cycle is explicitly described as repeated phases of reasoning about the bug, proposing or editing a patch, validating it, and analyzing the feedback (Xu et al., 1 Mar 2026). In test-suite–based APR, the loop is driven by compiler outcomes, failing tests, and patch budgets (Ruiz et al., 5 May 2025). In formal security-protocol repair, the loop is verify $\to$ extract attack $\to$ diagnose $\to$ apply repair rule $\to$ verify again (Hutter et al., 2013). In deployment-time validation, the loop is deploy patch in shadow, compare outputs under real workload, monitor discrepancies, estimate residual risk, and then switch or continue (Groš et al., 2021).

A concise cross-domain summary is given below.

Setting	Iterative unit	Feedback signal
Test-suite APR	Patch candidate or partial patch	Compiler errors, failing tests, timeout
Continuous vulnerability repair	Crash task and candidate patch	PoV reproduction, functional tests, deduplication outcomes
Shadow deployment	Patched replica under mirrored traffic	Response differences against Main
Embedded hotpatching	Triggered hotpatch at trampoline	Runtime control-flow outcome, dispatcher result
Security-protocol repair	Canonical protocol step	Attack bundle and confusion diagnosis

This recurrent structure does not imply a single algorithm. Some systems iterate over successive textual prompts, some over search states in a repair tree, some over queues of crashes and patches, and some over protocol transformations. A plausible implication is that “iterative patching protocol” is best understood as a family of control strategies rather than a single repair model.

2. Test-driven iterative repair in automated program repair

The most explicit formulation appears in "The Art of Repair" (Ruiz et al., 5 May 2025). The setting is test-suite–based APR for Java on HumanEval-Java and the 217 single-hunk-bug subset of Defects4J v2. For each bug, the faulty region is marked with <bug_start> and <bug_end>, and the model must return the fixed complete method. Candidate patches are classified as Plausible, Wrong, Timeout, or Uncompilable after compilation and execution of the benchmark’s unit tests. The primary metric is the number of problems for which at least one plausible patch is found within a patch budget.

The protocol imposes a strict budget $N_{\max}=10$ per bug, with

$n_o + i \cdot n_i \leq N_{\max}=10.$

Here, $n_o$ is the number of outputs in the initial generation, $i$ the number of iterative rounds, and $n_i$ the number of outputs in each subsequent round. One-shot repair corresponds to Strategy A $(10\times1)$, while iterative variants allocate some of the budget to feedback-driven depth: B $\to$0, C $\to$1, D $\to$2, E $\to$3, F $\to$4, and G $\to$5. After each non-plausible patch, the system extracts either one failing or timing-out test and its source code, or compiler errors, and appends this execution feedback to the next prompt. To avoid combinatorial explosion, only the first generated patch is refined in later rounds (Ruiz et al., 5 May 2025).

The empirical result is not that more iteration is universally better. Base models benefit strongly from feedback, particularly on Defects4J. A concrete example is Llama3.1 Base on Defects4J, which rises from 28 plausible bugs with Strategy A to 74 plausible bugs with Strategy F $\to$6 (Ruiz et al., 5 May 2025). Fine-tuned models behave differently. On HumanEval-Java with Strategy A, Full Fine-Tuning on only 1K examples raises CodeLlama from 60 to 107 plausible bugs, DeepSeek-Coder from 76 to 129, and Llama3.1 from 68 to 108, corresponding to gains of $\to$7, $\to$8, and $\to$9 respectively (Ruiz et al., 5 May 2025). The same study reports that $\to$0 of the fine-tuning dataset suffices to roughly double or triple repair performance versus the base models, but larger FFT datasets often plateau or degrade, with the paper attributing this to likely overfitting (Ruiz et al., 5 May 2025).

"ITER: Iterative Neural Repair for Multi-Location Patches" extends the iterative idea from prompt-level refinement to search over partial patches and fault-localization states (Ye et al., 2023). ITER treats uncompilable or partially successful outputs as partial patches rather than discarding them. If a patch reduces the failing-test count, fault localization is re-run on the modified program, and the next patching step may target a different location, allowing construction of multi-location patches. Its search is bounded by beam width $\to$1, top-50 suspicious locations, and maximum inference iterations $\to$2, with a theoretical maximum of $\to$3 candidates per location after $\to$4 iterations. On 476 Defects4J 2.0 bugs, ITER produces 76 correct patches and 119 plausible patches, and repairs 17 multi-location bugs, including uniquely repaired cases such as Closure-79 (Ye et al., 2023). This suggests that iterative patching can operate not only over successive textual fixes, but also over evolving program states and evolving fault-localization hypotheses.

3. LLM orchestration, architecture, and iteration depth

Iterative patching in LLM-based vulnerability repair is not limited to a single-agent feedback loop. "PatchIsland" organizes iteration at the system level through a COORDINATOR, multiple WORKERS, sequential agent execution on each worker, and two-phase patch-based deduplication (Kim et al., 24 Jan 2026). When a crash arrives, the COORDINATOR first checks whether any stored patch already resolves it; unresolved crashes enter a dispatch queue. A worker then runs a sequence of agents according to FP2 orchestration, each agent performing its own loop of context gathering, patch generation, build, PoV reproduction, and functional testing. Plausible patches are returned to the COORDINATOR, which then performs patch-side deduplication and queue pruning. The core handlers are given as OnCrashReceived and OnPatchGenerated, where new patches both remove already-fixed crashes from the queue and may subsume earlier patches (Kim et al., 24 Jan 2026).

PatchIsland’s architecture makes iteration continuous rather than benchmark-static. In internal evaluation it repaired 84 of 92 vulnerabilities; in the AIxCC competition it patched 31 out of 43 vulnerabilities for a repair rate of $\to$5 (Kim et al., 24 Jan 2026). The same paper reports 84/92 patched overall for PatchIsland, versus 16/92 for ROBODUCK and 57/92 for BUTTERCUP, with a 0% error rate for PatchIsland’s infrastructure execution (Kim et al., 24 Jan 2026). Its reported design principle is that patch-based deduplication is the backbone of iteration in continuous vulnerability repair.

"A Systematic Study of LLM-Based Architectures for Automated Patching" compares four paradigms under a common Java vulnerability benchmark: fixed workflow, single-agent, multi-agent, and general-purpose code agent (Xu et al., 1 Mar 2026). The benchmark contains 19 delta-scan Java vulnerabilities from AIxCC. Patch correctness is defined by successful build, PoV neutralization, and passing functional tests. The reported success counts are 12/19 for Single Agent with GPT-5 and 13/19 with Sonnet-4.5, 13/19 for Multi-Agent with GPT-5 and 8/19 with Sonnet-4.5, 12/19 for Fuzzing-Brain fixed workflow with GPT-5 and 10/19 with Sonnet-4.5, and 16/19 for Claude Code as the general-purpose code agent (Xu et al., 1 Mar 2026).

The principal conclusion is that architectural design and iteration depth, rather than model capability alone, dominate reliability and cost (Xu et al., 1 Mar 2026). The paper describes non-linear behavior of iteration depth: shallow iteration often suffices on simple tasks, whereas deep loops may help on hard tasks but can also induce reasoning drift, particularly in multi-agent shared-state systems (Xu et al., 1 Mar 2026). This complements the APR findings in (Ruiz et al., 5 May 2025): optimal depth is conditional on model state, task complexity, and the structure of the controller.

4. Deployment-time and runtime instantiations

Iterative patching protocols also appear outside offline APR. "Controlled Update of Software Components using Concurrent Exection of Patched and Unpatched Versions" proposes a shadow-mode deployment protocol in which the unpatched Main instance remains authoritative, while a patched instance receives adjusted copies of the same requests and its outputs are used only for comparison (Groš et al., 2021). The protocol has a learning mode, in which two identical unpatched instances are used to derive rules for expected differences, and a comparison mode, in which the patched version replaces one instance and unexpected differences raise alarms. Promotion is deferred until monitoring under real traffic yields sufficient confidence that the patch has not introduced regressions.

The same paper introduces a probabilistic reliability sketch. If $\to$6 is the time from start of concurrent execution to the next bug-induced difference and $\to$7, then

$\to$8

and the probability of no new differences in the next $\to$9 units of time is approximated by

$\to$0

This is not patch generation, but it is an iterative patching protocol in the sense that patch acceptance is driven by repeated differential validation under live workload rather than a one-time test pass (Groš et al., 2021).

"AutoPatch" moves iteration into runtime hotpatching for embedded RTOS systems (Salehi et al., 2024). Its protocol is “instrument once; hotpatch many times”: an Instrumentation Component inserts trampolines at function entrances, after function calls, and inside and after complex loops and branches, and an Analysis Component later maps each official C/C++ patch to a functionally equivalent hotpatch associated with one of those trampolines. The runtime dispatcher performs a binary search over up to 64 active patches keyed by trampoline address. AutoPatch hotpatched 56 of 62 real CVEs, fixed more than 90% of them, reported average total delay of less than $\to$1, and average memory overhead slightly lower than RapidPatch’s 23% (Salehi et al., 2024). The protocol is iterative because new hotpatches can be added over time without reflashing or rebooting the instrumented firmware.

For low-power IoT firmware, "Incremental Firmware Update Over-the-Air for Low-Power IoT Devices over LoRaWAN" frames patching as repeated application of binary deltas $\to$2 (Simone et al., 19 May 2025). The server computes a compact COPY/ADD bitstream patch; the device reconstructs the new image by single-pass interpretation of the patch, keeping the old firmware intact until validation and reboot. The experiments show $\to$3 average compression for minor updates, FUOTA time reductions of $\to$4 to $\to$5, and radio-energy reductions of $\to$6 to $\to$7 compared with full-image updates (Simone et al., 19 May 2025). The paper explicitly notes that the method supports repeated updates over time and can be viewed as an iterative patching protocol over firmware versions.

5. Validation semantics, correctness, and failure modes

A central issue across iterative patching protocols is that acceptance criteria are usually operational rather than semantic. In the APR setting of (Ruiz et al., 5 May 2025), a plausible patch is defined purely by compilation and passing all tests; correctness beyond the tests is not guaranteed. The authors manually checked 3,298 plausible patches and found 131 overfitting patches (Ruiz et al., 5 May 2025). ITER likewise distinguishes plausible from correct patches, with correctness determined by identity to developer or community-reviewed patches, or by manual judgment of semantic equivalence (Ye et al., 2023).

PatchIsland uses build success, PoV non-reproduction, and functional tests as its plausibility criterion, but its postmortem shows that plausibility remains weaker than correctness (Kim et al., 24 Jan 2026). For intended vulnerabilities, it produced 1/33 plausible-but-incorrect patch; for unintended vulnerabilities, 10/14 patches were plausible but incorrect (Kim et al., 24 Jan 2026). The documented example is a patch that catches ArrayIndexOutOfBoundsException and returns null rather than fixing the underlying parsing bug, illustrating symptom suppression rather than semantic repair.

The deployment-time shadowing protocol in (Groš et al., 2021) exposes a related limitation from the opposite direction: intentional behavioral changes caused by a correct patch will also appear as differences and must be triaged manually. The formal security-protocol framework in (Hutter et al., 2013) addresses correctness differently. There, the repair loop is grounded in strand spaces, canonical bundles, attack bundles, and explicit repair rules—message encoding, agent naming, and session binding—applied only when their formal preconditions hold. This does not provide absolute completeness, but it does shift validation from empirical test passing to proof-guided elimination of specific attack classes (Hutter et al., 2013).

Stopping conditions likewise vary by domain. The APR controller in (Ruiz et al., 5 May 2025) stops when a plausible patch is found or the total number of generated patches reaches 10. ITER stops on plausible repair, exhausted search branch, or maximum inference depth $\to$8 (Ye et al., 2023). PatchIsland stops per crash when some agent finds a plausible patch or all agents fail (Kim et al., 24 Jan 2026). Shadow deployment stops when estimated risk becomes acceptable or discrepancies trigger revision (Groš et al., 2021). These are all iterative protocols, but they optimize different notions of sufficiency.

6. Design tensions and broader significance

The literature converges on several recurring design tensions. One is breadth versus depth. In APR under a tight budget, one-shot breadth and iterative depth are not substitutes but competing uses of the same finite budget; the best allocation depends on model strength and benchmark complexity (Ruiz et al., 5 May 2025). Another is specialization versus generality. Multi-agent patchers and continuous CVR systems encode explicit roles such as context retrieval, root-cause analysis, validation, and reflection, whereas general-purpose code agents rely on a broader tool interface and developer-like adaptation (Xu et al., 1 Mar 2026). A third is static batch evaluation versus continuous operation. PatchIsland treats automated repair as a persistent service with a coordinator, workers, crash queues, and patch repositories rather than a single benchmark run (Kim et al., 24 Jan 2026).

The cited work also shows that iteration need not mean repeated prompting alone. It may mean re-running fault localization after a partial fix (Ye et al., 2023), deduplicating crashes and merging subsuming patches over time (Kim et al., 24 Jan 2026), maintaining concurrent patched and unpatched instances until probabilistic risk falls below a policy threshold (Groš et al., 2021), dispatching newly generated hotpatches through pre-inserted trampolines without reboot (Salehi et al., 2024), or repeatedly generating binary deltas between successive firmware versions for low-power devices (Simone et al., 19 May 2025). In security-protocol repair, it means alternating between verifier-generated attacks and local, semantics-preserving rule applications (Hutter et al., 2013).

Taken together, these results support a general characterization: an iterative patching protocol is a control discipline for repair under feedback, budgets, and incomplete observability. The specific state being iterated over may be a natural-language prompt, a partial patch, a ranked fault-localization set, a crash queue, a shadow deployment, a firmware version graph, or a canonical protocol bundle. What unifies the concept is the replacement of single-pass patch generation with a bounded, feedback-conditioned succession of repair states whose acceptance is mediated by tests, differential execution, runtime validation, or formal analysis (Ruiz et al., 5 May 2025, Xu et al., 1 Mar 2026, Hutter et al., 2013).