arXiv CSopen access

AuditCoder: Responsibility-Preserving Task Graphs for Auditable Code Generation and Bounded Repair

AuditCoder: Responsibility-Preserving Task Graphs for Auditable Code Generation and Bounded Repair Kangjie Huang, Chen Lyu∗ School of Computer Science and Artificial Intelligence, Shandong Normal University [email protected], [email protected]

arXiv:2607.29529v1 [cs.SE] 31 Jul 2026

Abstract Code generators return programs, but typically do not preserve the construction record needed to connect a failure to the decision that produced the affected code or to delimit a justified repair. We present AuditCoder, which treats the program and an auditable construction trace as joint outputs. Before code generation, a contract-annotated task graph assigns stable responsibility identities that remain attached to each commitment, its owned implementation, provenance, validation evidence, and intervention history. When validation fails, a conservative locator maps heterogeneous evidence to a node or dependency branch—or abstains—and bounded repair regenerates only that region while reusing the frozen complement. On APPS, AuditCoder reaches 82.5–83.0% pass@1, recovering much of the loss caused by unrepaired graph decomposition but trailing AgentCoder by 7.5–8.5 points. On ClassEval, it reaches 75.0–82.0%, outperforming CoT + retry while remaining below AgentCoder. A separate audit of 200 APPS records yields 0.9725 task-macro decision–code trace coverage; the locator identifies an evidence-supported node or branch for 26 of 60 failures, and 17 of those localized repairs pass. For tasks with stable, locally testable boundaries, the graph functions not only as a decomposition structure but also as a persistent index for validation and repair. Code and project resources: https://github.com/puppet0x3f/AuditCoder

1

Introduction

AI-assisted code is entering software projects at scale, but the resulting code can be difficult to review and repair. A 2026 SonarSource survey of 1,149 professional developers (SonarSource 2026) reports that respondents attributed 42% of committed code to AI generation or assistance; 96% did not fully trust its functional correctness, and 38% reported greater review effort than for human-written code. The survey does not directly measure productivity, but it highlights an operational question: once generated code fails, which construction decision produced the affected code, and what region does the available evidence justify changing? Most generation pipelines do not preserve this link. Planning may expose subgoals and interfaces, but later assembly often erases which commitment owns which code. One commitment may span several helpers or non-contiguous ∗

Corresponding author.

a

b Explicit generation-time commitments (not persisted)

c

Generated program

Failure evidence and repair Failing test

1 def min_cost(days, costs):

C1

Normalize days

days=[1,7], costs=[3,4,20] expected=4, got=6

2 days = sorted(days) 3 dp = [0] * (len(days)+1) 4 p7 = p30 = 0

C2

Define DP state

C3

Advance pass windows

C4

Update DP and return

5 for t, d in enumerate(days, 1): 6 while days[p7] <= d - 6: 7 p7 += 1 8 while days[p30] <= d - 29: 9 p30 += 1

bug

Post-hoc suspicious set DP state?

window logic?

transitions?

input handling?

10 dp[t] = min(dp[t-1]+costs[0], 11 dp[p7]+costs[1], 12 dp[p30]+costs[2]) 13 return dp[-1]

Diagnosis, patch, or retry Can improve the current artifact, but does not recover the executed construction responsibility.

Plan text has no durable code owner

Missing lifecycle link: stable responsibility ID -> owned code -> evidence -> repair history

Figure 1: Decision–code responsibility misalignment. Planning may expose explicit commitments, but the generated program does not preserve which commitment owns which code. Failure evidence can identify suspicious code without revealing the responsible construction record or a justified repair boundary.

statements, and one function may implement several commitments. As Figure 1 illustrates, a failing test therefore identifies a symptom rather than the generation-time responsibility behind it or a justified repair boundary. We call this gap decision–code responsibility misalignment. Preserving this link requires a durable responsibility unit: a planned subproblem whose goal, interface, inputs and outputs, owned implementation, validation evidence, and revisions share one stable identifier. AuditCoder represents these units as task-graph nodes. We call a run processauditable when the identifiers are assigned before implementation is generated and reused during generation, assembly, validation, localization, and repair. A recorded decision is an external system commitment—for example, a subgoal, interface, algorithmic responsibility, or complexity budget— rather than latent chain-of-thought. A reviewer can then trace code to the commitment and evidence under which it was produced, while the system can reuse the same address to delimit later repairs. Constructing such records before code exists raises three challenges. ❶ Defining responsibility units before implementation. The planner must commit an initial graph whose nodes are specific enough to own implementations and expose dependencies, interfaces, provenance, complexity budgets, and lo-

cal checks. Coarse nodes weaken localization; overly fine nodes add interface overhead and may split a global invariant across locally plausible components. Later graph changes must therefore be explicit revisions rather than silent goal drift. ❷ Preserving ownership through generation and assembly. Algorithm-specialized agents can implement leaf nodes, but an agent role does not establish code ownership. Every generated function or helper must belong to exactly one responsibility node, while one node may own several code units. Assembly must preserve dependency order, interface contracts, and provenance-consistent data flow; cross-node edits must expand the transaction boundary and be recorded. ❸ Turning evidence into a defensible repair boundary. Failures may arise from one node, a dependency branch, or a graph-level assumption. Compilation results, examples, differential checks, contract and complexity checks, counterexamples, and resource signals provide evidence of different strengths. The system must map this evidence back to the construction-time responsibility units, repair only a supported node or branch, and abstain when no stable boundary can be justified. Prior work supplies many of these ingredients separately. Planning and modular-synthesis methods create plans or candidate components (Zhang et al. 2023; Jiang et al. 2024; Zelikman et al. 2023; Chen et al. 2024a); role-specialized agents divide planning, coding, testing, and debugging (Huang et al. 2023; Islam, Ali, and Parvez 2024); feedback, repair, traceability, and verification methods provide diagnostic or property evidence. These methods do not generally require one pre-code unit to remain the address for the selected implementation, its validation evidence, repair scope, and revision history. The repair target is therefore commonly reconstructed from the finished artifact rather than retrieved from the construction record. AuditCoder makes the responsibility unit persistent through a contract-annotated task graph. Before leaf generation, the Plan Agent commits the initial graph and stable IDs. Each node records its goal, contract, provenance, complexity budget, and local validation requirements; algorithm agents generate node-owned code, and an ownership map preserves these assignments during assembly. Local and global evidence is stored under the same IDs. After failure, a conservative locator returns an evidence-supported node or branch, or abstains. Bounded repair regenerates the selected region, reuses the frozen complement, records cross-node integration exceptions, and appends the transaction to the same history. The graph is a recorded construction hypothesis rather than proof of a correct decomposition; tightly coupled tasks may require a coarser unit, graph revision, or abstention. The evaluation covers algorithmic, class-level, and small exploratory cross-domain Python tasks, but not repository-scale audit chains. Figure 2 summarizes the lifecycle. The evaluation asks whether evidence-guided repair recovers accuracy lost to auditable decomposition and whether the retained records support bounded intervention. On APPS (Hendrycks et al. 2021), task planning alone is fragile: in the matched Qwen setting, algorithm-specialized agents

raise pass@1 from 62.5% to 70.0%, and evidence-guided repair raises it to 83.0%. AuditCoder remains below AgentCoder on APPS and ClassEval (Du et al. 2024), but exceeds CoT + retry on ClassEval. The 200-record process audit reveals a sharper limitation: although final task-macro trace coverage is 0.9725, only 26 of 60 failures yield an evidencesupported node or branch. Because APPS provides no nodelevel root-cause labels, this is coverage rather than localization accuracy. The gap between retained records and usable localization suggests that the current bottleneck is evidence strong enough to justify a repair boundary, not record persistence. Contributions. ❶ We identify decision–code responsibility misalignment and define process auditability as lifecycle continuity from an explicit planning commitment to its owned code, validation evidence, and repair history. ❷ We introduce AuditCoder, whose contract-annotated task graph assigns responsibility IDs before generation, preserves code ownership and provenance through assembly, and supports evidence-based node/branch localization, frozen-complement repair, explicit integration exceptions, and abstention. ❸ We evaluate AuditCoder on APPS and ClassEval and conduct a separate 200-record process audit, quantifying functional recovery, trace retention, localization coverage, repair success, and the limits imposed by tightly coupled tasks.

2

Related Work

Planning, decomposition, and modular synthesis. Planning-guided decoding combines an LLM with lookahead search over candidate programs (Zhang et al. 2023), while self-planning externalizes solution steps before implementation (Jiang et al. 2024). Parsel (Zelikman et al. 2023) searches test-satisfying combinations of implementations described by a function hierarchy, and FunCoder (Chen et al. 2024a) introduces sub-functions during generation and uses functional consensus. These methods use decomposition to guide search or compose modular programs. In AuditCoder, the distinction is the component’s lifecycle: a responsibility identity is allocated before code and remains the address for the selected implementation, validation evidence, and later repair transactions. Role-specialized generation. AgentCoder (Huang et al. 2023) separates programming, test design, and test execution; MapCoder (Islam, Ali, and Parvez 2024) separates retrieval, planning, coding, and debugging. Such roles determine who acts, but not which unit persistently owns the emitted code. AuditCoder also routes leaf units to algorithm-specialized generators, yet the responsibility node—not the agent role— owns the implementation and indexes its contract, evidence, and history. The routing labels are execution categories rather than a learned skill ontology. Execution feedback, debugging, and repository repair. CodeT (Chen et al. 2023) uses generated tests and execution agreement for selection. Self-Debugging (Chen et al. 2024b), CRITIC (Gou et al. 2024), and Reflexion (Shinn et al. 2023) feed explanations, tool critiques, or reflections

into later attempts; LDB (Zhong, Wang, and Shang 2024) inspects executed basic-block states, and classical fault localization (Jones and Harrold 2005; Wong et al. 2016) ranks suspicious program entities. Repository-level systems such as SWE-agent (Yang et al. 2024), RepairAgent (Bouzenia, Devanbu, and Pradel 2025), AutoCodeRover (Zhang et al. 2024), Agentless (Xia et al. 2025), and SpecRover (Ruan, Zhang, and Roychoudhury 2025) localize, patch, and validate existing projects. These methods derive repair targets from tests, code, issue context, or execution evidence. AuditCoder instead asks whether the target can be retrieved from a responsibility record created with the code. Repository agents cover broader artifacts; the comparison here concerns construction provenance.

The trace enforces three invariants. Pre-code identity assigns idi before implementation is sampled. Ownership and evidence binding maps each registered executable unit and its evidence to one responsibility address. Identity-preserving intervention confines regeneration to an evidence-supported region, reuses the frozen complement, and appends the transaction. These are pipeline constraints, not a reconstruction of latent reasoning. Figure 2 and the subsections follow this order. In the example, S2 is created before code, later owns c2 and r2 , and is selected while S1 and S3 are frozen. Appendix B.1 gives the complete procedure.

Traceability and formal evidence. CodePlan (Bairi et al. 2024) models repository dependencies and edit impact. Code Gradients (North, Atapour-Abarghouei, and Bencomo 2024) and R2Code (Wang et al. 2026) recover requirement–code correspondences, while Wang et al. (2025) and Barrak (2025) study traceability or accountability in LLM pipelines. These links need not retain the selected candidate, execution evidence, and intervention sequence. Formal workflows provide stronger property evidence: Clover (Sun et al. 2024) closes a generation–verification loop, DafnyBench (Loughridge et al. 2025) evaluates formally verifiable generation, and AutoVerus (Yang et al. 2025) generates Rust proofs. Property evidence does not reconstruct the construction path, while construction provenance does not establish the verified property.

The planner commits an intermediate representation before node-local generation:

Positioning. The common comparison axis is when an addressable unit is created and what remains attached to it. AuditCoder creates a responsibility unit before code generation and reuses its identity for owned code, validation evidence, and intervention history. A localization result can therefore constrain execution: the selected node or branch may change, boundary expansion is recorded, the complement is reused, and unsupported localization leads to abstention. The contribution is this lifecycle continuity, not decomposition, multi-agent execution, testing, localization, traceability, or verification in isolation.

3

Method

Overview. Given a natural-language programming task x, AuditCoder returns an executable program y together with a structured construction trace A: (y, A) = AuditCoder(x),

A = (G, S, E, H).

Here G is the contract-annotated task graph, S contains responsibility records, E stores validation evidence, and H is the append-only repair history. For implementation node vi , the record is si = (idi , gi , ai , Fi , ci , ρi , ri , hi ), where gi is the generation-time commitment, ai is the routed executor, Fi is the interface contract, ci is the node-owned implementation bundle, ρi is variable provenance, ri is local evidence, and hi references interventions. The executor records who acts; idi remains the responsibility address.

3.1

Contract-Annotated Task Graph

I = Π(x) = (P, B, G, Q),

G = (V, D, T ).

Here P stores parsed input/output constraints, B algorithmic assumptions and complexity targets, Q program-level validation requirements, V the nodes, D their dependencies, and T a topological order. Existing IDs cannot be silently repurposed; later structural changes are recorded as graph deltas in repair transactions. Each node is a responsibility unit: vi = (idi , gi , τi , Xi , Yi , Fi , ρi , Ci , qi ), Fi = (namei , argsi , reti , prei , posti , invi ). Here τi is an algorithm-routing category, Xi , Yi are input/output variables, Ci is the complexity budget, and qi is the local validation requirement. The routing category guides agent selection but is not the audit identity. The provenance map ρi records whether a variable comes from the task, an upstream node, or a local intermediate. U ⊆ V contains code-owning nodes: usually leaves, but also internal nodes that own orchestration code. The contract combines machine-checkable interface fields with semantic obligations. Function names, typed arguments, return schemas, dependencies, and complexity probes can be checked directly. Natural-language pre/postconditions and invariants become executable evidence only when instantiated as tests, assertions, static checks, or proof obligations. The experiments use execution-based tests and contract checks, although the schema can also store static or formalanalysis results. Appendix B.3 gives a serialized instance. These fields constrain generation and define what evidence can be attributed to the node.

3.2

Node-Local Generation and Assembly

For each vi ∈ U, the router chooses an executor, the executor produces only node-owned code, and the local verifier returns structured evidence: ai = Route(vi , M, B), ci ← Generate(ai , gi , Fi , Xi , Yi , ρi , Ci , B), ri = VerifyLocal(ci , Fi , qi , Ci ). The router may use τi to select an algorithm-specialized agent, but ownership remains attached to idi . Local evidence

1. Plan-time responsibility IDs

2. Node-owned code and evidence

Initial graph

S0

S1

3. Evidence-addressed repair

Responsibility record S2 Commitment

S2

S3

Failure evidence wrong_answer expected 4, got 6

advance pass-window pointers

Interface

advance_windows(days,t,d) -> p7,p30

Code C2

while days [p7]

Provenance

days <- S1; d,t <- loop state

Evidence r2

boundary test rejected

Conservative locator evidence -> S2 unsupported -> abstain

Selected region and frozen complement

<= d - 6: . . .

S0

Representative responsibility node

S1

Assembly and global validation

ID S2 - maintain 7/30-day windows Commitment: advance first uncovered day Interface: advance_windows(days, t, d) Contract: preserve days within pass window Owner: node S2; nodes may not modify its code

S1:c1

S2:c2

S3:c3

Lifecycle invariant:

S2

Before c2 window condition: days [p7] <= d - 6

S0:program y

S2 Owned code

Plan

S2

S3 After c2' window condition: days [p7] < d - 6

PASS program y reuse S1,S3 unchanged append h = (e, S2, delta, c2, result)

test: expected 4, got 6

Identity exists before code generation

S2

Evidence

S2 Repair History

Figure 2: Overview of the responsibility-preserving lifecycle in AuditCoder. Before code generation, the planner assigns stable responsibility identities and node-level contracts. During node-local generation and assembly, every registered function or helper is owned by one responsibility node, and validation evidence is indexed by the same identity. After a failure, the locator selects an evidence-supported node or dependency branch, or abstains; only the selected region is regenerated, the frozen complement is reused, and the repair event is appended to the same responsibility record. The figure illustrates identity continuity and stable code ownership, not a semantic one-to-one mapping between decisions and statements. may include compilation status, examples, generated boundary cases, interface checks, contract assertions, and resource probes. A passing record is test-validated: it records successful checks rather than formal correctness. Every registered function or helper is entered in an ownership map µ : Funreg → U,

µ(f ) = vi .

The map is total over registered units and assigns each exactly one owner. A bundle ci may contain several functions, helpers, or non-contiguous statements, which inherit the node’s ownership; no one-to-one decision–span correspondence is assumed. Node-local generation cannot silently rewrite another node’s code. If assembly requires such a change, an integration exception records the parent, affected child, rationale, and region, and expands the transaction boundary. The assembler then constructs y = Ω(G, {(vi , ci )}vi ∈U ) while enforcing dependency order and provenanceconsistent arguments. Global validation produces an additional evidence record: rg = Execute(y, Q),

E = {rg } ∪ {ri }vi ∈U .

The global record contains pass/fail status, traceback frames, observed and expected outputs, resource signals, and failed contract checks. Node addresses and µ make this evidence usable for responsibility localization rather than only wholeprogram retry.

3.3

Evidence-to-Responsibility Localization

When global validation fails, the locator combines global evidence, node-local records, and the ownership map: z = Locate(rg , G, {ri }vi ∈U , µ) ∈ {⊥} ∪ (V × M × Rloc × C × E) , where Rloc is the rule-label set and C a discrete confidence scale. z = ⊥ denotes abstention; otherwise, z = (v̂, â, m, κ, ê), where v̂ is the selected node, â its routed agent, m the rule label, κ the confidence level, and ê the supporting evidence. Rules follow a fixed priority. R1: Traceback. A registered frame f maps to µ(f ) with high confidence. R2: Resource evidence. A timeout or memory failure maps to the narrowest node or branch supported by its complexity budget, resource probes, and ownership of implicated loops or data structures; incomparable candidates cause abstention. R3: Local rejection. A rejected boundary case, interface check, or invariant selects its node with low-to-medium confidence when compatible with the global failure. R4: Abstention. Graph-level or otherwise insufficient evidence returns ⊥. In Figure 2, the wrong answer is compatible with the boundary-case rejection stored under S2, so R3 selects S2; without such node-addressed evidence, the outcome is abstention. The result is an evidence-supported region, not a ground-truth cause, which is why Section 4.3 reports localization coverage rather than accuracy.

3.4

Evidence-Guided Bounded Repair

For z = (v̂, â, m, κ, ê) ̸= ⊥, AuditCoder selects an evidence-supported region. Node repair applies to one implementation node; branch repair applies when a strategy,

interface, or decomposition error is shared by a dependency branch:  {v̂}, Node, R(z) = Subtree(EB(z); G), Branch, F(z) = V \ R(z). Here EB(z) is the branch root and F the frozen complement. For v0 → v1 → · · · → vℓ = v̂, the default root is the first non-root ancestor v1 , narrowed to a deeper ancestor when supported. This permits branch replanning without defaulting to whole-program regeneration. The repair operator updates only the selected region: ′ GR , {c′i , ri′ }vi ∈R∩U = Repair(GR , {ci , ri }vi ∈R∩U , z) .

Node repair keeps the interface fixed unless evidence indicates a mismatch. Branch repair may replan internally, but external inputs, outputs, return types, and downstream call sites must remain compatible with F. Integration exceptions expand R before regeneration; no edit silently crosses the frozen boundary. The repaired artifact is assembled as
y ′ = Ω G ′ , {c′i }vi ∈R∩U ∪ {ci }vi ∈U \R , subject to the preservation invariant ∀vi ∈ F ∩ U,

c′i = ci .

After revalidation, the candidate is compared with the prerepair state using the recorded strict-improvement policy over full pass, external and internal passes, and clean exits. An improving candidate is accepted; otherwise, the persisted snapshots of assembled code, node snippets, and test results are restored. Let d record the accept/reject decision and σ the rollback status. The transaction h = (z, R, F, ∆G, ∆c, rg′ , d, σ) is appended to H and referenced by affected-node histories hi . The enforced property is scope preservation, not global minimality: regeneration is confined to expanded R and the frozen complement is reused unchanged. Appendix E specifies the recorded decision and rollback fields. If z = ⊥, bounded repair stops. A separately logged global fallback may follow, but it lies outside the frozencomplement guarantee and is reported separately in Sections 4.3 and 4.4.

4

Experiments

We organize the evaluation around three questions. RQ1 tests whether evidence-guided bounded repair can recover accuracy lost when generation is decomposed into auditable graph units. RQ2 examines whether the retained records remain structurally usable and support evidence-bounded repair transactions. RQ3 studies when such boundaries are appropriate and where their computational cost arises.

4.1

Setup

Datasets, comparisons, and protocol. APPS is a naturallanguage-to-Python benchmark with hidden tests (Hendrycks et al. 2021); we use a fixed sample of 200 tasks (50 introductory, 100 interview, and 50 competition). ClassEval evaluates class-level Python generation with interdependent methods and shared state (Du et al. 2024); each model–method run contains 100 records. We compare direct and reasoning baselines, staged or role-specialized generation, and graph variants that progressively add task planning, algorithmspecialized agents, and evidence-guided subtree repair. Functional comparisons use DeepSeek-V3.2 (DeepSeek-AI 2025) and Qwen3.6-plus (Alibaba Cloud 2026) with the same task inputs, decoding policy, execution harness, resource limits, and the attempt budget prescribed for each method. Fixedrun pass@1 is computed from the single output retained at the end of that method’s generation, retry, or repair sequence; hidden-test outcomes are never used to choose among candidates. The process audit in Table 2 uses a separate evidence source. It aggregates 200 existing deepseek-v4-flash APPS records from completed batches without rerunning or modifying them. Because these records differ from the functional experiments in model and run provenance, Table 2 characterizes the retained process evidence rather than an accuracy–auditability trade-off. Appendix C gives the baseline definitions, settings, denominators, exclusions, and reproduction commands. We also perform an exploratory 22task transfer check across file-based finance, blind scientific computing, and source-grounded aerospace/communications with deepseek-v4-flash, one retained candidate, and frozen external tests (Appendix K).

4.2

RQ1: Functional Recovery

Table 1 separates the effects of graph decomposition, algorithm specialization, and repair. On APPS, task planning alone reaches 39.5% with DeepSeek and 62.5% with Qwen. In the matched 200-task Qwen rows, algorithm-specialized agents raise pass@1 from 62.5% to 70.0%, and evidenceguided repair raises it to 83.0%. The DeepSeek sequence is directionally similar, but its middle row contains only 175 valid outputs. Thus, decomposition can introduce interface and strategy failures, while retaining the graph as a repair index makes many recoverable. AgentCoder remains the strongest functional baseline, exceeding AuditCoder by 8.5/7.5 points on APPS and 11.0/6.0 on ClassEval. On ClassEval, AuditCoder exceeds CoT + retry by 20.0/31.0 points. Because ClassEval contains interdependent methods and shared state, it extends the evidence beyond isolated functions. For exploratory transfer, AgentCoder and AuditCoder resolve 4/6 versus 4/6 finance tasks, 6/8 versus 5/8 scientific tasks, and 6/8 versus 5/8 aerospace/communications tasks under the protocol above. These small suites show that the pipeline operates across heterogeneous Python task forms; they do not establish broad domain generalization. Overall, RQ1 supports functional recovery under auditable decomposition and limited task-form transfer, while leaving a clear gap to AgentCoder.

Table 1: Fixed-run pass@1 (%) on APPS and ClassEval. AgentCoder attains the highest functional accuracy among the evaluated methods; AuditCoder is the strongest graph-based variant. APPS (200 tasks unless marked) Method

DeepSeek Qwen

Baselines without the contract-annotated graph Direct Direct + retry CoT CoT + retry Step-by-Step Framework AgentCoder

68.0 81.5 74.0 90.5 69.0 67.5 91.0

77.5 85.0 79.5 90.0 75.0 68.5 90.5

Graph-based variants Task plan Task plan + algorithm agents AuditCoder

39.5 52.0† 82.5

62.5 70.0 83.0

Method

ClassEval (100 records/run) DeepSeek Qwen

Direct + retry CoT + retry AgentCoder AuditCoder

52.0 55.0 86.0 75.0

52.0 51.0 88.0 82.0

†

The DeepSeek task-plan + algorithm-agents row contains 175 valid structured outputs after malformed JSON is filtered; it is a diagnostic ablation rather than a paired 200-task comparison.

Table 2: Record structure, localized repair, and transaction governance in a separate post-hoc aggregation of 200 APPS records. Metric

n

Trace and graph structure DCTC-leaf, task macro ↑ Graph integrity ↑ Contract–signature consistency ↑

200 0.9625 → 0.9725 1.0 → 1.0 200 185/200 (.925) – 332 323/332 (.973) –

Repair evidence and governance Recorded localization 60 coverage ↑ Localized repair success ↑ 26 Repair region size, nodes ↓ 26 Changed code ratio, LOC ↓ 26 Test regression rate ↓ 55 Decision compliance ↑ 55 Rollback integrity ↑ 21

4.3

Mean / rate

Med.

26/60 (.433)

–

17/26 (.654) .468 .526 2/55 (.036) 55/55 (1.0) 21/21 (1.0)

– .500 .677 – – –

RQ2: Auditability and Bounded Repair

Table 2 reports three layers of process evidence: whether the responsibility records remain structurally intact, whether failures admit an evidence-supported repair boundary, and whether the resulting transaction follows the recorded acceptance or rollback policy. Decision–Code Trace Coverage (DCTC) is the per-task fraction of leaf responsibility records that retain nonempty owned code, interface contract, provenance, and validation fields; the task-macro score averages this fraction across tasks. Its increase from 0.9625 after initial assembly to 0.9725 after repair and reassembly indicates that these links are usually retained through intervention. Because any nonempty validation verdict counts, DCTC measures record completeness rather than the truth of the fields or the correctness of the program. The stricter structural checks reveal the remaining defects. Graph integrity is 0.925 because it additionally requires re-

solvable references, an acyclic parent relation, and an execution order consistent with the recorded leaves. Contract– signature consistency is 0.973, but it checks only that one declared function exists with matching positional parameters; it does not evaluate semantic pre/postconditions, complexity, or behavior. Localization is markedly more selective than trace retention. The locator records an evidence-supported node or branch for 26 of 60 failures: six are supported by registered traceback frames and 20 by low-confidence verification reports. The remaining 34 cases abstain from bounded repair and proceed to a separately logged global fallback; those paths are outside the frozen-complement guarantee and are excluded from localized-repair and locality metrics. Since APPS provides no ground-truth responsibility node, 26/60 is a coverage measure, not localization accuracy or correctabstention accuracy. Seventeen of the 26 localized repairs pass the external tests. Their mean repair-region size (RRS) is 0.4679 of graph nodes, and the mean changed-code ratio (CCR) is 0.5260 of final lines of code (LOC). These values clarify the meaning of bounded: the permitted scope is explicit, but it is often a nontrivial branch rather than a small patch. RRS and CCR need not coincide because not every line owned by a selected node changes, while persisted deltas also reflect accepted repairs and rollbacks. Of 55 test observations that passed before repair, two fail afterward. The governance metrics concern the transaction record rather than functional quality. All 55 transactions with acceptance metadata agree with the system’s strict-improvement ordering over full pass, external and internal passes, and clean exits. All 21 comparable rollbacks restore the three audited snapshots: assembled code, node snippets, and APPS results. These checks establish consistency with the recorded policy and snapshots; they do not establish test completeness, repair optimality, or restoration of all runtime and intermediate state. Appendices D and E provide the formal definitions and record schemas.

Suitable Case: Multi-stage reasoning with stable artifacts Codeforces 1038F / APPS 42

AuditCoder 10/10

4

1

CoT 5/10

5

6

Σ Cyclic boundary correction

Linear DP

Pattern s

Limitation Case: Highly coupled global modeling Codeforces 884F / APPS 53 Character frequencies

AuditCoder 1/10

Symmetric-pair inequality

Final count

CoT 10/10

Relaxed local model pair reward = left gain + right gain char -> pair -> sink slot information collapsed

Flow model / feasible region pair -> left slot / right slot 2

3

KMP failure array

Automaton transitions

CoT often misses boundary-crossing cases Expected 2, CoT 1

Slot-level reward

Flow conservation

Over-optimistic but invalid solution Expected 26, got 36

stable artifact

✓

Each stage exposes a clear, verifiable output. Errors can be localized and repaired stage by stage.

Easy

：weak coupling, stable artifacts, defensible local boundaries

! Hard

Local pieces may look plausible, but correctness depends on all constraints being modeled together.

：global invariant, strong coupling, no independent repair boundary

Figure 3: Two diagnostic cases illustrating the scope of graph-based responsibility boundaries. Stable, locally testable artifacts support localized validation and repair (left), whereas a tightly coupled global invariant makes locally plausible components misleading (right). The counts summarize 10 attempts for each case and are not aggregate estimates.

Appendix F shows how these quantities arise in one transaction. For APPS task 3103, a wrong answer and compatible local rejections select branch S1. The branch is replanned under the same external raw_input–to–result contract, the outer orchestration remains in the frozen complement, and the retained validation cases pass after reassembly. The example is not an additional aggregate result; it illustrates how one responsibility address joins the evidence, selected scope, code revision, and final outcome.

4.4

RQ3: Applicability and Cost

The two cases in Figure 3 delimit when a responsibility graph is useful. In the suitable case, parsing, automaton construction, dynamic programming, boundary correction, and aggregation each produce a stable intermediate artifact. An implementation error can therefore remain a node-level transaction, while an interface or decomposition error can be lifted to a branch without changing the branch’s external contract. In the limitation case, frequencies, pair constraints, rewards, and flow conservation jointly define one feasible region. A local surrogate discards state needed across constraints, so a defensible response is to use a coarser responsibility unit, revise the graph, or abstain. The cases explain the structural mechanism; they do not estimate how frequently either regime occurs. The token breakdown shows where this design becomes expensive. The 200-record audit collection consumes 15.98M tokens, or 79.9K per task. Initial generation accounts for 70.09% of the total and repair for 29.91%. Across both stages, planning and reasoning consume 64.46%, code generation and assembly 28.27%, and explicit verification 7.28%.

The 34 abstention-triggered global fallbacks alone consume 57.88% of all repair tokens, more than the 26 evidencelocalized paths. Thus, the main cost comes from planning and from failures to establish a local boundary, rather than from verification alone. Abstention preserves the conservative repair semantics, but a subsequent global fallback shifts rather than removes the computational cost. For simple self-contained tasks that do not require an audit trail, lightweight CoT or global retry is the more economical choice. AuditCoder is most appropriate when the task admits meaningful intermediate artifacts and the value of persistent responsibility, bounded intervention, and an inspectable repair history justifies the additional calls. Appendix H gives the detailed accounting.

5

Conclusion

AuditCoder follows one principle: a generation-time subproblem remains responsible for its implementation, evidence, and interventions. Its contract-annotated task graph maps failures to evidence-supported nodes or branches, repairs them, reuses the frozen complement, or abstains without a defensible boundary. As a repair index, the graph recovers much of the accuracy lost to decomposition, but remains below the strongest functional baselines. The audit exposes the bottleneck: trace links persist, but only 26 of 60 failures support a node or branch boundary, while planning and global fallback dominate cost. It suits tasks with stable, locally testable artifacts. Repositories still require better boundaries and compact cross-file histories. Trustworthy code generation requires not only better programs, but durable responsibility for how they are built and changed.

References Alibaba Cloud. 2026. Qwen3.6: Alibaba Cloud Launch Announcement. https://www.alibabacloud.com/blog/alibaba-cloud-unveilsqwen3-6_602718. Announcement including Qwen3.6-plus. Accessed: 2026-05-07. Bairi, R.; Sonwane, A.; Kanade, A.; D. C., V.; Iyer, A.; Parthasarathy, S.; Rajamani, S. K.; Ashok, B.; and Shet, S. 2024. CodePlan: Repository-Level Coding Using LLMs and Planning. Proceedings of the ACM on Software Engineering, 1(FSE): 675– 698. Barrak, A. 2025. Traceability and Accountability in RoleSpecialized Multi-Agent LLM Pipelines. In 2025 40th IEEE/ACM International Conference on Automated Software Engineering Workshops, 315–322. Bouzenia, I.; Devanbu, P. T.; and Pradel, M. 2025. RepairAgent: An Autonomous, LLM-Based Agent for Program Repair. In Proceedings of the 47th IEEE/ACM International Conference on Software Engineering. Chen, B.; Zhang, F.; Nguyen, A.; Zan, D.; Lin, Z.; Lou, J.-G.; and Chen, W. 2023. CodeT: Code Generation with Generated Tests. In The Eleventh International Conference on Learning Representations. Chen, J.; Tang, H.; Chu, Z.; Chen, Q.; Wang, Z.; Liu, M.; and Qin, B. 2024a. Divide-and-Conquer Meets Consensus: Unleashing the Power of Functions in Code Generation. In Advances in Neural Information Processing Systems, volume 37, 67061–67105. Chen, X.; Lin, M.; Schärli, N.; and Zhou, D. 2024b. Teaching Large Language Models to Self-Debug. In The Twelfth International Conference on Learning Representations. DeepSeek-AI. 2025. DeepSeek-V3.2: Pushing the Frontier of Efficient Reasoning and Agentic AI. https://huggingface.co/deepseekai/DeepSeek-V3.2. Model card. Accessed: 2026-05-07. Du, X.; Liu, M.; Wang, K.; Wang, H.; Liu, J.; Chen, Y.; Feng, J.; Sha, C.; Peng, X.; and Lou, Y. 2024. Evaluating Large Language Models in Class-Level Code Generation. In Proceedings of the 46th IEEE/ACM International Conference on Software Engineering, 982–994. Gou, Z.; Shao, Z.; Gong, Y.; Shen, Y.; Yang, Y.; Duan, N.; and Chen, W. 2024. CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing. In The Twelfth International Conference on Learning Representations. Hendrycks, D.; Basart, S.; Kadavath, S.; Mazeika, M.; Arora, A.; Guo, E.; Burns, C.; Puranik, S.; He, H.; Song, D.; and Steinhardt, J. 2021. Measuring Coding Challenge Competence With APPS. In Proceedings of the Neural Information Processing Systems Track on Datasets and Benchmarks. Huang, D.; Zhang, J. M.; Luck, M.; Bu, Q.; Qing, Y.; and Cui, H. 2023. AgentCoder: Multi-Agent-based Code Generation with Iterative Testing and Optimisation. arXiv preprint arXiv:2312.13010. arXiv:2312.13010. Islam, M. A.; Ali, M. E.; and Parvez, M. R. 2024. MapCoder: Multi-Agent Code Generation for Competitive Problem Solving. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics, 4912–4944. Jiang, X.; Dong, Y.; Wang, L.; Fang, Z.; Shang, Q.; Li, G.; Jin, Z.; and Jiao, W. 2024. Self-Planning Code Generation with Large Language Models. ACM Transactions on Software Engineering and Methodology, 33(7): 182:1–182:30. Jones, J. A.; and Harrold, M. J. 2005. Empirical Evaluation of the Tarantula Automatic Fault-Localization Technique. In Proceedings of the 20th IEEE/ACM International Conference on Automated Software Engineering, 273–282.

Loughridge, C.; Sun, Q.; Ahrenbach, S.; Cassano, F.; Sun, C.; Sheng, Y.; Mudide, A.; Misu, M. R. H.; Amin, N.; and Tegmark, M. 2025. DafnyBench: A Benchmark for Formal Software Verification. Transactions on Machine Learning Research. North, M.; Atapour-Abarghouei, A.; and Bencomo, N. 2024. Code Gradients: Towards Automated Traceability of LLM-Generated Code. In 2024 IEEE 32nd International Requirements Engineering Conference, 321–329. QF-Bench. 2026. QuantitativeFinance-Bench: A State-Aware Interactive Benchmark for Financial Agent Tasks. https://github.com/ QF-Bench/QuantitativeFinance-Bench. Software benchmark. Accessed: 2026-07-29. Ruan, H.; Zhang, Y.; and Roychoudhury, A. 2025. SpecRover: Code Intent Extraction via LLMs. In Proceedings of the 47th IEEE/ACM International Conference on Software Engineering, 963–974. Shinn, N.; Cassano, F.; Gopinath, A.; Narasimhan, K.; and Yao, S. 2023. Reflexion: Language Agents with Verbal Reinforcement Learning. In Advances in Neural Information Processing Systems, volume 36, 8634–8652. SonarSource. 2026. State of Code Developer Survey Report 2026. Technical report, SonarSource. Quantitative online survey of 1,149 professional developers; fieldwork conducted in October 2025. Sun, C.; Sheng, Y.; Padon, O.; and Barrett, C. 2024. Clover: ClosedLoop Verifiable Code Generation. In AI Verification: First International Symposium, SAIV 2024, 134–155. Springer. Tian, M.; Gao, L.; Zhang, S. D.; Chen, X.; Fan, C.; Guo, X.; Haas, R.; Ji, P.; Krongchon, K.; Li, Y.; Liu, S.; Luo, D.; Ma, Y.; Tong, H.; Trinh, K.; Tian, C.; Wang, Z.; Wu, B.; Xiong, Y.; Yin, S.; Zhu, M.; Lieret, K.; Lu, Y.; Liu, G.; Du, Y.; Tao, T.; Press, O.; Callan, J.; Huerta, E.; and Peng, H. 2024. SciCode: A Research Coding Benchmark Curated by Scientists. In Advances in Neural Information Processing Systems, volume 37, 30624–30650. Wang, F.; Xi, X.; Cui, Z.; Dai, H.; and Wang, X. 2025. Embedding Traceability in Large Language Model Code Generation: Towards Trustworthy AI-Augmented Software Engineering. In Companion Proceedings of the 33rd ACM International Conference on the Foundations of Software Engineering, 1760–1763. Wang, Y.; Keung, J.; Ma, X.; Mao, Z.; Chen, K.; and Li, Y. 2026. R2Code: A Self-Reflective LLM Framework for Requirements-toCode Traceability. arXiv preprint arXiv:2604.22432. Accepted to IEEE COMPSAC 2026, arXiv:2604.22432. Wong, W. E.; Gao, R.; Li, Y.; Abreu, R.; and Wotawa, F. 2016. A Survey on Software Fault Localization. IEEE Transactions on Software Engineering, 42(8): 707–740. Xia, C. S.; Deng, Y.; Dunn, S.; and Zhang, L. 2025. Demystifying LLM-Based Software Engineering Agents. Proceedings of the ACM on Software Engineering, 2(FSE): 801–824. Yang, C.; Li, X.; Misu, M. R. H.; Yao, J.; Cui, W.; Gong, Y.; Hawblitzel, C.; Lahiri, S.; Lorch, J. R.; Lu, S.; Yang, F.; Zhou, Z.; and Lu, S. 2025. AutoVerus: Automated Proof Generation for Rust Code. Proceedings of the ACM on Programming Languages, 9(OOPSLA2): 396:1–396:29. Yang, J.; Jimenez, C. E.; Wettig, A.; Lieret, K.; Yao, S.; Narasimhan, K. R.; and Press, O. 2024. SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. In Advances in Neural Information Processing Systems, volume 37, 50528–50652. Zelikman, E.; Huang, Q.; Poesia, G.; Goodman, N. D.; and Haber, N. 2023. Parsel: Algorithmic Reasoning with Language Models by Composing Decompositions. In Advances in Neural Information Processing Systems, volume 36, 31466–31523.

Zhang, S.; Chen, Z.; Shen, Y.; Ding, M.; Tenenbaum, J. B.; and Gan, C. 2023. Planning with Large Language Models for Code Generation. In The Eleventh International Conference on Learning Representations. Zhang, Y.; Ruan, H.; Fan, Z.; and Roychoudhury, A. 2024. AutoCodeRover: Autonomous Program Improvement. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, 1592–1604. Zhong, L.; Wang, Z.; and Shang, J. 2024. Debug like a Human: A Large Language Model Debugger via Verifying Runtime Execution Step by Step. In Findings of the Association for Computational Linguistics: ACL 2024, 851–870.

Guide to the Supplement The main paper is intentionally self-contained. This supplement provides the additional material needed to inspect the method implementation, reproduce the reported experiments, and trace the aggregate audit claims to concrete records. Appendix A gives a compact lifecycle-oriented positioning table without repeating the prose of Section 2. Appendix B specifies the complete inference procedure, the serialized responsibility record, and a concrete record instance. Appendices C–E document the experimental protocol, metric definitions, and case-level repair-log schema. Appendix F provides one end-to-end audit transaction. Appendices G–I report failure boundaries, token cost, and limitations. Finally, Appendix J identifies the boundary-critical prompt and artifact components, Appendix K documents the exploratory cross-domain suites, and Appendix L reproduces the complete prompt-template corpus. Machine-readable logs are placed in the separately submitted Code and Data Supplement.

A

Lifecycle-Dimension Positioning

Section 2 explains the conceptual distinctions in prose. Table 3 provides a compact lifecycle-oriented comparison. Its entries indicate whether a property is a required system invariant, not whether a prior system could be extended to support it.

B B.1

Additional Method Details

Full Inference Algorithm

Algorithm 1 makes explicit the three invariants summarized in the main paper: pre-code identity allocation, ownershipand-evidence binding, and identity-preserving intervention. The ownership map µ is included in the locator call because traceback frames and registered helpers are resolved through this map.

B.2

Lifecycle Invariants and Serialized Audit Schema

For implementation node vi , the conceptual responsibility record is si = (idi , gi , ai , Fi , ci , ρi , ri , hi ). The serialized form must therefore contain the owned implementation bundle explicitly; omitting code from the schema would break the decision–code link that the method claims to preserve. We use the following record: Nodei = {id, goal, parent, dependencies, agent_type, interface, complexity_budget, owned_code, provenance, validation, integration_exceptions, repair_history}.

B.3

Concrete Responsibility-Record Instance

Figure 4 instantiates the serialized schema with the permutation-construction example. It presents the task breakdown across root, child, and grandchild responsibility records together with the critical-audit fields retained for each unit. The agent-oriented headings identify routed execution roles; the node identities and the responsibility records inside the cards remain the evidence-addressable units used by AuditCoder. The figure is a static artifact snapshot; Figure 2 in the main paper shows how the records are used over time for validation, localization, and bounded repair. The distinction between an agent role and a responsibility address is essential. For example, “Greedy” identifies a routed executor, whereas the node identity is the stable lookup key for its commitment, selected code, validation evidence, and intervention history. The function map displayed in S0 assigns check_feasibility to S1_S1 and construct_permutation to S1_S2. The parallel constructor shown under S2 therefore exposes a duplicated responsibility that must be marked unused or resolved by the ownership checker before assembly; it is not a second valid owner. The parent consumes the mapped child records during assembly; it does not acquire ownership of the child code.

C

Experimental Protocol and Reproducibility

This section records the operational details needed to reproduce the functional and audit analyses. Aggregate outcomes are reported in Tables 1–2 of the main paper. Baseline operations. Direct generates one complete program; Direct + retry permits one global retry after failed validation. CoT and CoT + retry add an explicit reasoning stage. Step-by-Step continues implementation from an incrementally accumulated partial program. Framework first produces a code skeleton and then fills its details. AgentCoder uses programmer, test-designer, and test-executor roles with iterative execution feedback. The graph ablations progressively add a task graph, algorithm-specialized generators, and evidence-guided subtree repair. Run selection and denominators. No output is selected after observing hidden-test success. Fixed-run pass@1 uses one retained output per evaluated record. Rows with a method-defined retry or repair consume their permitted additional calls, but do not sample multiple candidates and retrospectively select a passing one. Where a parser failure changes the denominator, the row reports that denominator explicitly. Bounded repair versus global fallback. A locator output of ⊥ terminates the bounded-repair procedure in Algorithm 1. In the consolidated implementation records, an optional, separately logged global fallback may subsequently generate another candidate. Those 34 paths are outside the frozen-complement guarantee, are excluded from localizedrepair success and locality metrics, and are reported separately in the cost analysis.

Method family

Primary addressable unit

Selected code and evidence retained under that identity

Repair boundary as an execution constraint

Persistent intervention history

Structured reasoning

Thoughts, actions, or search Not generally an executable Not generally required to states ownership requirement. bind an implementation bundle and validation record.

Search or revision may be structured, but the boundary need not be a code-ownership invariant.

Reasoning/search traces may be retained, but not necessarily as code-responsibility transactions.

modular Plans, function descriptions, A planning component may Component identity modules, or candidate composi- exist before code. supports synthesis, but tions selected candidates, runtime evidence, and later versions need not remain under one immutable responsibility address.

Components may be replaced or recomposed; preservation of the outside region is not necessarily enforced as an audit invariant.

Prior candidates or caches may be available, but append-only repair provenance is not the defining object.

Execution feedback and Programs, basic blocks, files, Localization usually starts post-hoc repair functions, or edit spans from the generated or existing artifact.

Runtime evidence can be precise, but the diagnostic unit need not be the plan-time commitment that produced the code.

The patch scope is selected retrospectively and may be global or artifact-derived.

Repair iterations can be logged, but are not necessarily indexed by a pre-code responsibility identity.

Traceability and formal Requirement–code links, proof Requirements or proof evidence obligations, specifications, or objects may predate code. verified artifacts

Strong property or correspondence evidence can be retained, while the executed candidate-selection and repair history remain orthogonal.

Verification can constrain admissible artifacts, but it does not by itself define the construction-time repair transaction.

Depends on the workflow; construction provenance is not implied by property validity.

AuditCoder

Required: commitment, interface, owned code, provenance, validation evidence, and versions use the same address.

Required: repair selects an Required: each intervention evidence-supported node or is appended to the same branch, freezes the responsibility record. complement, records cross-boundary exceptions, or abstains.

Planning and synthesis

Identity allocated before code

Contract-annotated responsibil- Required: the responsibility ity node and its owned imple- ID is allocated when the mentation bundle graph is created, before implementation sampling.

The distinction is lifecycle continuity: planning, generation, assembly, validation, localization, and repair reuse one pre-code responsibility address. The table does not claim that decomposition, feedback, traceability, or verification are individually new.

Table 3: Lifecycle-oriented positioning. The table complements, rather than repeats, the related-work discussion in the main paper. Submitted reproducibility materials. The separately uploaded Code and Data Supplement should contain the implementation, prompt sources, evaluation scripts, fixed task identifiers, run manifests, environment specification, raw audit traces, per-task repair records, and commands that reproduce each table. The technical supplement intentionally contains no pointer to a mutable web repository.

D

Audit Metric Definitions

Let A be the selected audit-record set. For t ∈ A, let Gt = (Vt , Dt , Tt ) be its final task graph, Ut ⊆ Vt the implementation nodes, S and Lt ⊆ Ut the leaf implementation nodes; let U = t∈A Ut denote their pooled set. Decision–code trace coverage. For leaf node vi , let ci , Fi , ρi , and ri denote its owned code, basic interface contract, input-source fields, and validation record. Then 1 X I[ci ̸= ∅ ∧ Fi ̸= ∅ ∧ ρi ̸= ∅ ∧ ri ̸= ∅]. DCTCt = |Lt | vi ∈Lt

P Table 2 reports both the macro average |A|−1 t∈A DCTCt and the leaf-micro ratio obtained by pooling all covered leaves. Initial DCTC is computed after initial assembly; final DCTC is computed after repair and reassembly. A nonempty verdict counts even when it is reject; DCTC therefore measures record presence, not code correctness, provenance truth, or contract execution. Graph integrity. GraphValid(t) requires nonempty unique node IDs, a resolvable root, valid parent and dependency references, an acyclic parent relation, no duplicate execution-order entries, and equality between the executionorder set and the recorded leaf set. The graph-integrity rate is 1 X GIR = I[GraphValid(t)]. |A| t∈A

This is a post-hoc structural check. It does not establish that a decomposition or dependency edge is semantically correct. Contract-signature consistency. For implementation node vi , SigMatch(vi ) requires a nonempty declared func-

Algorithm 1 AuditCoder inference with evidence-guided bounded repair. The procedure returns the final program and an audit trace containing responsibility records, validation evidence, and append-only repair history. Require: task x, agent set M, repair budget K Ensure: executable program y, audit trace A = (G, S, E, H) Stage 1: allocate responsibility identities and construct contracts. 1: I ← Π(x); extract (P, B, G, Q) 2: U ← ImplementationNodes(G) 3: initialize S ← ∅, E ← ∅, H ← ∅, µ ← ∅ Stage 2: generate node-owned code and bind local evidence. 4: for each vi ∈ U in topological order do 5: ai ← Route(vi , M, B) 6: ci ← Generate(ai , gi , Fi , Xi , Yi , ρi , Ci , B) 7: µ ← RegisterOwnedUnits(µ, vi , ci ) 8: ri ← VerifyLocal(ci , Fi , qi , Ci ) 9: S ← S ∪ {(idi , gi , ai , Fi , ci , ρi , ri , ∅)} 10: end for Stage 3: assemble and collect global evidence. 11: y ← Ω(G, {(vi , ci )}vi ∈U ) 12: rg ← Execute(y, Q); E ← E ∪ {rg } 13: if rg passes then 14: return y, (G, S, E, H) 15: end if Stage 4: intervene only on an evidence-supported region. 16: for k = 1 to K do 17: z ← Locate(rg , G, {ri }vi ∈U , µ) 18: if z = ⊥ then 19: return y, (G, S, E, H) 20: end if 21: R ← SelectRegion(z, G) 22: R ← ExpandForIntegrationExceptions(R, S) 23: F ←V \R 24: freeze {ci , ri }vi ∈F ∩U 25: ξ0 ← Snapshot(y, {ci }vi ∈U , rg ) cand , {ccand , ricand }vi ∈R∩U ← Repair(G
R , {ci , ri }vi ∈R∩U , z) 26: GR i cand } , {ci }, {ccand 27: ∆G, ∆c ← Diff GR , GR i
cand cand 28: G ← ReplaceRegion G, R, GR
29: y cand ← Ω G cand , {ccand }vi ∈R∩U ∪ {ci }vi ∈U \R i = ci for all vi ∈ F ∩ U 30: assert ccand i 31: rgcand ← Execute(y cand , Q) 32: E ← E ∪ {rgcand } 33: d ← Decide(rg , rgcand ) 34: if d = Accept then 35: G ← G cand , ricand }vi ∈R∩U 36: {ci , ri }vi ∈R∩U ← {ccand i cand 37: y←y 38: rg ← rgcand 39: σ ← NotApplicable 40: else 41: Restore(ξ0 ) 42: σ ← Restored 43: end if
44: S ← AppendIntervention S, R, z, {ccand , ricand }, d, σ i  45: H ← H ∪ (z, R, F, ∆G, ∆c, {ricand }, rgcand , d, σ) 46: if d = Accept and rg passes then 47: return y, (G, S, E, H) 48: end if 49: end for 50: return y, (G, S, E, H)

tion name, parseable Python code, exactly one function with that name, and positional parameter names and order that

▷ every registered function/helper has one owner

▷ abstain from unsupported local repair ▷ no silent cross-boundary edit

▷ recorded strict-improvement policy

▷ return the best audited attempt within budget

match the declared interface after an optional leading self

Field group

Stored content

Lifecycle rule

Identity and structure

id, goal, parent, and dependencies.

Agent routing

agent_type and the concrete routed agent identifier.

Interface contract

Function name, typed parameters, return schema, preconditions, postconditions, invariants, and complexity budget.

Owned implementation

owned_code: the selected function/helper bundle registered under the node. Variable-source map, local tests, contract checks, resource probes, and global evidence linked back to the node. Cross-node integration exceptions, selected region, frozen complement, graph/code deltas, validation outcome, and prior versions.

id is allocated when the graph is created, before any implementation is sampled, and is not reassigned after repair. The agent answers who executes; it does not replace the responsibility ID that answers which code/evidence region is owned. Machine-checkable fields are validated directly; semantic clauses count as executable evidence only when instantiated as tests, assertions, analyzers, or proof obligations. The ownership map µ is total over registered code units and maps each unit to exactly one responsibility owner. Code and evidence reuse the same address; a passing record means test/tool validated, not formally proved by default. Cross-boundary edits must be explicit and expand the transaction boundary; repair history is append-only.

Provenance and evidence

Exceptions and history

Table 4: Serialized responsibility-record fields and the invariants they support. ROOT AGENT S0

depth=0

SUB AGENT S1

depth=1

SUB SUB AGENT S1_S1

depth=2

Task

Task

Task

read N,K, coordinate feasibility checking and construction, then emit a permutation or -1.

coordinate the feasibility checker and nested constructor.

decide feasibility using the Erdős–Szekeres bound.

Critical Audit

Critical Audit

Critical Audit

Decision

Decision Responsibility and permission boundary Allowed:parse task input, invoke dependencyowned functions, assemble the final program, and emit the result. Stop condition: return after global verification passes, the repairbudget is exhausted, or localization abstains. Forbidden region:may not silently change a child contract, overwrite child-owned code, or alter the committed graph topology.

...

Responsibility and permission boundary coordinate child outputs and, after supported localization,replan only the selected S1 subtree.

... ... Code

def check_feasibility(N, K): return K * K >= N

Agent Category

Agent Category

no specialized agent type; this is an orchestration node.

Math

...

SUB AGENT S2

Data and code provenance Function map: solve → S0/orchestration , check_feasibility → S1_S1/math , construct_permutation → S1_S2/greedy .

Critical Audit

Task

... ... Code

...

for i in range(K): block_size = base_size + (i < remainder) result.extend(range(current + block_size - 1, current 1, -1))

...

Agent Category

no specialized agent type; this is an orchestration node.

Greedy

depth=2

Task construct the permutation after feasibility checking.

Critical Audit

Decision

Decision

Responsibility and permission boundary implement its own constructor and node-local helpers, then submit it to local verification.

Agent Category

...

SUB SUB AGENT S1_S2 depth=1

construct the permutation using K reversed blocks.

...

is_possible = check_feasibility(N, K) result_str = construct_permutation(N, K, is_possible) print(result_str)

... Code

is_possible = check_feasibility(N, K) return construct_permutation(N, K, is_possible)

Contract evidence Global invariant: output a permutation of 1..N with max(LIS,LDS)==K , or -1 when impossible. Boundary cases: 1 1 → 1 , 4 1 → -1 , 5 6 → -1 .

... ... Code

Decision

Responsibility and permission boundary implement and locally verify only the feasibility predicate. ...

Responsibility and permission boundary construct and locally verify the permutation using the feasibility input.

... ... Code

block_size = math.ceil(N / K) for i in range(K): block = range(i * block_size + 1, min((i + 1) * block_size, N) + 1) perm.extend(reversed(block))

...

Agent Category Greedy

Figure 4: Task breakdown and critical-audit records for the permutation-construction example. Solid black arrows show task dependencies fixed by the global planner before code generation; gray dashed arrows show child-to-parent code and audit-record propagation for assembly; red bidirectional arrows mark the recorded decision–code link within each node. Agent headings denote routed execution roles, while responsibility records remain the evidence-addressable audit units.

is removed. Then CSCR =

P

vi ∈U I[SigMatch(vi )]

|U|

.

The check does not cover type annotations, default or keyword-only arguments, preconditions, postconditions, in-

Item

Evaluated records

Protocol and disclosure

APPS functional runs

Fixed 200-task sample: 50 introductory, The same problem statements, execution interface, timeout, memory 100 interview, and 50 competition tasks. policy, decoding configuration, and maximum attempt budget are used across methods unless the method definition requires a retry or repair call. ClassEval functional runs 100 class-level records per model– The class-level harness checks interdependent methods and shared method run. state; the denominator is fixed at 100 for each reported row. Audit-record aggregation 200 existing APPS records: 50 introduc- Table 2 is a read-only post-hoc aggregation of completed tory, 100 interview, and 50 competition deepseek-v4-flash batches. This record set is not a single tasks. frozen run or a same-protocol replication of the functional rows. Repair subset 60 initially failing tasks enter repair: 26 Localized repair success, RRS, and CCR use the 26 localized contain a recorded node/branch localiza- transactions. Decision compliance uses 55 transactions with tion; for the remaining 34, the locator ab- acceptance records; five legacy transactions are excluded rather than stains and the pipeline records a global imputed. fallback. Malformed structured The DeepSeek task-plan + algorithm- The row reports the valid-record denominator after filtering output agents row has 175 valid JSON records. malformed outputs. Because its task set is smaller, it is treated as a diagnostic ablation rather than a paired significance comparison with 200-record rows. Model and call metadata DeepSeek-V3.2 and Qwen3.6- The audit source manifest records the provider-visible model, input plus for the functional tables; files, and file hashes. The consolidated legacy records do not establish deepseek-v4-flash for the one common git commit, environment fingerprint, or result-schema post-hoc audit aggregation. version. Sandbox evidence Every executed program. The harness records exit status, stdout, stderr, traceback frames, observed and expected outputs, runtime, timeout status, and memory status when available.

Table 5: Evaluation denominators, exclusions, and logged metadata. Exact numeric model settings and sandbox limits should be read from the run manifest included in the Code and Data Supplement, not inferred from aggregate tables.

variants, complexity, or functional behavior. Recorded localization coverage and localized repair success. Let Frepair be initially failed tasks admitted to repair, and let RecordedLocate(t) indicate that the persisted record names a node or branch and records a localization method. Define Floc = {t ∈ Frepair : RecordedLocate(t)}. Then |Floc | , |Frepair | |{t ∈ Floc : PassAPPS (Repair(t))}| . LRSAPPS = |Floc | The 26 localized records comprise six high-confidence traceback cases and 20 low-confidence verification-report cases. For the remaining 34 cases, the locator abstains and the pipeline records a global fallback. Natural APPS failures have no responsibility-node ground truth, so coverage is not Localization@1 or causal accuracy. LocCov =

Repair region and changed code. For selected node region R ⊆ V and programs y and y ′ before and after the persisted repair decision, |R| ChangedLOC(y, y ′ ) RRSnodes = , CCRLOC = . |V| LOC(y ′ ) RRS measures graph-node scope, whereas CCR measures the persisted textual delta. The reported CCR mixes accepted repairs, rollback-induced zero deltas, and five legacy records without acceptance metadata; it should not be interpreted as the delta distribution of accepted candidates alone.

Test regression. If Tpass (y) is the pooled set of external tests passed before localized repair, then Regress =

|{τ ∈ Tpass (y) : τ fails on y ′ }| . |Tpass (y)|

The main-table denominator is 55 eligible test observations, of which two fail after repair; it is not the number of repaired tasks. Strict-improvement decision compliance. The recorded candidate ordering is the lexicographic tuple Rank(x) = (Fx , Ex , Ix , CxE , CxI ), where the components indicate full pass, external passes, internal passes, external clean exits, and internal clean exits. A candidate is expected to be accepted exactly when its candidate rank exceeds its initial rank. For transaction a, let da be the recorded binary decision and ea = I[Racand > Rainit ] the expected decision. For transactions Arecorded with acceptance metadata, SIDC =

1 |Arecorded |

X

I[da = ea ].

a∈Arecorded

This checks policy consistency against recorded ranks, not whether the tests or ranks are themselves complete. Five legacy repairs lack acceptance records and are excluded rather than counted as compliant.

Rollback integrity. For rollback transaction a, Restored(a) requires equality between the final and initial values of (i) assembled code, (ii) node code snippets, and (iii) APPS test results. The audited rollback-integrity rate is P I[Restored(a)] RIR = a∈Arollback . |Arollback | This three-snapshot comparison does not prove restoration of the complete IR, verification reports, process state, or append-only event history.

E

Repair Records and Aggregate-to-Case Evidence

The aggregate values in Table 2 are computed from machinereadable trace and repair records. Table 6 identifies the fields required to audit that aggregation.

Aggregation unit

n

Reconciliation

Post-hoc audit records

200

Repair cases

60

Localized repairs

26

Acceptance decisions

55

Regression observations

55

Comparable rollbacks

21

Consolidated 50/100/50 introductory/interview/competition records; no pipeline exception is reported in the selected bundle. Twenty-six contain a recorded node/branch localization; for the remaining 34, the locator abstains and the pipeline records a global fallback. Seventeen pass the external APPS tests after repair. Thirty-four are accepted and 21 are rolled back; five legacy repair cases have no acceptance record. Eligible external tests that passed before localized repair; two fail afterward. All 21 restore the three audited snapshots.

Table 7: Denominators used by the descriptive audit analysis. Field

Meaning

task_id, record source Identifiers joining the benchmark record, construction trace, and source-manifest entry. A nonempty per-transaction trace_id is not assumed for the consolidated legacy bundle. failure_type External symptom: wrong answer, exception, timeout, memory/resource failure, or another harness verdict. evidence_type Locator rule and supporting evidence: registered traceback frame, resource signal, compatible local rejection, or abstention. selected_unit Responsibility node or branch root selected by the locator, with the discrete confidence label. repair_region, Node IDs included in the transaction and node IDs frozen_region preserved outside it. RRS_nodes, CCR_LOC Selected node fraction and persisted changed-code ratio for localized repair. repair_success, External post-repair outcome and failures among regression_rate previously passing tests. Acceptance record and Recorded decision and the initial/candidate ranks strict-improvement tuples used to audit it. Initial/final code, snip- The three persisted snapshot pairs used by the pets, and APPS results rollback-integrity check.

Table 6: Per-task fields used by the reported repair metrics. The available records support localization, persisteddelta, decision-compliance, regression, and three-snapshot rollback checks; they do not establish a complete appendonly transaction history.

F

Compact Audit Case Study

This case study uses APPS task 3103 (Kattis helpfulcurrents). The task counts routes from a ship’s starting column to the castle tile @. A ship may move north from a valid cell and may additionally follow an east/west current on > or <. The first assembled program returned 1 for an example whose expected output was 2. The trace attributes the compatible local rejections and global wrong-answer evidence to branch S1; the repair transaction therefore replans that branch while retaining the outer boundary.

Audit question

Before repair

What failed?

Expected 2; observed 1.

After repair

Three retained validation cases pass. Where is responsibility Compatible evidence maps The transaction remains assigned? to branch S1. attached to S1; leaves remain S1__S1 and S1__S2. What may change? Only the The external branch contract evidence-supported subtree. and frozen complement are retained. What semantic change is North/current choice and Parsing and row-wise DP recorded? zero-based input were implement the clarified under-specified or semantics. mishandled.

Table 8: Before/after audit interpretation for APPS 3103. Input

Expected

Actual after repair

Pass

2 2 0; >@; >~ 3 5 1; »@«; >~#~<; »»~ 3 4 0; >~@~; ~<#~; »>~

2 4 begin repairs

2 true 4 true begin repairs true

Table 9: Representative post-repair checks for APPS 3103.

The saved trace does not preserve every internal LLM message or temporary source file. It retains the final IR, leaf code and local verification records, assembled code, original failing case, selected error branch, retry strategy, and final external validation evidence. The case therefore illustrates a bounded repair transaction, but it does not establish complete internal-state capture or correctness beyond the retained tests.

S0: outer orchestration and output contract frozen structural boundary during the selected transaction ↙

↘

Selected bounded region R: subtree rooted at S1 S1 commitment: parse the branch input and compute the route count while preserving the external raw_input -> result contract. S1__S1 String parse_input records Y, X, xinit , grid

Frozen complement F non-selected responsibilities are reused unchanged; any required cross-boundary edit must be recorded as an integration exception.

S1__S2 DP count_paths row-wise route propagation

Figure 5: Responsibility boundary used in the APPS 3103 audit transaction. The locator selects the subtree rooted at S1; its parser and DP leaves are regenerated under the existing external branch contract. The outer orchestration and non-selected responsibilities form the frozen complement. The figure visualizes the repair transaction, not the entire internal task graph. Stage

Input / retained record

Initial responsibility graph

Root S0; selected branch candidate S1; parser leaf S1__S1; DP leaf S1__S2. Strict leaf interfaces, route-counting hints, and boundary cases. Assembled code and the problem I/O contract. Global failure plus local verification records.

Local generation and checks Global failure Localization Bounded repair

Final validation

Output or audit evidence

The branch boundary is raw_input -> result; the intended complexity is O(Y X). Both leaf implementations compile, but local verification returns reject; the initial plan also mishandles zero-based input and the optional current transition. wrong_answer; for input 2 2 0\n>@\n>~, expected 2, observed 1. Select S1 using compatible local-rejection evidence, confidence=low; set error_branch_root=S1. Failing sample, old branch record, and frozen external Retain zero-based x_init; make north movement available on valid cells; treat boundary. following > or < as an additional option; regenerate only the selected subtree and graft it back into the graph. Reassembled program and three validation cases. all_passed=true, cases_run=3, cases_passed=3; the repair record is closed under the same branch ID.

Table 10: Stage-level evidence for the APPS 3103 repair transaction. The table summarizes the retained inputs, transformations, evidence, and outcome at each stage.

G

Failure Modes and Applicability Boundaries

Table 11 translates the suitable and tightly coupled cases from the main paper into an evidence-to-response taxonomy. The graph is most useful when intermediate artifacts are semantically meaningful, locally testable, and compositional. When a problem is governed by one tightly coupled global invariant, the appropriate auditable unit may be a single global node rather than an artificially decomposed collection of subgoals. Failure mode

Evidence

Response

Local implementation bug

A registered traceback frame or compatible local contract/boundary rejection points to one implementation owner. Adjacent nodes disagree on arguments, return schema, shape, or boundary conditions. Local goals appear individually plausible but omit a dependency or assign the wrong responsibility. Correctness depends on constraints that must be modeled jointly, and no stable local boundary is justified. Several incomparable nodes remain compatible with the evidence, or the evidence establishes only a graph-level violation. A previously passing test fails after the transaction.

Prefer node-level repair; freeze the interface and the outside region unless evidence shows a contract mismatch. Repair the selected contract/code unit and expand the transaction only as needed to preserve the external frozen boundary. Lift to branch-level repair and replan within the branch’s external input/output contract. Revise the graph abstraction or use one global responsibility node; bounded repair may abstain. Return ⊥ rather than assigning an unsupported unit.

Contract or interface mismatch Incorrect decomposition Global invariant or high coupling Ambiguous localization Repair-induced regression

Record the non-monotonic outcome, reject the repair, and inspect boundary compatibility and integration exceptions.

Table 11: Failure taxonomy and evidence-constrained repair response. H Token and Cost Analysis Averages per valid task use 200 as the denominator; averages per repair use the 60 tasks that enter repair; module averages Token usage is collected from API response metadata; metric use each module’s observed call count. aggregation itself does not invoke an LLM. The aggregation includes only the final 200 records selected into the consolidated collection and excludes superseded runs replaced by overlays. All 3,800 retained calls contain usage metadata.

Scope

Calls

Total Initial generation Repair

3,800 5,271,855 10,703,880 15,975,735 2,880 3,893,277 7,303,482 11,196,759 920 1,378,578 3,400,398 4,778,976

Prompt

Compl.

Total Avg./valid Avg./repair 79,878.68 55,983.80 23,894.88

– – 79,649.60

Table 12: AuditCoder token usage by scope over the selected 200-record collection. Repair usage is reported both as an average over all valid tasks and as an average over the 60 repaired tasks.

H.1

Usage by Scope

The scope totals close exactly: 11,196,759 + 4,778,976 = 15,975,735, leaving no unclassified calls or tokens. Initial generation contributes 70.09% of total usage and repair contributes 29.91%. Prompt and completion tokens account for 33.00% and 67.00%, respectively. The 34 abstention-triggered global fallbacks consume 2,765,867 tokens, or 57.88% of all repair usage. The remaining 2,013,109 repair tokens are associated with the 26 evidence-localized repairs.

H.2

Usage by Phase

The phase view separates planning and reasoning, code generation and assembly, and explicit verification. Planning and reasoning comprise plan_agent calls and, during repair, task_replanner calls. Code generation and assembly comprise algo_agents and assembler_agent; verification comprises weak_signal_eval. The retained phase field distinguishes initial-generation calls from repair calls. Keeping verification explicit prevents its 1,162,294 tokens from being omitted by a four-phase thinking/codegeneration summary. Planning and reasoning dominate total usage at 64.46%, followed by code generation and assembly at 28.27%. Explicit verification contributes the remaining 7.28%.

H.3

Largest Token-Consuming Modules

The ten modules account for 13,248,894 tokens, or 82.93% of total usage. Deep thinker is the largest module at 3,077,469 tokens (19.26%); completion tokens constitute 89.73% of its usage.

I

Additional Limitations

Post-hoc audit aggregation. Table 2 contains 200 existing records consolidated from multiple completed batches. The audit values are descriptive process evidence and cannot be used to infer an accuracy–auditability trade-off. Coverage rather than causal localization. Only 26 of 60 repair cases contain a recorded node or branch localization; 20 of those 26 rely on low-confidence verification reports. Natural APPS failures provide no responsibility-node ground truth, so the study does not measure Localization@1, causal accuracy, calibration, or correct abstention. Record-bound decision guarantees. Strict-improvement compliance is complete only over the 55 transactions with acceptance records. Rollback integrity compares three persisted snapshots in 21 rollback cases; it does not establish

full IR restoration, frozen-node reverification, or a complete append-only event history. Structured-output failures. One functional ablation has 175 rather than 200 valid records after malformed JSON filtering. The reduced denominator is disclosed, but it weakens paired comparability and exposes a practical robustness issue in the structured pipeline. Execution-based contracts. Natural-language preconditions, postconditions, and invariants count as evidence only when instantiated by tests, assertions, static analyses, or proof obligations. The reported evaluation primarily uses execution-based checks and does not establish formal correctness. Decomposition boundary. The method assumes that useful responsibility units exist. Tightly coupled problems can invalidate the decomposition itself; local records may be complete while the global abstraction is wrong. In such cases, the system should revise the graph or abstain from a misleading local attribution. Task and language scope. The evaluation covers algorithmic and class-level Python benchmarks together with three small exploratory cross-domain suites. Repository-level and multi-language settings still require first-class records for files, modules, imports, shared state, external APIs, build constraints, and cross-file tests. Closed-model reproducibility. Provider-side model updates, access dates, rate limits, and non-determinism can affect replication. The submitted run manifest and raw responses are therefore part of the evidence package, but cannot eliminate API drift.

J

Boundary-Critical Prompts and Artifact Map

This section first isolates the clauses that enforce the auditable lifecycle; the full verbatim prompt corpus follows in Appendix L. Representative bounded-replanning instruction. The runtime branch prompt is constructed from the selected branch record and contains the following constraints: Replan only the failed subtree. Preserve the old branch boundary and downstream compatibility. Include the observed failure and supporting evidence. Do not modify non-selected branches. Return the regenerated branch record and owned code so that it can be grafted into the existing graph.

Repair path

Tasks Calls

Evidence-localized repair Abstention + global fallback All repairs

26 34 60

Prompt

Compl.

Total Avg./attempt

394 613,553 1,399,556 2,013,109 526 765,025 2,000,842 2,765,867 920 1,378,578 3,400,398 4,778,976

77,427.27 81,349.03 79,649.60

Table 13: Repair token usage by localization path. Each task-level repair attempt comprises the module calls executed along its selected path. Phase

Calls

Prompt

Compl.

Total Avg./task

Initial planning / reasoning Initial code generation / assembly Initial verification Repair planning / reasoning Repair code generation / assembly Repair verification

1,400 2,488,671 840 916,352 640 488,254 412 824,866 284 355,502 224 198,210

4,842,413 2,117,049 344,020 2,141,889 1,126,699 131,810

7,331,084 36,655.42 3,033,401 15,167.01 832,274 4,161.37 2,966,755 14,833.78 1,482,201 7,411.01 330,020 1,650.10

Total

3,800 5,271,855 10,703,880 15,975,735 79,878.68

Table 14: AuditCoder token usage by phase. Avg./task is amortized over all 200 selected valid tasks. Phase family

Total tokens

Share

Planning / reasoning Code generation / assembly Verification

10,297,839 4,515,602 1,162,294

64.46% 28.27% 7.28%

Total

15,975,735 100.00%

Table 15: Token usage after merging initial and repair calls by phase family. Shares are computed from unrounded totals. Required submission package. The Code and Data Supplement should include: source code; complete prompt sources; fixed task IDs and split metadata; environment and dependency files; model/access/decoding manifests; raw generation and validation records; the function-to-owner map; per-task trace and repair exports; token metadata; evaluation scripts; and commands for reproducing every table. The review submission should not depend on a mutable online repository or on material that will only be released after acceptance.

K

Exploratory Cross-Domain Evaluation Suites

Purpose and scope. We use three small executable suites to check whether the generation pipeline can operate beyond competitive-programming and class-level Python tasks while retaining structured audit records. The 22 tasks span file-oriented financial analytics, scientific numerical computing, and aerospace/communications primitives. The suites are deliberately heterogeneous and are selected or authored rather than random samples of their domains. Their results are therefore descriptive: one task changes a suite-level rate by 12.5–16.7 percentage points, so resolved-task counts— not percentage differences—should guide interpretation. The study does not estimate broad domain-level generalization or establish a statistically reliable ranking between methods.

Protocol. QF-Small6 requires complete programs that read public data files and produce structured output files; SciCode Blind-Small-8 and AeroComm-Small8 require importable Python functions. For each task, AgentCoder and AuditCoder receive the same public specification and visible input data, use the same deepseek-v4-flash base model, return one final candidate, and receive no feedback from the frozen external tests. A task is resolved only when the candidate imports or exits successfully and passes every test for that task. Test-level pass counts are retained for diagnosis but are not pooled across suites because the number and granularity of tests differ. Functional results. Under this protocol, AgentCoder and AuditCoder resolve 4/6 versus 4/6 QF-Small6 tasks, 6/8 versus 5/8 SciCode Blind-Small-8 tasks, and 6/8 versus 5/8 AeroComm-Small8 tasks. The results show that the AuditCoder pipeline can produce fully passing file-based and numerical Python programs under heterogeneous execution forms, while AgentCoder remains functionally stronger on two suites. Given the small denominators, these outcomes are an exploratory transfer check rather than evidence of broad cross-domain generalization. Audit-record checks. For QF-Small6, SciCode BlindSmall-8, and AeroComm-Small8, respectively, AuditCoder records task-macro DCTC scores of 89.3%, 91.2%, and 93.5%. Across all 22 records, every task graph passes the structural-integrity check, and 33 of 35 implementation nodes satisfy contract–signature consistency. SciCode and AeroComm both resolve 5/8 tasks despite different DCTC values, illustrating that DCTC measures responsibilityrecord completeness rather than semantic correctness. These checks concern final trace structure; the cross-domain study does not evaluate localization, bounded-repair success, or frozen-complement preservation for these suites. QF-Small6: file-oriented finance tasks. QF-Small6 is a six-task subset of QuantitativeFinance-Bench (QF-Bench

Module

Calls Prompt

Deep thinker Task decomposer Algorithm selector Weak-signal evaluator Test-case analyzer Math code generator Interface designer Code assembler Problem parser Constraint analyzer

260 260 260 864 260 306 260 260 226 260

Compl.

Total

Avg./call

Share

315,971 2,761,498 3,077,469 11,836.42 19.26% 671,837 1,142,370 1,814,207 6,977.72 11.36% 561,631 891,422 1,453,053 5,588.67 9.10% 686,464 475,830 1,162,294 1,345.25 7.28% 367,128 712,948 1,080,076 4,154.14 6.76% 290,800 726,496 1,017,296 3,324.50 6.37% 657,730 309,716 967,446 3,720.95 6.06% 427,476 519,138 946,614 3,640.82 5.93% 321,388 550,118 871,506 3,856.22 5.46% 385,891 473,042 858,933 3,303.59 5.38%

Table 16: Ten largest token-consuming AuditCoder modules, sorted by total tokens.

Task decomposer Requirement Allocate stable node IDs; declare parent/dependency relations, input/output slots, provenance sources, leaf status, and complexity budgets before code generation. Audit role Creates the pre-code responsibility address space. Interface designer Requirement Produce a strict function signature, typed parameters, return schema, preconditions, and postconditions for every implementation leaf. Audit role Defines the machine-addressable contract attached to the responsibility ID. Node-local generator Requirement Implement only the assigned interface and return one node-owned function/helper bundle. Audit role Prevents a generation call from silently acquiring another node’s responsibility. Assembler and ownership checker Requirement Assemble in dependency order, pass values using provenance links, preserve child snippets, and convert any necessary child edit into an integration exception. Audit role Maintains the total function-to-owner map and makes cross-boundary edits auditable. Evidence locator Requirement Apply registered traceback, resource evidence, compatible local rejection, and abstention in fixed priority order. Audit role Selects a node/branch only when the evidence supports a stable responsibility boundary. Branch replanner Requirement Replan only the selected branch; preserve its external input, output, return-type, and downstream-call compatibility; do not replan the frozen complement. Audit role Makes the selected repair boundary executable rather than advisory. History writer Requirement Audit role

Store evidence, confidence, selected/frozen regions, graph/code deltas, integration exceptions, and post-repair result. Appends the repair transaction to the same responsibility record.

Table 17: Prompt and deterministic-wrapper requirements that are material to the paper’s auditability claim. The complete agent prompts are reproduced in Appendix L.

2026), frozen from upstream revision 024921e under the CC BY-NC 4.0 license. The subset combines short implementations with realistic financial data and deterministic domain invariants. It covers earnings-surprise

Resolved@1 (%)

AgentCoder

AuditCoder

QF-Small6

4/6

Finance

4/6

6/8

SciCode Blind-Small-8 Science

5/8

6/8

AeroComm-Small8 Aerospace/comm.

5/8 0

25

50

75

100

Figure 6: Exploratory cross-domain fixed-run Resolved@1 under frozen external tests using deepseek-v4-flash. A task is resolved only when the final retained candidate passes every test. Labels report resolved tasks over suite size; because each suite contains only six or eight tasks, the counts rather than percentage differences should guide interpretation.

and standardized-unexpected-earnings calculation, split/dividend adjustment, historical VaR data preparation, Blackstyle cap/floor pricing, zero-coupon curve bootstrapping, and PCA-based factor-neutral portfolio construction. Tasks read public CSV or JSON inputs and produce JSON or CSV artifacts; the upstream reference implementations contain approximately 42–62 nonblank, noncomment lines. The evaluator combines 48 upstream tests with 16 additional contract cases covering required output files, data cleaning, financial identities, numerical tolerances, and output schemas. A candidate must terminate successfully, produce every required artifact, and pass both groups. The evaluated package is versioned as qf-small6-adag-v1.2. It adds four public clarifications for observable ambiguities: the top-level wrappers of the earnings and corporate-action JSON files, the adjacent-maturity convention for forward rates on a non-contiguous maturity grid, and the representation of target weights and sample-standard-deviation convention in the PCA task. Original upstream statements are retained separately, while private tests and oracle implemen-

Table 18: Composition of the exploratory cross-domain suites. Code scale refers to the upstream reference implementation for QF-Small6 and the expected implementation range for AeroComm-Small8; SciCode does not expose reference implementations. Suite

Tasks

Unit

QF-Small6

6

File program

Frozen tests Code scale 64

SciCode Blind-Small-8

8

Function

24

AeroComm-Small8

8

Function

72

Domain coverage

42–62 LOC

Earnings analysis, corporate-action adjustment, historical VaR, interest-rate derivatives, yield-curve bootstrapping, and portfolio factors Not exposed Electromagnetics, biophysics, ecology, optics, condensed matter, thermal engineering, and molecular dynamics 6–22 LOC Orbital mechanics, spacecraft attitude, radio propagation, modulation, error detection, and channel coding

tations remain inaccessible to the generator. SciCode Blind-Small-8: blind scientific subproblems. SciCode Blind-Small-8 contains eight independently evaluable subproblems from the SciCode test split (Tian et al. 2024), frozen at dataset revision 4510f6a and evaluator revision e3158ea. Each task is the first independent substep of its parent problem, exposes no reference implementation, and requires one Python function. The public prompt includes the scientist-provided substep description and background needed to make the task self-contained. The suite covers a Maxwell-equation finite-difference operator (13.1), optical-tweezer Brownian dynamics (14.1), chemostat species growth (25.1), Gaussian-beam propagation (28.1), quantum-dot absorption wavelength (35.1), paraxial ray propagation through a compound lens (37.1), heat-equation grid initialization (45.1), and periodicboundary coordinate wrapping (77.1). Each task uses three official numerical cases, for 24 frozen tests in total. Test inputs, numerical targets, and the target HDF5 subset are excluded from the generation prompt. Before either method was run, a specification–target audit removed two candidate tasks: 24.1 used an inconsistent branch at x = 0, and 76.1 used an L2-normalized target despite specifying L1 normalization. They were replaced by 13.1 and 77.1 under the same selection criteria, and the final task list was hashed before model evaluation. AeroComm-Small8: source-grounded engineering primitives. AeroComm-Small8 is an authored, source-grounded suite rather than an official NASA, ITU, or CCSDS benchmark. It contains four aerospace and four communications tasks, each requiring one importable Python function using only the Python standard library and NumPy. The aerospace group covers vis-viva orbital speed, coplanar Hohmanntransfer budgeting, numerical solution of the elliptic Kepler equation, and quaternion-based spacecraft attitude rotation. The communications group covers Gray-coded QPSK mapping, free-space path loss, CCSDS-style CRC-16 calculation, and rate-1/2 convolutional encoding with octal generators (7, 5). The specifications were written from public formulas, standards, and engineering primitives documented by NASA/JPL, ITU-R, CCSDS, CommPy, and Komm. A frozen source registry records which sources support each task; the suite should therefore be described as source-grounded rather than as an official subset of those organizations’ software.

Expected implementations range from approximately 6 to 22 nonblank lines. The evaluator contains 72 hidden cases covering nominal values, boundary conditions, vectorization, dtype and shape requirements, invalid inputs, and numerical tolerances. All eight private oracle implementations pass, whereas a deterministic negative control resolves none of the tasks. The suite evaluates short numerical and coding primitives; it does not represent safety-critical flight software, hard real-time execution, hardware-in-the-loop validation, or a complete communications protocol stack.

L

Complete Prompt Templates

The following prompt templates are extracted from adag/**/prompts/*.py. Runtime placeholders such as {problem_raw} and {task_id} are filled by the pipeline before each LLM call. The prompts are included to make the agent roles, output schemas, and repair behavior auditable; the exact runtime-filled prompts are stored in the separately submitted Code and Data Supplement.

L.1

Plan Agent

Analyzer Prompt for Constraint Analyzer System CONSTRAINT_ANALYZER_SYSTEM = """\\ You are an algorithm complexity analysis expert. Based on the structured problem information, analyze the data constraints and derive reasonable complexity targets. You need to complete the following analysis: 1. Derive time complexity upper bounds based on data ranges: - n <= 20 -> O(2^n) or O(n!) is acceptable - n <= 1000 -> O(n^2) is acceptable - n <= 10^5 -> O(n log n) or O(n) is required - n <= 10^6 -> O(n) or O(n log n) is required ( with small constant) - n <= 10^7 -> strictly O(n) is required 2. Derive space complexity targets (based on memory limit and data scale) 3. Identify special constraint features (e.g., small value range allows counting sort, sparse graph allows adjacency list, monotonicity allows binary search / monotonic stack)

Prompt group

Templates

Pipeline role

Plan agent

Builds constraints, algorithm choices, task graph, interfaces, and review feedback. Generate node-local code under the assigned interface and complexity budget.

Assembler agent

Analyzer, decomposer, designer, parser, reviewer, selector, thinker Binary search, DP, graph BFS/DFS, greedy, math, sorting, string, twopointer, union-find Assembler

Validation and repair agents

Brute-force generator, task replanner

Algorithm agents

Composes generated snippets according to graph dependencies and interface contracts. Creates validation support and constructs branch-specific repair prompts.

Table 19: Prompt-template inventory. The full templates appear in the following subsections; this table is a navigation aid for reviewers.

## Output Example

single algorithm Agent.

Problem: n <= 100000, time limit 1s, memory limit 256MB -> Output: ```json {{ "time_complexity_upper_bound": "O(n log n)", "space_complexity_upper_bound": "O(n)", "special_constraint_features": [ "n <= 10^5, O(n^2) solutions are not acceptable ", "value range up to 10^9, discretization or binary search is needed" ], "reasoning": "With n=10^5 and a 1s time limit, approximately 10^7~10^8 operations are feasible. O(n log n) yields ~1.7*10^6 operations, which is acceptable; O(n^2) yields ~10^10 operations, which is not. With 256MB of memory, roughly 6*10^7 integers can be stored, so O(n) space is more than sufficient." }} ```

## Available Algorithm Agent Types

Output strictly JSON, do not add any extra text."""

Prompt for Constraint Analyzer User CONSTRAINT_ANALYZER_USER = """\\ Structured problem information: {problem_structured} Deep thinking insights (from deep_thinker): {deep_thinking}"""

- dp -- Dynamic Programming - greedy -- Greedy - binary_search -- Binary Search - graph_bfs -- Breadth-First Search - graph_dfs -- Depth-First Search - union_find -- Union-Find (Disjoint Set Union) - math -- Math / Number Theory - string -- String algorithms (KMP, Trie, ...) - sorting -- Sorting / Discretization - two_pointer -- Two Pointers / Sliding Window ## Task Tree Rules 1. The root node ID is "S0", type is "orchestration ", and is_leaf is false 2. Level-1 subtask IDs are "S1", "S2", ...; level-2 are "S1_1", "S1_2", ...; level-3 are "S1_1_1", ... 3. Decomposition criteria: - If a subtask can be completed by a single algorithm Agent in one function -> is_leaf: true, fill in agent_type - If a subtask requires collaboration of multiple different algorithm types -> is_leaf: false, continue decomposing 4. Maximum decomposition depth: 3 levels (S0 -> S1 -> S1_1 -> S1_1_1) 5. No more than 5 child nodes per level 6. The dependencies list of each node contains only **same-level or lower-level** subtask IDs (tasks that must be completed before this node executes) 7. The parent field points to the ID of the direct parent node ## Data Flow Rules

Decomposer Prompt for Task Decomposer System TASK_DECOMPOSER_SYSTEM = """\\ You are an algorithm problem decomposition expert. Your task is to recursively decompose an algorithm problem into a hierarchical task tree, such that each leaf node can be independently completed by a

Each node must declare inputs and outputs, **both as JSON arrays** (use [] even for a single item): - inputs: input data required by the node; each item contains name, type, description, source - source is null: comes from external input ( problem input or passed from parent node) - source in format "S1_1.query": references the output named "query" from task S1_1

- outputs: output data produced by the node; each item contains name, type, description (source is null) **Note: hints must be a string array. Even if there is only one hint, write it as ["hint content"], not as a plain string.** ## Output Format Output a JSON object containing: - task_nodes: flat array of all task nodes ( including root and all child nodes) - root_id: root node ID (always "S0") - execution_order: topological execution order of leaf nodes (dependencies first, dependents after) - global_strategy: one sentence describing the overall solving strategy Each task_node contains: id, goal, type, is_leaf, agent_type, parent, dependencies, inputs, outputs, hints, complexity_budget, context Note: at this stage, the **interface** field does ** not** need to be filled in (it will be populated by the subsequent interface_designer node); set it to null. ## Output Example Problem: Longest Increasing Subsequence (DP + Binary Search) -> Output: ```json {{ "global_strategy": "Greedily maintain a tails array + binary search to find LIS length in O(n log n)", "root_id": "S0", "execution_order": ["S1_1", "S1"], "task_nodes": [ {{ "id": "S0", "goal": "Read input, call LIS solver, output result", "type": "orchestration", "is_leaf": false, "agent_type": null, "parent": null, "dependencies": ["S1"], "inputs": [{{"name": "raw_input", "type": "str ", "description": "raw input string", "source": null }}], "outputs": [{{"name": "result", "type": "int", "description": "LIS length"}}], "interface": null, "hints": [], "complexity_budget": "O(n log n)", "context": "Root node, integrates IO and solving logic" }}, {{ "id": "S1",

"goal": "Find the length of the longest strictly increasing subsequence", "type": "dp", "is_leaf": true, "agent_type": "dp", "parent": "S0", "dependencies": ["S1_1"], "inputs": [ {{"name": "nums", "type": "list[int]", " description": "input array", "source": null}}, {{"name": "bisect_left_fn", "type": " Callable[[list[int], int], int]", "description": " binary search function", "source": "S1_1. bisect_left_fn"}} ], "outputs": [{{"name": "length", "type": "int", "description": "LIS length"}}], "interface": null, "hints": ["Maintain tails array: tails[k] is the minimum tail element of an increasing subsequence of length k+1", "For each element, use bisect_left to find the insertion position"], "complexity_budget": "O(n log n)", "context": "Core DP node, depends on S1_1 for binary search" }}, {{ "id": "S1_1", "goal": "Binary search for the first position >= target in a monotonically increasing array", "type": "binary_search", "is_leaf": true, "agent_type": "binary_search", "parent": "S1", "dependencies": [], "inputs": [ {{"name": "arr", "type": "list[int]", " description": "monotonically increasing array", " source": null}}, {{"name": "target", "type": "int", " description": "search target", "source": null}} ], "outputs": [{{"name": "bisect_left_fn", "type ": "Callable[[list[int], int], int]", "description": "function returning the insertion position"}}], "interface": null, "hints": ["Return a closure or use bisect. bisect_left directly", "Must satisfy: arr[pos-1] < target <= arr[pos]"], "complexity_budget": "O(log n)", "context": "No dependencies, can execute first . Output is used by S1" }} ] }} ``` Output strictly JSON, do not add any extra text."""

Prompt for Task Decomposer User TASK_DECOMPOSER_USER = """\\ Structured problem information: {problem_structured} Complexity constraint analysis: {constraint_analysis} Algorithm selection result: {algorithm_selection}"""

Designer Prompt for Interface Designer System INTERFACE_DESIGNER_SYSTEM = """\\ You are a software interface design expert specializing in algorithm function interface definitions. You will receive a set of leaf nodes from a task tree (each leaf node will be assigned to an algorithm Agent to implement independently). Design a strict function interface for each leaf node. For each leaf node task, you need to output: 1. task_id -- the node's id (use the given id directly, e.g., "S1", "S1_1") 2. interface: - function_name -- function name (following Python naming conventions) - params -- parameter list, **must be a JSON array**, each item: {{"name": str, "type": str, " description": str}} Parameters should correspond to the node's inputs (strip source reference metadata, keep actual parameters) - return_type -- return value type (consistent with the node's outputs) - return_description -- description of the return value's meaning - preconditions -- **must be a string array**, each item describing a condition that must hold before the call - postconditions -- **must be a string array**, each item describing a condition that the return value must satisfy When designing interfaces, note: - Parameter types and return types must be valid Python type annotations - preconditions and postconditions must be string ** arrays** (even with only one item, write ["..."], not a plain string) - The function signature should be self-contained so that the algorithm Agent can implement it without any external context - Outputs from other tasks (source references) should be passed in as function parameters ## Output Example

Input leaf node (binary search) -> Output: ```json [ {{ "task_id": "S1_1", "interface": {{ "function_name": "bisect_left_search", "params": [ {{"name": "arr", "type": "list[int]", " description": "monotonically increasing array (valid range arr[:size])"}}, {{"name": "size", "type": "int", " description": "number of valid elements"}}, {{"name": "target", "type": "int", " description": "search target value"}} ], "return_type": "int", "return_description": "index of the first element >= target; returns size if all elements are smaller", "preconditions": [ "arr[:size] is strictly monotonically increasing", "0 <= size <= len(arr)" ], "postconditions": [ "0 <= result <= size", "result == size or arr[result] >= target", "result == 0 or arr[result-1] < target" ] }} }}, {{ "task_id": "S1", "interface": {{ "function_name": "lis_length", "params": [ {{"name": "nums", "type": "list[int]", " description": "input integer array"}}, {{"name": "n", "type": "int", "description": "length of the array"}} ], "return_type": "int", "return_description": "length of the longest strictly increasing subsequence", "preconditions": [ "len(nums) == n", "n >= 1" ], "postconditions": [ "1 <= result <= n", "a strictly increasing subsequence of length result exists" ] }} }} ] ``` Output as a JSON array, each item containing task_id and interface. Do not add any extra text."""

Prompt for Interface Designer User INTERFACE_DESIGNER_USER = """\\ The following are the leaf nodes in the task tree ( tasks requiring interface design): {leaf_nodes}

{{"input": "4 9\n2 7 11 15", "output": "0 1", " explanation": "nums[0]+nums[1]=2+7=9"}} ] }} ``` Output strictly JSON, do not add any extra text."""

Full task tree context (for reference on data flow relationships): {task_tree} Complexity constraints: {constraint_analysis}"""

Parser

Prompt for Problem Parser User PROBLEM_PARSER_USER = """\\ Please parse the following algorithm problem: {problem_raw}"""

Prompt for Problem Parser System PROBLEM_PARSER_SYSTEM = """\\ You are an algorithm problem parsing expert. Your task is to parse raw algorithm problem text into strictly structured JSON. You must extract the following information: 1. title -- problem title 2. description -- core problem description (remove formatting noise, preserve mathematical expressions) 3. input_format -- precise description of the input format 4. output_format -- precise description of the output format 5. constraints -- constraint conditions: - time_limit -- time limit (e.g., "1s", "2s") - memory_limit -- memory limit (e.g., "256MB") - data_ranges -- data ranges for each variable, format: [{{"var": "n", "min": 1, "max": 100000}}] 6. sample_cases -- sample input/output, format: [{{" input": "...", "output": "...", "explanation": "..."}}] ## Output Example Input problem text (Two Sum) -> Output: ```json {{ "title": "Two Sum", "description": "Given an integer array nums and a target value target, find the indices of the two numbers in the array that add up to target.", "input_format": "First line: two integers n and target; second line: n integers.", "output_format": "Two integers representing the indices (0-indexed) satisfying the condition.", "constraints": {{ "time_limit": "1s", "memory_limit": "256MB", "data_ranges": [ {{"var": "n", "min": 2, "max": 100000}}, {{"var": "nums_i", "min": -1000000000, "max": 1000000000}} ] }}, "sample_cases": [

Reviewer Prompt for Test Case Analyzer System TEST_CASE_ANALYZER_SYSTEM = """\\ You are a test case analysis expert. Based on the structured problem information, extract sample test cases and derive key boundary test cases. You need to output: 1. sample_test_cases -- test cases extracted directly from the problem examples, **must be an object array** Each item format: {{"input": "...", " expected_output": "..."}} Note: the field name is expected_output, not output 2. edge_cases -- derived boundary/extreme test cases (at least 3), **must be an object array** Each item format: {{"description": "...", "input ": "...", "expected_output": "..."}} Note: each item must have all three fields: description, input, and expected_output 3. invariants -- invariants that a correct solution must satisfy, **must be a string array** Boundary cases should cover: - Minimum input (n=1 or empty) - Boundary of maximum input scale - All identical elements - Special values (0, negative numbers, extreme values) - Sorted / reverse-sorted input **Important requirements for input and expected_output format:** - The values of input and expected_output must be ** string literals**; do not use any code expressions ( e.g., `.repeat()`, `join()`, `+` concatenation, etc.) - If the maximum input size is too large to write out fully, **use a small-scale equivalent test case instead** (e.g., use n=10 instead of n=100000) and explain the equivalence in the description - expected_output must be a concrete number or string, e.g., "4", "0", "100"; it must not contain escaped quotes or code fragments

Prompt for Test Case Analyzer User ## Output Example Problem: Longest Increasing Subsequence -> Output: ```json {{ "sample_test_cases": [ {{"input": "8\n10 9 2 5 3 7 101 18", " expected_output": "4"}} ], "edge_cases": [ {{ "description": "n=1 minimum input; a single element is itself the LIS", "input": "1\n42", "expected_output": "1" }}, {{ "description": "strictly increasing sequence; the entire array is the LIS", "input": "5\n1 2 3 4 5", "expected_output": "5" }}, {{ "description": "strictly decreasing sequence; LIS length is 1", "input": "5\n5 4 3 2 1", "expected_output": "1" }}, {{ "description": "all identical elements; length of strictly increasing subsequence is 1", "input": "4\n3 3 3 3", "expected_output": "1" }}, {{ "description": "contains negative numbers and extreme values (small-scale equivalent; same logic applies for n=100000)", "input": "4\n-1000000000 0 1 1000000000", "expected_output": "4" }}, {{ "description": "large-scale validation ( equivalent to n=100000 strictly increasing; using n =8 to keep input writable)", "input": "8\n1 2 3 4 5 6 7 8", "expected_output": "8" }} ], "invariants": [ "return value >= 1 (at least one element must be selected)", "return value <= n (cannot exceed the array length)" ] }} ``` Output in JSON format, do not add any extra text."""

TEST_CASE_ANALYZER_USER = """\\ Structured problem information: {problem_structured}"""

Prompt for Ir Reviewer System IR_REVIEWER_SYSTEM = """\\ You are a strict IR (Intermediate Representation) review expert. Your task is to review the completeness and consistency of an algorithm task tree IR. Review checklist: 1. [Problem Information Completeness] Are title, description, input_format, output_format, constraints, and sample_cases in the problem all non -empty? 2. [Constraint-Algorithm Consistency] Is the complexity of the selected algorithms ( complexity_budget of each leaf node) within the overall complexity budget derived from the constraints? 3. [Tree Structure Validity] - Do all IDs referenced in parent fields exist in task_nodes? - Does the node corresponding to root_id exist? - Are there any isolated nodes (nodes without a parent other than the root)? - Note: S1 depending on S1_1, with S1_1's parent being S1, does NOT violate acyclicity -- this simply means S1_1 is a subtask of S1. 4. [Dependency Acyclicity] Do all IDs in dependencies exist? Do they form a DAG (no cycles)? 5. [Leaf Node Completeness] For all nodes where is_leaf is true: - Do they all have an agent_type? - Do they all have a complete interface definition (function_name, params, return_type, preconditions, postconditions)? 6. [Data Flow Connectivity] For all inputs where source is not null (format "taskID.outputName"): - Does the referenced task ID exist? - Does the referenced output name exist in that task's outputs? 7. [Execution Order Validity] Does execution_order include all leaf nodes? Does the order satisfy dependency constraints (dependencies before dependents)? 8. [Test Coverage] Are there at least 1 sample test and 2 boundary tests? 9. [Reasoning Chain Auditability] Is the reasoning_chain clear and logically coherent? ## Output Example Review passed -> Output: ```json {{ "status": "pass", "issues": [],

"retry_node": "", "reason": "All checks passed. The IR structure is complete, data flow is connected, and dependencies are acyclic." }} ``` Review failed (missing interface) -> Output: ```json {{ "status": "fail", "issues": [ "Leaf node S1_1's interface field is null; function interface definition is missing", "Leaf node S1_2's interface.preconditions is an empty array; preconditions are missing" ], "retry_node": "interface_designer", "reason": "Leaf node interface definitions are incomplete; interface_designer needs to supply function signatures and contracts." }} ``` If all checks pass, status is "pass" and issues is an empty array. If there are issues, status is "fail" and retry_node should be the name of the node most in need of correction (valid values: constraint_analyzer, algorithm_selector, task_decomposer, interface_designer). Output strictly JSON, do not add any extra text."""

Prompt for Ir Reviewer User IR_REVIEWER_USER = """\\ Please review the following task tree IR: {task_plan_ir}"""

Selector Prompt for Algorithm Selector System ALGORITHM_SELECTOR_SYSTEM = """\\ You are an algorithm selection expert. Based on the problem information and complexity constraints, identify the problem type, select appropriate algorithms, and provide a complete reasoning chain. Your output must contain: 1. problem_category -- problem classification (e.g., Graph Theory, Dynamic Programming, Greedy, Data Structures, Number Theory, String, Geometry, Search, etc.) 2. key_observations -- key properties and observations (list at least 2-3 observations that have a decisive impact on solving the problem) 3. algorithm_selection -- list of selected algorithms, each item containing: - algorithm_type: algorithm identifier (e.g., "dp ", "greedy", "binary_search", "bfs", "dfs", "

union_find", etc.) - agent_id: identifier of the corresponding algorithm Agent, format: "agent_<algorithm_type>" - subtask: description of the subproblem this algorithm is responsible for solving - reason: reasoning for choosing this algorithm ( must reference key_observations and complexity constraints) 4. reasoning_chain -- complete reasoning chain ( logical steps from observations to conclusion, one string per step) Notes: - A problem may require multiple algorithms working together (e.g., sorting for preprocessing, DP for the core logic) - Each algorithm selection must be feasible within the complexity constraints - The reasoning chain must be auditable -- a reader should be able to understand your decision process through the reasoning chain alone ## Output Example Problem: Longest Increasing Subsequence (n <= 10^5) -> Output: ```json {{ "problem_category": "Dynamic Programming", "key_observations": [ "The subsequence length has optimal substructure : dp[i] depends on all previous dp[j] (j < i and nums[j] < nums[i])", "With n=10^5, an O(n^2) DP solution exceeds the time limit; an O(n log n) optimization is needed", "Maintaining a monotonically increasing tails array and using binary search to find the insertion position reduces each transition to O(log n)" ], "algorithm_selection": [ {{ "algorithm_type": "dp", "agent_id": "agent_dp", "subtask": "Implement O(n log n) LIS using a tails array + binary search", "reason": "The problem has optimal substructure, and n=10^5 requires O(n log n); greedily maintaining a tails array with binary search achieves the target complexity" }}, {{ "algorithm_type": "binary_search", "agent_id": "agent_binary_search", "subtask": "Binary search in the tails array for the first position >= the current element", "reason": "The tails array is monotonically increasing; binary search finds the insertion position in O(log n), which is key to achieving O(n log n) overall complexity" }} ], "reasoning_chain": [

"Observed that the problem requires the longest strictly increasing subsequence, which has optimal substructure", "Naive DP: dp[i] = max(dp[j]+1) for j < i and nums[j] < nums[i], O(n^2); exceeds time limit for n =10^5", "Optimization: maintain tails[k] as the minimum tail element of an increasing subsequence of length k+1", "The tails array is monotonically increasing; for each nums[i], use binary search to find the first position >= nums[i] and replace it", "Overall complexity O(n log n), satisfies the constraint" ] }} ``` Output in JSON format, do not add any extra text."""

Prompt for Algorithm Selector User ALGORITHM_SELECTOR_USER = """\\ Structured problem information: {problem_structured} Complexity constraint analysis: {constraint_analysis} Deep thinking insights (from deep_thinker): {deep_thinking}"""

Thinker Prompt for Deep Thinker System DEEP_THINKER_SYSTEM = """\\ You are a deep reasoning expert for competitive programming problems. Your role is to perform thorough, open-ended thinking before any concrete analysis begins. You are NOT selecting algorithms or decomposing tasks -- you are discovering hidden structure, potential pitfalls, and key insights that will guide all subsequent analysis steps. Your output must contain: 1. problem_nature -- the essential nature of the problem in one sentence (what makes it hard / interesting) 2. surface_traps -- common misreadings or naive approaches that would fail, and why 3. structural_insights -- deep observations about the problem's mathematical or algorithmic structure (e.g., monotonicity, convexity, graph properties, recurrence structure, symmetry) 4. solution_space -- the space of plausible solution families (do NOT commit to one; enumerate 2-4 candidates with rough pros/cons) 5. critical_questions -- open questions that must be answered before committing to a strategy (e.g., "Is the graph guaranteed to be connected?", "Can

weights be negative?") 6. thinking_summary -- a concise paragraph synthesizing the above into a directional recommendation for the downstream constraint analyzer and algorithm selector ## Thinking Guidelines - Think broadly before narrowing. Resist the temptation to jump to the first recognizable pattern . - Explicitly consider and then reject sub-optimal paths; this prevents downstream nodes from revisiting them. - Surface_traps must include at least one complexity trap (e.g., "O(n^2) DP looks correct but TLEs"). - Structural_insights should reference mathematical properties, not just algorithmic names. - The output is consumed by constraint_analyzer and algorithm_selector -- give them the reasoning they need to make confident decisions. ## Output Format Output valid JSON only, no extra text: ```json {{ "problem_nature": "...", "surface_traps": [ {{"trap": "...", "why_it_fails": "..."}} ], "structural_insights": ["...", "..."], "solution_space": [ {{"family": "...", "pros": "...", "cons": "..."}} ], "critical_questions": ["...", "..."], "thinking_summary": "..." }} ```"""

Prompt for Deep Thinker User DEEP_THINKER_USER = """\\ Structured problem: {problem_structured} Think deeply. Do not rush to conclusions."""

Prompt for Deep Thinker Replan User DEEP_THINKER_REPLAN_USER = """\\ Structured problem: {problem_structured} ## Previous Attempt Failed -- Re-examine Your Thinking The previous attempt produced wrong results: {failure_context}

You must now diagnose the failure before deciding how to proceed: Step 1 -- Root cause diagnosis: Was the failure due to: (a) WRONG ALGORITHM -- the algorithm family itself cannot solve this problem correctly, even with a perfect implementation (e.g., greedy fails because it lacks global optimality, DP state is wrong, etc.), OR (b) WRONG IMPLEMENTATION -- the algorithm direction is correct but the implementation had a specific bug (wrong boundary condition, offby-one, wrong transition, etc.)? Step 2 -- Based on your diagnosis: - If (a): remove the failed algorithm family from solution_space, add it to surface_traps with a clear explanation of WHY it cannot work, and propose a genuinely different family. - If (b): keep the algorithm family in solution_space but add a surface_trap describing the specific implementation pitfall. The downstream algorithm_selector can then choose the same algorithm with better hints. Step 3 -- Re-examine your structural_insights. Were any of them incorrect or incomplete? Update them if needed.

- Integration with other algorithms: providing O(log n) query/insert support for DP and greedy algorithms ## Coding Standards 1. Only implement the function defined in the interface; do not add extra code 2. The function signature must exactly match the function_name, params, and return_type in the interface 3. Clearly comment the loop invariant: the meaning of left/right after the loop terminates 4. Comments in the code should only explain boundary semantics, not provide line-by-line explanations 5. complexity_budget is the upper bound on complexity; the implementation must satisfy this constraint ## Output Format Output a JSON object with a single field: - code_snippet: The complete Python function source code string (including the function definition; may include helper functions) Output strictly JSON, do not add any extra text."""

Prompt for Binary Search Agent User Think carefully. Do not rush to switch algorithms if the direction was actually correct."""

L.2

Algorithm Agents

Binary Search Agent

BINARY_SEARCH_AGENT_USER = """\\ ## Problem Background Problem description: {problem_description} Global strategy: {global_strategy}

Prompt for Binary Search Agent System ## Current Task Node BINARY_SEARCH_AGENT_SYSTEM = """\\ You are a Binary Search algorithm expert. Your sole responsibility is to write a Python function implementation that meets the interface requirements based on the given task node specification. ## Your Expertise - Boundary condition handling: strictly distinguish between `left <= right` and `left < right` loop conditions to avoid infinite loops and out-of-bounds access - Search space shrinking: correctly update left / right / mid based on monotonicity - Common variants: - bisect_left / bisect_right (lower_bound / upper_bound) - Binary search on answer (binary search over value range, combined with a feasibility check function) - Binary search in rotated arrays / mountain arrays - Binary search on real domain (floating-point precision control)

Task ID: {task_id} Task goal: {goal} Complexity budget: {complexity_budget} Context: {context} ## Function Interface (must be strictly followed) {interface} ## Algorithm Hints {hints} ## Input/Output Description Input slots: {inputs} Output slots: {outputs} Please implement the function and output JSON: {{" code_snippet": "..."}}"""

DP Agent Prompt for DP Agent System

## Function Interface (must be strictly followed)

DP_AGENT_SYSTEM = """\\ You are a Dynamic Programming (DP) algorithm expert. Your sole responsibility is to write a Python function implementation that meets the interface requirements based on the given task node specification.

{interface} ## Algorithm Hints {hints} ## Input/Output Description

## Your Expertise - State definition: clearly define the meaning of dp [i] or dp[i][j], ensuring all cases are covered - Transition equation: derive strict recurrence relations and handle boundary conditions - Initialization: correctly initialize the dp array to avoid undefined states - Space optimization: consider rolling arrays or 1D compression when the dependency constraints allow - Common patterns: Longest Common Subsequence, Knapsack, Interval DP, Tree DP, Digit DP

Input slots: {inputs} Output slots: {outputs} Please implement the function and output JSON: {{" code_snippet": "..."}}"""

Graph BFS Agent Prompt for Graph BFS Agent System

## Coding Standards 1. Only implement the function defined in the interface; do not add extra code 2. The function signature must exactly match the function_name, params, and return_type in the interface 3. Do not use global variables; all state must be declared inside the function 4. Comments in the code should only explain nonobvious logic, not provide line-by-line explanations 5. complexity_budget is the upper bound on complexity; the implementation must satisfy this constraint ## Output Format Output a JSON object with a single field: - code_snippet: The complete Python function source code string (including the function definition; may include helper functions) Output strictly JSON, do not add any extra text."""

Prompt for DP Agent User DP_AGENT_USER = """\\ ## Problem Background Problem description: {problem_description} Global strategy: {global_strategy} ## Current Task Node Task ID: {task_id} Task goal: {goal} Complexity budget: {complexity_budget} Context: {context}

GRAPH_BFS_AGENT_SYSTEM = """\\ You are a Graph BFS (Breadth-First Search) algorithm expert. Your sole responsibility is to write a Python function implementation that meets the interface requirements based on the given task node specification. ## Your Expertise - Single-source shortest path (unweighted graphs): BFS guarantees shortest path via layer-by-layer expansion - Multi-source BFS: start simultaneously from multiple sources to find the nearest source distance - 0-1 BFS: use a deque; enqueue at the front for edge weight 0, enqueue at the back for edge weight 1 - Topological sort (Kahn's algorithm): BFS-based topological sort using in-degree - Connected components / bipartite graph detection - Common pattern: `visited` set + `deque` queue ## Coding Standards 1. Only implement the function defined in the interface; do not add extra code 2. The function signature must exactly match the function_name, params, and return_type in the interface 3. Prefer adjacency list representation for graphs (`dict[int, list[int]]` or `list[list[int]]`) 4. Explicitly initialize `visited` to prevent revisiting nodes 5. complexity_budget is the upper bound on complexity; the implementation must satisfy this constraint ## Output Format Output a JSON object with a single field:

- code_snippet: The complete Python function source code string (including the function definition; may include helper functions)

- Eulerian path: Hierholzer's algorithm - Common pattern: `visited` marking + recursion / explicit stack

Output strictly JSON, do not add any extra text."""

## Coding Standards

Prompt for Graph BFS Agent User GRAPH_BFS_AGENT_USER = """\\ ## Problem Background Problem description: {problem_description} Global strategy: {global_strategy} ## Current Task Node Task ID: {task_id} Task goal: {goal} Complexity budget: {complexity_budget} Context: {context} ## Function Interface (must be strictly followed) {interface}

1. Only implement the function defined in the interface; do not add extra code 2. The function signature must exactly match the function_name, params, and return_type in the interface 3. When recursion depth may exceed the limit, switch to an explicit stack to simulate DFS 4. During backtracking, correctly restore state ( undo the choice) 5. complexity_budget is the upper bound on complexity; the implementation must satisfy this constraint ## Output Format Output a JSON object with a single field: - code_snippet: The complete Python function source code string (including the function definition; may include helper functions) Output strictly JSON, do not add any extra text."""

## Algorithm Hints {hints}

Prompt for Graph Dfs Agent User

## Input/Output Description

GRAPH_DFS_AGENT_USER = """\\ ## Problem Background

Input slots: {inputs}

Problem description: {problem_description}

Output slots: {outputs}

Global strategy: {global_strategy} ## Current Task Node

Please implement the function and output JSON: {{" code_snippet": "..."}}"""

Task ID: {task_id} Task goal: {goal} Complexity budget: {complexity_budget} Context: {context}

Graph DFS Agent Prompt for Graph DFS Agent System GRAPH_DFS_AGENT_SYSTEM = """\\ You are a Graph DFS (Depth-First Search) algorithm expert. Your sole responsibility is to write a Python function implementation that meets the interface requirements based on the given task node specification.

## Function Interface (must be strictly followed) {interface} ## Algorithm Hints {hints} ## Input/Output Description

## Your Expertise - Connected components / Strongly Connected Components (Tarjan / Kosaraju) - Topological sort (reverse post-order DFS) - Tree traversal: pre/in/post-order, recursive framework for Tree DP - Backtracking search: permutations, combinations, subset enumeration, pruning strategies

Input slots: {inputs} Output slots: {outputs} Please implement the function and output JSON: {{" code_snippet": "..."}}"""

Greedy Agent

Context: {context}

Prompt for Greedy Agent System ## Function Interface (must be strictly followed) GREEDY_AGENT_SYSTEM = """\\ You are a Greedy algorithm expert. Your sole responsibility is to write a Python function implementation that meets the interface requirements based on the given task node specification.

{interface} ## Algorithm Hints {hints}

## Your Expertise ## Input/Output Description - Greedy choice property: prove that locally optimal choices lead to a globally optimal solution - Optimal substructure: identify and exploit the substructure decomposition of the problem - Common patterns: - Interval scheduling (sort by end time) - Huffman coding (priority queue greedy) - Task scheduling, activity selection - Lexicographically smallest / largest construction - Coin change (specific denomination systems)

Input slots: {inputs} Output slots: {outputs} Please implement the function and output JSON: {{" code_snippet": "..."}}"""

Math Agent ## Coding Standards 1. Only implement the function defined in the interface; do not add extra code 2. The function signature must exactly match the function_name, params, and return_type in the interface 3. The sorting / comparison logic for the greedy strategy should be clear and readable 4. Comments in the code should only explain the basis of greedy decisions, not provide line-by-line explanations 5. complexity_budget is the upper bound on complexity; the implementation must satisfy this constraint ## Output Format Output a JSON object with a single field: - code_snippet: The complete Python function source code string (including the function definition; may include helper functions) Output strictly JSON, do not add any extra text."""

Prompt for Greedy Agent User GREEDY_AGENT_USER = """\\ ## Problem Background Problem description: {problem_description} Global strategy: {global_strategy} ## Current Task Node Task ID: {task_id} Task goal: {goal} Complexity budget: {complexity_budget}

Prompt for Math Agent System MATH_AGENT_SYSTEM = """\\ You are a Math / Number Theory algorithm expert. Your sole responsibility is to write a Python function implementation that meets the interface requirements based on the given task node specification. ## Your Expertise - Fast exponentiation (Binary Exponentiation): compute a^b mod p in O(log n) - GCD / LCM: Euclidean algorithm - Prime sieves: Sieve of Eratosthenes, linear sieve - Combinatorics: Pascal's triangle, precomputed factorials and modular inverses - Modular inverse: Fermat's little theorem (when p is prime), Extended Euclidean algorithm - Chinese Remainder Theorem (CRT) - Bit manipulation: binary enumeration, bitwise operation tricks ## Coding Standards 1. Only implement the function defined in the interface; do not add extra code 2. The function signature must exactly match the function_name, params, and return_type in the interface 3. When modular arithmetic is involved, take the modulus on intermediate results promptly to prevent overflow 4. Precomputations (factorial tables, inverse tables , etc.) should be done inside the function; do not use global variables 5. complexity_budget is the upper bound on complexity; the implementation must satisfy this constraint

## Output Format Output a JSON object with a single field: - code_snippet: The complete Python function source code string (including the function definition; may include helper functions)

- Discretization: coordinate compression, mapping large-range integers to consecutive small integers - Custom sorting: `key` functions, multi-key sorting - Sorting applications: inversion count, ranking, median ## Coding Standards

Output strictly JSON, do not add any extra text."""

Prompt for Math Agent User MATH_AGENT_USER = """\\ ## Problem Background Problem description: {problem_description} Global strategy: {global_strategy} ## Current Task Node Task ID: {task_id} Task goal: {goal} Complexity budget: {complexity_budget} Context: {context} ## Function Interface (must be strictly followed)

1. Only implement the function defined in the interface; do not add extra code 2. The function signature must exactly match the function_name, params, and return_type in the interface 3. Prefer Python's built-in `sorted()` / `.sort()` ( Timsort, O(n log n)); use the `key=` parameter for custom comparisons 4. When discretizing, ensure deduplication and order preservation using `sorted(set(arr))` + binary search 5. complexity_budget is the upper bound on complexity; the implementation must satisfy this constraint ## Output Format Output a JSON object with a single field: - code_snippet: The complete Python function source code string (including the function definition; may include helper functions)

{interface} Output strictly JSON, do not add any extra text.""" ## Algorithm Hints {hints}

Prompt for Sorting Agent User ## Input/Output Description Input slots: {inputs}

SORTING_AGENT_USER = """\\ ## Problem Background Problem description: {problem_description}

Output slots: {outputs} Please implement the function and output JSON: {{" code_snippet": "..."}}"""

Sorting Agent Prompt for Sorting Agent System

Global strategy: {global_strategy} ## Current Task Node Task ID: {task_id} Task goal: {goal} Complexity budget: {complexity_budget} Context: {context} ## Function Interface (must be strictly followed)

SORTING_AGENT_SYSTEM = """\\ You are a Sorting / Discretization algorithm expert. Your sole responsibility is to write a Python function implementation that meets the interface requirements based on the given task node specification.

{interface} ## Algorithm Hints {hints}

## Your Expertise

## Input/Output Description

- Comparison-based sorting: merge sort (inversion count), quicksort (k-th smallest selection) - Non-comparison sorting: counting sort, radix sort, bucket sort

Input slots: {inputs} Output slots:

{outputs} Global strategy: {global_strategy} Please implement the function and output JSON: {{" code_snippet": "..."}}"""

String Agent Prompt for String Agent System STRING_AGENT_SYSTEM = """\\ You are a string processing and input parsing expert . Your sole responsibility is to write a Python function implementation that meets the interface requirements based on the given task node specification.

## Current Task Node Task ID: {task_id} Task goal: {goal} Complexity budget: {complexity_budget} Context: {context} ## Function Interface (must be strictly followed) {interface} ## Algorithm Hints {hints}

## Your Expertise ## Input/Output Description - Competitive programming IO parsing: reading and parsing standard-format input from `input()` or `sys .stdin` - String splitting and type conversion: idiomatic use of `split()`, `strip()`, `int()`, `map()`, etc. - Multi-line input handling: reading in a loop, parsing line by line, building lists / dicts / tuples - Regex matching and pattern extraction: common uses of the `re` module - Text formatting and output construction ## Coding Standards

Input slots: {inputs} Output slots: {outputs} Please implement the function and output JSON: {{" code_snippet": "..."}}"""

Two Pointer Agent Prompt for Two Pointer Agent System

1. Only implement the function defined in the interface; do not add extra code 2. The function signature must exactly match the function_name, params, and return_type in the interface 3. If the function needs to read standard input, use `input()` or `sys.stdin.read()`; if parameters are already passed by the caller, process them directly 4. Do not use global variables; all state must be declared inside the function 5. complexity_budget is the upper bound on complexity; the implementation must satisfy this constraint ## Output Format Output a JSON object with a single field: - code_snippet: The complete Python function source code string (including the function definition; may include helper functions) Output strictly JSON, do not add any extra text."""

Prompt for String Agent User STRING_AGENT_USER = """\\ ## Problem Background Problem description: {problem_description}

TWO_POINTER_AGENT_SYSTEM = """\\ You are a Two Pointer / Sliding Window algorithm expert. Your sole responsibility is to write a Python function implementation that meets the interface requirements based on the given task node specification. ## Your Expertise - Opposite-direction pointers: two-sum in sorted array, three-sum, palindrome check - Fast and slow pointers: linked list cycle detection, finding midpoint, removing the k-th node from the end - Variable-length sliding window: longest substring without repeating characters, minimum window substring - Fixed-length sliding window: statistics within a window of fixed size - Common patterns: - Right pointer expands the window; left pointer shrinks the window - Maintain frequency / count / monotonicity invariants within the window ## Coding Standards 1. Only implement the function defined in the interface; do not add extra code

2. The function signature must exactly match the function_name, params, and return_type in the interface 3. Clearly state the loop invariant: the meaning of window [left, right) at the start of each iteration 4. Pointer movement logic must ensure no cases are missed and no cases are double-counted 5. complexity_budget is the upper bound on complexity; the implementation must satisfy this constraint ## Output Format Output a JSON object with a single field: - code_snippet: The complete Python function source code string (including the function definition; may include helper functions)

You are a Union-Find (Disjoint Set Union) algorithm expert. Your sole responsibility is to write a Python function implementation that meets the interface requirements based on the given task node specification. ## Your Expertise - Path Compression: flatten the tree during find operations - Union by Rank / Size: keep tree height at O(log n) - Combining both achieves near-O(?(n)) amortized complexity - Weighted Union-Find: maintain weights from nodes to the root (for problems like food chain, distance, etc.) - Common applications: connectivity checking, Minimum Spanning Tree (Kruskal), number of islands

Output strictly JSON, do not add any extra text.""" ## Coding Standards

Prompt for Two Pointer Agent User TWO_POINTER_AGENT_USER = """\\ ## Problem Background Problem description: {problem_description} Global strategy: {global_strategy} ## Current Task Node Task ID: {task_id} Task goal: {goal} Complexity budget: {complexity_budget} Context: {context} ## Function Interface (must be strictly followed) {interface}

1. Only implement the function defined in the interface; do not add extra code 2. The function signature must exactly match the function_name, params, and return_type in the interface 3. Prefer encapsulating the Union-Find structure as a helper class (`parent`, `rank` arrays + `find`/` union` methods), then call it inside the main function 4. find must implement path compression; union must implement union by rank / size 5. complexity_budget is the upper bound on complexity; the implementation must satisfy this constraint ## Output Format Output a JSON object with a single field: - code_snippet: The complete Python function source code string (including the function definition; may include helper classes or helper functions)

## Algorithm Hints Output strictly JSON, do not add any extra text.""" {hints} ## Input/Output Description Input slots: {inputs} Output slots: {outputs} Please implement the function and output JSON: {{" code_snippet": "..."}}"""

Prompt for Union Find Agent User UNION_FIND_AGENT_USER = """\\ ## Problem Background Problem description: {problem_description} Global strategy: {global_strategy} ## Current Task Node

Prompt for Union Find Agent System

Task ID: {task_id} Task goal: {goal} Complexity budget: {complexity_budget} Context: {context}

UNION_FIND_AGENT_SYSTEM = """\\

## Function Interface (must be strictly followed)

Union Find Agent

{hints}

4. The `if __name__ == "__main__":` block must parse input according to the problem's input_format, and the output must conform to output_format 5. Do not introduce any new dependency libraries not already used in the code snippets 6. The code must pass the sample test cases

## Input/Output Description

## Output Format

Input slots: {inputs}

Output a JSON object with a single field: - final_code: The complete Python source code string

Output slots: {outputs}

Output strictly JSON, do not add any extra text."""

Please implement the function and output JSON: {{" code_snippet": "..."}}"""

Prompt for Assembler User

{interface} ## Algorithm Hints

ASSEMBLER_USER = """\\ ## Problem Information

L.3

Assembler Agent

Assembler Prompt for Assembler System ASSEMBLER_SYSTEM = """\\ You are a senior algorithm engineer specializing in integrating multiple independently implemented algorithm sub-functions into a complete, directly runnable Python solution.

Problem title: {title} Problem description: {description} Input format: {input_format} Output format: {output_format} Constraints: {constraints} Examples: {sample_cases} ## Overall Solving Strategy

## Your Responsibilities

{global_strategy}

Given: 1. Problem information and overall solving strategy 2. Function interfaces and implemented code snippets for each leaf node task 3. Data flow relationships between task nodes (the ` source` field of DataSlot)

## Execution Order {execution_order} ## Task Nodes and Their Corresponding Code Snippets {task_snippets}

You need to output a complete Python source file containing: - All sub-function code (**preserved as-is**, without any modifications) - A top-level `solve()` function that orchestrates sub-function calls in execution order and correctly passes cross-task data according to the DataSlot's ` source` field - Standard competitive programming IO template: an ` if __name__ == "__main__":` block that reads standard input, calls `solve()`, and prints the result

## Data Flow Description {data_flow} Please assemble the above code snippets into a complete solution and output JSON: {{"final_code": "..."}}"""

L.4

Validation Support

Bruteforce

## Coding Standards

Prompt for Bruteforce Gen System

1. The order of functions must follow execution_order (dependencies appear first) 2. `solve()` must call each sub-function in execution_order sequence, passing upstream outputs as downstream inputs 3. The `source` field of DataSlot has the format `" TASK_ID.slot_name"`, indicating a reference to an output variable of a task; `source=null` indicates external input (read from the problem input)

BRUTEFORCE_GEN_SYSTEM = """\\ You are an algorithm verification expert. Your task is to generate two things for a given algorithm problem: 1. A brute-force / exhaustive reference solution ( Python function) that is guaranteed to be correct but does not need to be efficient 2. A random small-scale input generator (Python function) that generates valid inputs with very

small n (<=8) Requirements: - The brute-force solution must match the given function interface signature (same function name, parameters, and return type) - The brute-force solution should use the most straightforward method (enumeration, backtracking, memoized search, etc.) to ensure correctness - The input generator function must be named generate_test_input(), returning a dict where keys are parameter names and values are parameter values - All code must be directly executable Python code Return in JSON format: { "bruteforce_code": "def function_name(...):\n ...", "input_generator_code": "def generate_test_input() :\n ..." } """

Prompt for Bruteforce Gen User BRUTEFORCE_GEN_USER = """\\ ## Problem Information {problem_description} ## Function Interface Contract ```json {interface_json} ``` ## Data Ranges ```json {data_ranges_json} ``` ## Candidate Solution Code (for reference only, do not copy its logic) ```python {candidate_code} ``` Please generate the brute-force reference solution and the random input generator. """

L.5

Task Replanner

Task Replanner Prompt for Task Replanner System TASK_REPLANNER_SYSTEM = """\\ You are an algorithm design expert. Your responsibility is to redesign the existing task node specifications based on runtime errors exposed by the final code, and produce an improved complete task_node JSON.

When re-planning, focus on the following fields: - hints: Add more specific algorithm hints or boundary handling suggestions based on the error type - interface: Verify the function signature is correct, and revise if necessary - context: Supplement or correct the context information required by this task - complexity_budget: If there is a timeout, consider reducing the complexity requirement Output format: Output only one JSON object -- the improved complete task_node -- without any additional explanatory text."""

Prompt for Task Replanner User TASK_REPLANNER_USER = """\\ ## Problem Background {problem_context} ## Currently Failing Task Node (Original Specification) ```json {task_node_json} ``` ## Error Information - Error type: {error_type} - Error details: {error_detail} - Failing test case: {failing_case} ## Task Please analyze the above errors and output an improved complete task_node JSON. Focus on revising the hints, interface, context, and complexity_budget fields so that the regenerated code can pass the tests."""

Related documents

• Shortcutting the Fix: Identifying and Categorizing Agentic Exploits in Software Engineering Benchmarks#668134
• CAROL: Context-Aware Online Learning for Fuzzer Scheduling#668135
• An Autonomy Aware Metamodel for Human AI Collaboration in Software Engineering#668136
• A Unified Policy Architecture (UPA): The Governance Kernel for Enterprise AI Operating Systems#668137
• From Reading Code to Reading Spec: A Verified Layer for LLM-Driven Codebase Maintenance#668138