Call-Level Revision Contracts for LLM-Authored Workflows

Call-Level Revision Contracts for LLM-Authored Workflows Chenyang Jiang1 , Benyang Pan, and Puqu Wu

arXiv:2611.06967v1 [cs.SE] 4 Nov 2026

1

South China Normal University, Guangzhou, China

not compare payloads, so it returns the recorded result and the run succeeds with the replaced artifact. Neither gap is closed by a durable execution engine, which replays a recorded history, checkpoints after each workflow task, and requires the replayed code to issue the same commands in the same order. The guarantee is stated for the program that produced the history. A repair that moves a call into a helper still replays, because the command sequence is unchanged. A repair that edits a committed payload is served from the history, because the payload is not part of the key. Prior work formalizes resume for a fixed program [1], semantic step identity [2], runtime revision scope [3], and replay capsules under an unchanged source [4]. What a rewritten script may still touch is left open. After a failure, the committed calls cannot change and the rest of the script can. The two sets are not separated by a line number, and under parallel calls arrive in an unstable order. In a loop, one source location executes many times, and formatting moves lines. Each capability call therefore carries a structural identity ι = (σ, π, ω), made of the callsite σ (enclosing function, block path, and call ordinal), the fanout path π, and the occurrence counter ω. None of the three depends on the payload or on arrival order, so a reordering cannot disguise a replay as a new call, or a new call as a replay. The contract has three checks over a frozen prefix, and a bounded repair loop that uses them. Committed identities are durable, and a callsite with a committed occurrence is frozen. Before a container starts, a static gate rejects a candidate that removes a frozen callsite, changes its capability, or changes its call expression. At dispatch, a payload digest stops a call that reaches a committed identity with a different payload, so the run neither pays again nor returns a stale artifact. An occurrence ledger names a call at a new identity whose payload was already paid for at the same site and path. The repair loop returns structured counterexamples to the model, and a call-count check rejects a candidate that drops calls. Under the three assumptions of Section III, a candidate that the gate accepts never executes a committed identity. The contract freezes the call expression and leaves the statements around it writable. A loop may grow, a bound may change, and prompt assembly may be rewritten. Moving a committed call into a helper is the harder case. The move preserves the capability, the payload, and the order, but the moved call has a new callsite, so under structural identity it is new work and would be paid for. The gate stops the candidate before any provider call. Section II walks through a real repair

Abstract—Durable execution engines replay a recorded history and do not compare activity payloads. When a model repairs a workflow that failed partway through, it must either pay again for calls that succeeded or accept a recorded result whose payload changed. We define a revision contract for workflows whose orchestration code is written by a model. Each capability call carries a structural identity built from its callsite, its fanout position, and its occurrence count, and the identity stays stable under rewrites that leave the call in place, so committed identities form a frozen prefix. The frozen unit is the call expression, and the surrounding code stays writable. A static gate rejects a rewrite that would change a committed call before a container starts. A runtime digest stops a changed payload at a committed identity, and an occurrence ledger names a repeated paid payload. Under three assumptions, a candidate the gate accepts replays every committed call it invokes, executes only new work, and reports the identities it skips. No local identity is both relocationinvariant and free of wrong reuse, so callsite identity turns a relocation into a pre-spend stop. On media workflows, 22 gate-passed repairs replay 258 committed identities with no duplicate, and a live six-way fanout makes seven paid calls instead of twelve. A 12-task customersupport study applies the same identity, replay, and boundary checks on two models. Index Terms—Durable execution, workflow repair, LLM-authored workflows, revision contract, idempotency, replay, call identity.

I. I NTRODUCTION A repaired workflow may add work, but it must not pay twice for work that already ran, and it must not return a result that the repair has replaced. We make both properties an explicit contract for workflows whose orchestration code is written by a model. Tasks that used to be a single model call are now small programs. A request for a thirty-second brand video with six shots becomes a plan for a storyboard and one image call per shot. Each image is reviewed, the failures are regenerated, and the result is composed. Our platform lets the model write the orchestration script itself, in a restricted Python subset with capability primitives such as ctx.run("image.generate", payload) and a broker that authorizes every call. The script may loop, fan out, retry, and branch on data that earlier calls produced, which a fixed DAG cannot express. That flexibility has two failure modes, and both cost money. In the first, three shots are generated and paid for and the fourth call fails. The natural repair is to show the model the error and let it rewrite, and the rewritten script calls the provider for the first three shots again. The second mode is the reverse and is worse for the product. The model decides that a committed payload was wrong, for example a prompt, a size, or a seed, and edits it in place. A replay engine does 1

# committed: image.generate inside gen() async def orchestrate(ctx, args): async def gen(s): return await ctx.run("image.generate", {"prompt": s}) return await ctx.parallel( [gen(s) for s in args["scout_shots"][:4]])

of this shape. Proposition 4 shows that no local identity can be both relocation-invariant and free of wrong reuse, so the choice is forced. We evaluate the contract on media workflows and on a customer-support corpus, with a live image provider, two durable engines, and two model families. On eight real failures the model repairs every script within two rewrites, and the gate stops the one repair that would have paid for a committed call again. The spend advantage is strict when a failure falls inside a fanout, where a full rerun or an engine reset repeats the committed branches, and it disappears on a sequential tail repair, which Section VI reports. Section II describes durable execution, the platform, and the repair that motivates the contract. Section III gives the model and the safety result, Section IV the mechanisms and their boundary, and Section V the implementation. Section VI reports the evaluation, Section VII what it covers, and Section VIII positions the work.

# repair: the call is moved into gen_one() async def gen_one(ctx, s): return await ctx.run("image.generate", {"prompt": s}) async def orchestrate(ctx, args): return await ctx.parallel( [gen_one(ctx, s) for s in args["scout_shots"][:4]]) # gate: removed committed site orchestrate/#1 # spend: 0 provider calls; the repair never starts

Fig. 1. The a425 repair. Moving a committed call into a helper preserves the capability multiset and the call order, so a checker-only repair accepts it. The frozen callsite disappears, and the gate stops the candidate before spending.

C. A repair that must be stopped Figure 1 shows a script that the model wrote for a four-shot scout run, and the repair it produced after the fourth image call failed at the provider. The repair factors the image call into a helper named gen_one and calls the helper from the same place. This is an ordinary refactor, because the capability multiset is unchanged, the call order is unchanged, and every checker rule passes. Under a command-sequence identity the repair replays, because the commands are the same. Under the structural identity of Section III the committed callsite orchestrate/#1 no longer exists, so the moved call is new work and would be dispatched and paid for. The gate reports removed and stops the candidate before the container starts. The stop is a design decision, and Section IV states why no local identity avoids it.

II. BACKGROUND AND M OTIVATING E XAMPLE A. Durable execution and replay A durable execution engine records every external call in a history while the workflow runs. On recovery it re-executes the workflow function from the beginning, serves completed calls from the history, and requires the replayed code to issue the same commands in the same order. Checkpoints are taken per workflow task, so the unit the engine protects is the program that produced the history. Temporal, DBOS, and Restate choose different checkpoint units and different recovery paths [5], [6], [7]. In all three, a recorded call is matched by its position in the command sequence, not by the source expression that produced it. A version marker can declare a code change compatible, and that declaration is the part an engine cannot check.

D. What the contract has to decide Figure 2 shows the boundary the design has to draw. The original run commits three calls and fails at the fourth. A repair may replay the three committed calls and append work after them, but it may not edit the committed calls in place. The figure also shows the case that separates safety from fidelity. A control-flow edit can leave a committed callsite in the source and make it unreachable, which the static gate accepts and the orphan report records. Three requirements follow. A candidate that the gate accepts must not execute a committed identity, because a second execution is a second payment. A committed identity that the candidate reaches must replay or stop the run, because a changed payload cannot be served from the record. The decision must be made before the container starts, since a check that runs at dispatch can only detect the payment after it happened. The rest of the paper asks which identity makes the first requirement checkable on the source, which mechanisms enforce it at run time, and what no identity can achieve. Three assumptions support the results. Every external effect goes through run(c,p). Committed records are durable and only grow. The identity is structural and does not depend on the payload, the arrival order, or the line number. Section III

B. The platform A job arrives with a request and an envelope that fixes the granted capabilities, the token budget, and the concurrency limit. The host gives the model a skill document and a capability catalog, and the model returns a Python script whose entry point is orchestrate(ctx, args). The only route to an external effect is ctx.run(name, payload). The context also exposes parallel, pipeline, dag, and race for fanout and ordering. A checker rejects imports, dunder access, unbounded loops, and unguarded fanout before the script runs, and a broker outside the container authorizes each capability call against the grant set. The script executes in a networkless container with a read-only root filesystem and no provider credentials. The run store keeps one record per committed call. Four capabilities are production-bound in this build. image.generate is a paid image call. storyboard.plan, review.visual, and text.generate are read-only model calls. video.generate is catalog-only and appears in authoring studies, where no provider is billed. 2

A site may execute several times in a loop, and ω ∈ N0 is the zero-based occurrence counter for the pair (σ, π). The call identity is ι = (σ, π, ω) ∈ I, (3)

frozen prefix, source edits stopped run #1 commit

run #2 commit

run #3 commit

run #4 fail

and a record is id

r = (ι, c, h, v, u),

replay

replay

replay

where h = H(canonical(p)) is the payload digest, v is the result reference, and u records usage and cost. A run produces a trace T = ⟨r1 , . . . , rn ⟩. The committed prefix P is the persisted partial map from ι to r. commit is idempotent on ι, and P only grows. A frozen site constrains the call expression rather than the block. A loop that committed ω = 0, . . . , k − 1 may execute ω = k, because that identity is new. The expression run(c, p) that produced the committed payloads may not change, while the statements around it stay writable. A line-number heuristic and a block-level freeze give different writable sets (Figure 2).

new tail run #5 writable tail

Fig. 2. The revision boundary. The original run commits identities 1–3 and fails at 4. A repair replays 1–3 (same structural identities), may append a new call at a new identity, and may not edit the frozen prefix. The static gate stops such edits before a container starts. A control-flow edit that leaves 1–3 in the source but unreachable passes the gate and is reported as an orphan, which is why fidelity is separate from safety.

states each assumption formally and gives the case that fails when it does not hold.

B. Runtime rule For a call (ι, c, p), the runtime applies the following rule. 1) If P (ι) = r and r.c = c and r.h = H(p), return r.v. This is a replay hit, not a provider execution. 2) If P (ι) = r but r.c ̸= c or r.h ̸= H(p), raise Divergence(ι). Continuing would place a new effect on top of an already committed one at the same identity. 3) If ι ∈ / P , execute (c, p), commit (ι, c, H(p), v), and return v. The third branch is the one that spends money. The second raises a safety event, and the first serves the past without reexecuting it.

III. M ODEL AND P ROBLEM S TATEMENT Identity-level replay safety rests on three assumptions, and exactly one of them constrains how the source may be revised. This section defines the execution model and the structural identity of a capability call. It then states the safety theorem, which covers the committed calls that a candidate keeps, and a separate fidelity condition that covers the calls it skips. a) Terminology: A callsite σ is a normalized AST position. An identity ι adds the fanout path and the occurrence counter. A record is what a committed identity stores, and the store key is a slot. The committed prefix P is the set of identities with records, and a callsite with a record is frozen. A divergence is a call at a committed identity with a different payload, and it stops the run. An orphan is a frozen identity that the candidate does not invoke, and it is recorded without failing the run.

C. The repair problem A repair replaces the failed script S with a candidate S ′ for the next attempt. The contract makes three requirements. Every identity in P that S ′ invokes is served from P or raises Divergence. Identities outside P may execute, so a repair can add work after the failure. Every identity in P that S ′ skips is reported as an orphan. The gate (Section IV-B) decides the structural part before a container starts, the runtime rule enforces the rest at dispatch, and the orphan report names what the candidate skipped.

A. Scripts, callsites, and records A workflow script is an asynchronous function S : X → Y, written in a restricted Python subset. Every external side effect is mediated by run(c, p), where c is a capability name and p is a payload. The checker rejects imports, dunder access, and other ways around this surface, and Section V maps the rules to the code. A structural callsite is σ = (f, b1 , . . . , bk , j) ∈ Σ,

D. Assumptions Assumption 1 (Mediation). Every external side effect goes through run(c, p). The script reaches external effects only through the runtime, so imports, file I/O, network access, clocks, and randomness are outside the surface. The checker rejects the source-level routes (Section V), and the sandbox removes the rest. A rule that the checker misses therefore stays inside the runtime boundary, because the container has no network, a read-only root filesystem, and no provider credentials.

(1)

where f is the enclosing function, each bi is the kind and ordinal of a statement block, and j is the ordinal of the run call within the innermost block. The identity is computed on a normalized AST, so comments, formatting, and line breaks do not change σ. A container primitive parallel, pipeline, dag, or race pushes a branch index when it enters a branch. The resulting fanout path is π = (i1 , . . . , id ) ∈ Π,

(4)

Assumption 2 (Durable monotone prefix). P is keyed by ι, commit is idempotent on ι, and committed records survive failures, container restarts, and source rewrites. Silent deletion or

π = () for sequential code. (2) 3

Theorem 1 (Identity-level once). Under Assumptions 1–3, let S ′ be a candidate that the gate accepts. Then no identity in P reaches the execute branch. Every committed identity that S ′ invokes is served from P , or raises Divergence if its payload changed. Every committed identity that S ′ does not invoke is reported as an orphan.

overwrite is outside the trust model. The assumption requires a store that answers, and Section IV-I states the fail-closed policy for an outage. Assumption 3 (Structural identity). The identity ι = (σ, π, ω) is determined by the normalized AST position, the fanout path, and the occurrence counter. It does not depend on payload, arrival order, wall-clock time, or line number. Formatting, comments, payload values, and appends after committed sites do not change a committed σ. Different call instances in one trace receive different ι. An insertion or deletion of a capability call before a committed site shifts σ. The gate compares the frozen sites against the candidate, and Section IV-F states how the resulting identities are treated.

Proof. Gate acceptance gives presence, capability, and callexpression fingerprint for every frozen site (Section IV-B). Assumption 2 keeps the records readable, and Assumption 3 with Lemma 1 gives the same identity at dispatch. The runtime rule sends an invoked ι ∈ P to the replay branch when its digest matches, and to Divergence when it does not. The execute branch requires ι ∈ / P . The host compares the frozen identities with those invoked and reports the difference as Orphan.

Assumption 3 does not require two semantically identical calls to share an identity. A new site with the same provider request is a new identity. The semantic-duplication boundary of Section IV-F covers that case, and Theorem 1 covers the identities that a gate-accepted candidate invokes.

Theorem 1 states the system-level guarantee, which is identity-level once with an explicit fidelity signal. The proof separates four obligations. Identity stability (Lemma 1) is the source-level one. The gate establishes the structural part before spending. The digest checks payload changes at dispatch. The orphan report names the committed identities that a candidate skips.

E. Identity stability The proof rests on one source-level property. Lemma 1 (Identity stability under tail revision). Let S be a script and σ a callsite in S. For any candidate S ′ obtained from S by (i) changing comments, formatting, or blank lines, (ii) changing the value of a payload while preserving the call’s AST shape, (iii) inserting a statement that contains no capability call before a committed site, or (iv) appending statements after the last committed callsite, every committed runtime identity (σ, π, ω) has the same value in S ′ as in S.

Remark 1 (Orphans are the fidelity signal). Gate acceptance preserves the committed callsites, and reachability is the candidate’s choice. The orphan report names every committed identity that a candidate skips, and DYNAMIC_ORPHAN_POLICY=stop turns that report into a failed run. The default warn records the orphan and lets the run complete, because an orphan is a fidelity event rather than a second dispatch. A deployment that bills per artifact chooses stop, and the default keeps the run auditable.

Proof. By induction over the block traversal computed by assign_sites. Comments and formatting are not AST nodes. A payload value change leaves the call position untouched. A non-capability statement does not increment the call ordinal, and an append adds statements after the site.

G. Replay fidelity Proposition 1 (Replay fidelity). If (a) each committed site’s capability and call expression are unchanged, (b) prefix control flow is deterministic under the same inputs and environment, (c) no insertion or deletion before a committed site shifts its structural identity, and (d) the candidate’s control flow on the committed prefix is trace-equivalent to the committed run (same branch decisions, loop counts, and fanout widths), then replay serves every identity in P exactly once, executes only identities outside P , and produces no orphan.

Two edits fall outside the lemma. Inserting a block around a committed site adds a label to every nested call, so the old identifier is no longer produced and the frozen-site comparison reports removed. Inserting a fanout branch or a loop iteration before a committed identity changes π or ω. The static gate cannot see either shift, and Section IV-F states which runtime check catches it. Lemma 1 constrains σ, and the call-expression fingerprint is a separate check. A literal payload edit preserves σ but changes the fingerprint, so the static gate stops it. A datadependent payload edit preserves both and is caught by the runtime digest at dispatch. The gate catches source-level drift, and the digest catches value-level drift.

Proof sketch. Induct over control steps. By (d), the candidate follows the committed trace on the prefix, so every frozen site is reached in the same order and with the same loop and fanout structure. By (c), the sequence of (σ, π, ω) triples is the same as at commit time. By (a), each capability and payload digest matches its record, so every ι ∈ P takes the replay-hit branch. By (b), a second replay of the same candidate makes the same decisions. After the prefix is replayed, remaining identities are outside P and enter the execute branch.

F. Identity-level safety The runtime rule is a dispatch invariant that holds for every candidate, including one that renames every site and thereby avoids P . The theorem lifts it to the system. The gate provides the structural premise before spending, and the orphan report provides the fidelity signal.

The five script-level conditions of the checker approximate (a) and (b) syntactically. They are ordered iteration over sets, statically bounded loops, no hidden inputs, deterministic fanout width, and capability names within the grant envelope. 4

Proof. Let σ = (f, b1 , . . . , bk , j) be a committed callsite. Move the call into a new helper g invoked from the same point. The new site is σ ′ = (g, b′1 , . . . , b′k′ , j ′ ). The capability and the call expression are unchanged, and the call is performed once, in the same order. The runtime rule keys on ι = (σ, π, ω), and σ ′ is not in P , so the call would execute. The gate stops the candidate before spending and prevents the duplicate. A command-sequence engine accepts the edit because its identity is the command position, and the two identities disagree.

Condition (d) is a runtime property, and the orphan report names the identities that a candidate skips (Remark 1). IV. T HE R EVISION C ONTRACT A. Overview The host-side path appears in Figure 3. The model writes an orchestration script, and the repair driver validates every candidate against the checker and the committed prefix. An accepted candidate is annotated with callsite identities and handed to the sandbox, and capability calls return to the host through a bounded file RPC, pass through the broker, and are committed to the run store. The container has no network and never holds a provider credential. Three mechanisms catch the three ways in which a rewrite can repeat a paid effect. A static gate protects the source-level call expression, and a runtime digest protects the payload at a committed identity. An occurrence ledger names a repeat that the first two cannot see.

The relocation case is the one repair among the four replay points of Section VI that the gate stops. A command-sequence engine accepts the edit and replays the recorded result, and Section VI-B0d measures the difference. Proposition 4 shows that the stop does not depend on the implementation. C. The runtime payload digest The gate reads the source, so it sees a literal payload edit and stops it. A payload that depends on earlier results, such as a size read from the storyboard, preserves both the callsite and the shape of the call expression. At dispatch the runtime hashes the canonical payload and compares it with the record. A match replays r.v, and a mismatch raises Divergence before any new effect is recorded, so the run stops instead of paying again or returning the replaced artifact. The digest is the only check that sees a value computed at run time.

B. The frozen prefix and the static gate Let F be the set of frozen sites. The gate accepts a candidate S ′ only if every σ ∈ F is present, keeps its capability name, and keeps its call-expression fingerprint. A stopped candidate never reaches the container, so it spends nothing. Acceptance covers presence, capability, and the call expression. Reachability and the payload digest are separate checks, because neither can be decided from the source. The host derives the frozen prefix from the committed slot records and builds a hash chain over entries ordered by (site, path, occurrence). The certificate carries the frozen-site map, the chain digest, and the entry count. Verification recomputes both from the current store and reports any difference, so the certificate is a consistency manifest against the store. The gate is an over-approximation of the preservation premise, and it is stricter than the premise requires. Proposition 2 states the guarantee, and Proposition 3 states the cost.

D. The occurrence ledger The gate is static, and π and ω are run-time quantities (Section IV-F). The broker therefore keeps an occurrence ledger built from the same slot records. For each (σ, π) it indexes the committed payload digests. Before a call that misses on identity is dispatched, the ledger asks whether the same site and path already paid for this exact payload, and a hit is a semantic repeat. Policies are off, warn, deny, and the default auto, which resolves per capability. The default denies a repeat for a side-effecting capability and warns for a read-only one, so a repeated paid image call needs an explicit decision while a repeated review is only budget. An operator who needs a permissive policy can set warn globally, and a repair that legitimately produces a second take declares it. The ledger does not stop a call on its own. It names the repeat and leaves the choice to policy, which makes the occurrence-extension case visible, and optionally fatal, before money is spent.

Proposition 2 (Gate soundness). If the gate accepts S ′ , every committed callsite is present in S ′ with the same capability and the same call-expression fingerprint, and the structural premise of Theorem 1 holds. For every identity the candidate invokes, the runtime rule gives identity-level once, and every identity it skips appears in the orphan report. Proof. The gate checks presence, capability, and callexpression fingerprint (Section IV-B), which are the structural conjuncts of the preservation premise. Reachability is checked at run time by the orphan report. When the identity is invoked, the runtime rule applies Theorem 1.

E. The boundary of local identity The guarantee is keyed to the identity, and a pre-spend check can see the local syntactic context of a call, which is the capability, the payload, the call expression, the fanout path, and the occurrence, without the model’s cooperation. Proposition 4 states the limit of that information.

Proposition 3 (Pre-spend strictness). There is a candidate S ′ that preserves every committed call’s capability, payload, and order, and the gate reports it as removed and stops it before it starts. Relocating a committed call from its enclosing function into a helper is such an edit. Under structural identity the stop is necessary, because the moved call has a new σ and the runtime would execute it and pay again.

Proposition 4 (Identity boundary). No local identity is both relocation-invariant and free of wrong reuse on the candidates that keep a committed call’s capability, payload, and order. Relocation invariance means that moving the call into a new 5

accept

Model / rewriter

Repair driver

Static checker

Prefix gate

untrusted

bounded retries

R00–R12

freeze + fingerprint

Sandbox controller

Docker container

image + limits

script, no network

stop before spend load prefix

RPC

Run store

Capability broker

slots

slots, attempts, cert

grants + idempotency

Providers calls + results

Fig. 3. Host-side architecture. The model and the providers are external. The script executes in a networkless, read-only container. The host annotates callsites and owns the prefix, the broker, and the store.

function or block preserves the identity, and freedom from wrong reuse means that no call receives a result committed at a different callsite.

TABLE I W HAT EACH IDENTITY PROVIDES . Pre-spend MEANS THE HOST CAN COMPUTE THE IDENTITY BEFORE A CONTAINER STARTS WITHOUT AN AUTHORED MARKER . T HE LAST COLUMN IS THE MEASURED OR CONSTRUCTED OUTCOME . C ALLSITE IDENTITY IS THE ONLY ROW THAT IS BOTH HOST- DERIVED AND FREE OF WRONG REUSE , AND ITS COST IS THE RELOCATION STOP.

Proof. Suppose ι is local and relocation-invariant. A move into a helper preserves the capability, the payload, the call expression, the fanout path, and the occurrence, so ι is unchanged. Two callsites can share a local context, and the same call in two branches is the common case. They then share ι, so a record committed at the first is a replay hit at the second, which is wrong reuse. If two callsites with the same local context receive different identities, the difference is positional and depends on the enclosing function or the block path. A move changes that position, so ι changes, and the gate stops the relocation or the runtime executes the call again. A local identity has no third option.

Identity

Reloc. Misbind. Pre-spend

payload (cap, H(p)) arrival ordinal source line global ordinal ancestry tag semantic role callsite (σ, π, ω)

yes no no yes yes yes no

no yes yes no yes yes yes

yes yes yes no no no yes

Outcome wrong reuse duplicate stops duplicate authored declared pre-spend stop

TABLE II W HERE EACH SHIFT IS CAUGHT. T HE STATIC GATE COMPARES SITES , CAPABILITIES , AND CALL EXPRESSIONS , WHILE π AND ω ARE RUNTIME QUANTITIES .

Table I lists the alternatives. Three identities lie outside the local class, and each makes a different trade. A global call ordinal survives relocation in sequential code, but an insertion before a committed call shifts every later ordinal and turns replay into a duplicate. An ancestry tag survives relocation, but the tag must be authored, and a call that moves into a new frame changes its parent. A semantic role survives relocation, but the role is a declaration outside the runtime’s verification, with the same status as a version marker. We choose the local, host-derived identity because a pre-spend check can compute it without the model’s cooperation, and we state its cost. E7 measures the alternative, in which payload identity accepts every relocation and returns a result committed at another callsite twice in four repairs (Table VI). Identity and payload vary independently, which gives four cases. A call at a committed identity with the same payload replays and pays nothing. A call at a committed identity with a different payload raises Divergence. A call at a new identity with a payload already paid for at the same site and path is a semantic repeat, which the ledger names. A call at a new identity with a new payload is new work. The gate guarantees the first case before a container starts, the digest enforces the second at dispatch, and the ledger covers the third.

Shift

Gate

Digest

Ledger

Consequence

ω grows, same payload ω grows, new payload π shifts, other payload π shifts, same payload duplicate insertion new callsite

accepts

passes

blocks

the ledger names the repeat

accepts

passes

–

new work (intended)

accepts

Divergence –

stop, no duplicate

accepts

hit

–

interchangeable

accepts

hit

–

–

–

–

inserted call replays, original is new duplicate (residual case)

Table II lists them and names the mechanism that catches each one. a) Relocation: A fourth shift changes the identity without changing the command sequence, because it moves a committed call into a helper. The gate stops it (Proposition 3), and Section VI-B0d measures the difference against a durable engine’s reset, which completes the same repair. b) Occurrence extension: A script that retries with a fixed payload, for example a loop over range(3) whose body calls image.generate with a constant prompt, commits ω = 0, 1, 2. Widening the bound to 6 does not touch

F. Shifts that produce a new identity The identity has three components, so a repair has three ways to produce a call that is new but semantically old. 6

σ, the capability, or the call expression, so the gate accepts. Occurrences 3, 4, and 5 are fresh identities, so the runtime rule executes them. The ledger names the repeat before the call is paid. c) Path shift: Inserting a fanout branch ahead of a committed one moves every later branch by one path index. The gate still accepts, and the branch that now reaches a committed path carries a different payload, so the runtime digest raises Divergence and the run stops. No call is duplicated, but the counterexample is a digest mismatch rather than a structural explanation. When the shifted payload is identical the two branches are interchangeable, and the run reproduces the committed artifact. Without the ledger, widening the bound spends three more calls, and under deny it spends nothing, while a path shift stops after one call in either case. Together the three mechanisms give identity-level once. The ledger covers the semantic repeat for a stable payload, and a prompt that embeds a timestamp or a random seed lies outside its scope by construction.

a) Normal run: The driver parses the script and runs the checker. On acceptance the host injects a _site keyword into each capability call, starts the sandbox, and passes the annotated source. The host annotator owns _site and accepts an existing value only when it equals the computed callsite. The container reports (site,path,occurrence) with every RPC, and each frame carries a per-run random nonce that only the wrapper knows, which binds the call to the host’s annotation. The broker computes a payload digest and a slot key, executes the handler on a miss, commits the result and the slot, and returns. b) Repair after failure: The driver loads the prefix and asks the model for a candidate, including the frozen sites and the structured failure. The candidate is checked and then gated. A frozen edit raises a counterexample, and the driver retries without starting a container. If the candidate passes, replay serves committed identities from the store and executes only new identities. The host compares the frozen identities with those invoked, and a non-empty difference is an orphan, recorded without stopping the run.

G. Crash handling Let k be the number of calls in flight when the process crashes, which is the in-flight concurrency measured per crash.

I. Trust boundary and failure policy Storage errors are fail-closed by default, so a failed slot listing or idempotency read raises and an outage surfaces as a visible failure. The safety claim assumes a store that answers (Assumption 2), and the default is the safety choice. Explicit opt-outs (DYNAMIC_*_FAIL_CLOSED=0) make the permissive policy an operator decision. The host trusts the image digest, the broker, and the store. The container’s authority is the host’s annotation table. The host supplies _site, and each RPC is bound to that annotation by a per-run nonce. The image has no network and a read-only root, and provider credentials stay in the host. The gate and the runtime check are the enforcement points, and neither depends on the model’s cooperation.

Proposition 5 (Policy-dependent crash window). Assume the attempt record is persisted before dispatch. 1) Under fail-closed, an unresolved side-effecting attempt raises AttemptUnresolved. The k identities produce no silent duplicate until reconciliation, and the run waits for the operator’s decision. 2) Under explicit abandon-and-retry, an operator may declare an attempt abandoned and allow execution. If the provider completed and only the commit was lost, this can repeat up to k effects per crash, and the decision is operator-visible and auditable. 3) Under fail-open, a failed attempt write permits dispatch, and the bound becomes the operator’s responsibility. 4) A provider-side idempotency key or two-phase commit closes the window at the provider, and the contract composes with it.

V. I MPLEMENTATION The prototype runs the contract inside a networkless Docker sandbox that never sees a provider credential. A host service accepts a model-authored script as a job, validates it, runs it in the container, and routes capability calls back to the host. The repository contains the checker, the site annotator, the prefix gate, the broker, the run store, the repair loop, the sandbox controller, and the certificate and orphan endpoints. The implementation is Python 3.11, and the run store is SQLite in WAL mode. a) Checker: The checker is an AST pass over the script with thirteen rules, R00 to R12. It returns violations and facts, and valid is determined by the error-severity violations. The checker never executes the source, and the repair loop runs the script rules and skips the envelope rules, so authorization stays in the host’s grant set. b) Structural sites: assign_sites assigns each capability call a site from the enclosing function, the block path, and the call ordinal. The identifier does not depend on line numbers, comments, formatting, or payload values. R10 reserves _site for the host, and the checker enforces it.

The default policy is detect-and-fail-closed. An unresolved side-effecting call is detectable, and it is not replayed by default. Bounded duplication, at most k per crash, arises only after an explicit abandonment. A provider idempotency key composes with the contract and closes the window at the provider, while the contract supplies identity-level once, detection, and a bounded window. The broker writes an attempt record before dispatch, so a crash leaves the attempt without a committed result, and on replay a side-effecting capability raises AttemptUnresolved. The operator either writes back a known result or declares the attempt abandoned. Abandonment permits a retry and can repeat an effect that the provider had already completed, so the decision is recorded and auditable. H. Protocol walks Figure 4(a) walks a normal run and a tail repair, and part (b) shows the crash window. 7

Crash window Driver checker/gate

Model

Sandbox

Broker/store

candidate S

attempt check + start S

write run 1–3

dispatched

commit

crash

fail at 4 retry ≤ k

result

failure + prefix candidate S ′

committed

unresolved replay fail closed default

check and gate, start S ′ abandoned

frozen edit, stop before start replay 1–3, run 5

abandon may repeat at most k effects

commit 5 + certificate

Fig. 4. Protocol walks. (a) A normal run, a tail repair, and the gate’s pre-spend stop. (b) The crash window. The attempt record is written before dispatch, and an unresolved attempt fails closed unless an operator abandons it, which can repeat at most k effects.

backs up the gate’s call-expression check. A known handler exception is recorded as failed and may be retried, while a crash leaves attempt for the crash policy.

annotate injects _site without changing line numbers and accepts an existing value only when it equals the computed callsite. The host keeps a site-to-fingerprint whitelist and admits an RPC only when its site is in the whitelist. Each frame carries a per-run nonce, which binds the call to the host’s annotation. c) Prefix gate and certificate: The loader Prefix.from_store reads slot records, deduplicates by (site, path, occurrence), and raises PrefixConflictError on conflicting duplicates. The loader supports permissive reads, and the gate calls it with strict=True, the default, so enforcement fails closed on a failed listing. The gate emits removed or capability_changed, and a changed call expression emits call_changed. A failure raises before the container is created. The certificate is a hash chain over entries sorted by (site, path, occurrence). persist_certificate writes it, and certificate_for_run recomputes differences. d) Broker and idempotency: The broker registers the capabilities in the run’s grant set. Four of the nine catalog capabilities are production-bound, namely storyboard.plan, image.generate, review.visual, and text.generate. The other five serve dry-run authoring. Each handler is wrapped by _idempotent. The wrapper computes a canonical payload digest, a slot key from (site, path, occurrence), and a result key that also includes the payload digest. On a slot hit it compares the capability and the digest, and a mismatch raises ReplayDivergenceError. On a result hit it returns the stored result without calling the provider. On a miss it writes an attempt record, calls the handler, and commits the result and the slot. A source_digest check

e) Sandbox: SandboxRunner launches the fixed runtime image with no network, a read-only root filesystem, a non-root UID, dropped capabilities, no-new-privileges, a seccomp profile, cgroup limits on CPU, memory, and processes, and tmpfs workspaces. The source, inputs, and output are size-capped, and capability calls use a bounded file RPC rather than a network socket. The controller validates the image digest, the resource controller, and the isolation profile before execution. An acceptance script covers sixteen checks, including network isolation, read-only filesystem, non-root execution, seccomp, RPC authorization, output limits, timeout, artifact export, budget downgrade, concurrency, and capability audit. f) Repair loop: repair_dynamic_source performs at most max_attempts rewrites. It validates the candidate with the checker and the prefix, and it additionally requires that the number of capability calls does not decrease, which catches a truncated function that still parses. The prompt contains the frozen sites, their source lines, the original committed script, the last failure, and the structured counterexamples. The loop returns the candidate and the per-attempt feedback, and execution is a separate caller decision. g) Audit surfaces: The host records prefix verification, sandbox start and exit, capability start, denial, and completion, orphan reports, and certificates. The certificate and orphan endpoints expose the recomputed summary and the frozen-butnot-invoked identities. The certificate is a digest manifest that verification recomputes from the store. Provider credentials and the token budget remain in the host process. 8

h) Reproducibility: The checker, the annotator, the prefix gate, the broker, the run store, the repair loop, the E1 to E4 scripts, and the P1-C and P2 mutation harnesses are in the authors’ repository. E1 uses a stored task set and stored model outputs, P1-C uses stored outputs, and P2 uses stored mutants. The E2b, E4, and P2b commands run without Docker, network, provider credentials, or an API key. A reproducibility artifact accompanies the submission and carries the pre-registration specifications, the frozen task sets, the exact commands, the raw scores, and an offline smoke script. The E1 task set is frozen at 60 tasks, and the artifact records its definition, the pinned container image, the P1-C task and manifest identifiers, the P2 and P2b base identifiers, and the per-bucket cost records. Model IDs are the provider-served IDs on the run date.

TABLE III E2 B , INJECTED TAIL FAILURES ON REAL MODEL REPAIRS . C MT.= COMMITTED IDENTITIES , R EP.= REPLAYED , N EW = NEWLY EXECUTED . T OT. AND NAIVE COUNT SUCCESSFUL EXECUTIONS OVER THE FAILED RUN PLUS THE REPAIR . T HE INJECTED FAILURE IS A PAID ATTEMPT BUT NOT A SUCCESS . NAIVE EXECUTES THE REPAIR WITHOUT THE GATE . C MT. SUMS TO 11, WITH EIGHT IN THE THREE ADMITTED RUNS AND THREE IN THE STOPPED RUN . † MARKS A GATE STOP BEFORE SPENDING , WITH THE COMMITTED SITE REMOVED .

Case

k Cmt. Rep. New Tot. Naive

e388 a425† 5698a 5698b

2 2 3 4

3 3 2 3

3 0 2 3

1 0 2 1

4 3 4 4

7 7 6 7

Total

–

11

8

4

15

27

Two baselines bound the spend. A full rerun executes the repaired script from the start with an empty store. A reset asks a durable engine to restart from the last workflow task before the failed activity, which keeps the activities completed before that point. E7 adds three identity functions behind the same slot and commit layer, and two constructed probes test a payload cache. Most studies run offline, because E2b, E1, E1b, P1-C, P2, P2b, and E7 use stored inputs and stored model outputs and need neither Docker nor a provider key. E3 runs on Docker 28.0.1 for linux/arm64 with the pinned image, and E4 uses a real child process and the production SQLite store. E5 and E5b bill two image providers, and N1 bills a text provider.

VI. E VALUATION The evaluation reports spend, identity choice, repair quality, portability, and the cost of authoring and checking. A paid call is a dispatch attempt, including one that the provider rejects, and a successful execution returns an artifact. Every table that counts executions names which of the two it counts. A. Research questions and study design Six questions organize the study, and the next paragraph maps them to the studies. RQ1. What does a repair spend, and how does a durable engine compare? RQ2. Which identity should the contract use, and what does the writable set admit? RQ3. Can the model produce repairs that the gate admits? RQ4. Does the contract transfer to another domain? RQ5. What do authoring and checking cost? RQ6. What do reliability and overhead cost? All studies share one host, one run store, and one sandbox image, and every spend study uses a single run id per episode. RQ1 compares a contract run with a full rerun and with a durable engine’s reset. E2b replays real model repairs at the replay layer, E3 runs the protocol inside Docker, E5 and E5b bill a live provider, and the engine study ports five cases to Temporal. RQ2 re-runs the E2b cases under four identity functions that share the slot, divergence, and commit code and differ only in the key, and it applies seven deterministic edits to real prefixes. RQ3 measures repair on eight real failures and on a 32-script benchmark drawn from model output. RQ4 applies the same identity and replay checks to twelve customersupport tasks. RQ5 covers authoring on 60 tasks, execution on the accepted scripts, held-out transfer, task success with human scoring, and checker validity on two mutation corpora. RQ6 covers the crash window, store failures, orphan reporting, and the latency of the gate. Four quantities are counted. A committed identity is an identity with a stored record, and a replay serves one from the store. A duplicate executes a call whose work is already committed under the same run. Wrong reuse serves a record that belongs to a different callsite, and only E7 reports it.

B. Repair cost and engine comparison (RQ1) RQ1 asks what a repair spends, and we measure it at three levels. E2b replays real model repairs against a local harness, E3 runs the protocol inside Docker, and E5 and E5b bill a live provider. The subsection ends with a durable engine on the same repairs and with the cost model that turns call counts into money and time. a) Replay of real model repairs (E2b): E2b executes the original script against a deterministic local provider until the k-th capability execution fails, persists the committed slots, and then runs the repaired script on the same run id. The harness uses the production identity, slot, idempotency, gate, and certificate code, so replay is isolated from container and provider variance. The repaired source is the output that E2 produced for the same failure. Four failure points come from three scripts. One loop case is run at two failure points, the second iteration’s image and review, labeled 5698a and 5698b. Across the three admitted repairs, eight committed identities are replayed and none is executed again. Across all four runs, no committed identity is re-executed, no orphan is reported, and every certificate recomputes with differences=[]. The three admitted repairs make 12 successful executions where a full rerun makes 20. Counting the committed prefix of the stopped run, the episode is 15 against 27, and the four injected failures account for the difference between 15 and the 19 dispatch attempts. The parallel case commits three of four branches and replays all three, and the loop case replays 9

TABLE IV E5 REAL - PROVIDER REPAIR (S EEDREAM , 1K, ONE HOST ). Calls ARE HTTP REQUESTS TO THE PROVIDER . T HE NAIVE ROW IS A FULL RERUN OF THE REPAIRED SCRIPT, MEASURED OVER THREE CONTROL RUNS ON 2026-10-31 (83–89 S PER CONTROL RUN ).

64 64

48 32

33

32

Calls

Images

Wall clock

First run (3 ok, 1 rejected) Repair (one model attempt) Replay (same run id)

4 0 1

3 – 1

109.1 s – 35.6 s

Contract path, total Naive full rerun (measured, 3 runs)

5 8

4 7

144.7 s –

16 16 8

5

4

8 contract

occurrence 0 and executes occurrence 1, so the result holds for parallel and for sequential code. The a425 case shows the boundary. Its repair passes R00 to R12 and preserves the capability multiset, but it moves the fanout call into a helper. The committed site orchestrate/#1 disappears, and the gate stops the candidate before spending, with the status removed. Under structural identity the moved call is new and would execute, which is the trade-off the contract accepts. The shipped repair prompt lists the frozen sites, and RQ3 measures what that listing changes. b) End-to-end in Docker (E3): E3 runs the pinned image under Docker 28.0.1. One script is submitted three times under the same run id and store. The first submission, v1, calls echo(n=1) and echo(n=2) and then raises. The second, v2, appends echo(n=3) and changes nothing else. The third, v3, edits the committed n=1 payload to n=9. echo is a local counting handler that appends its argument to a list on every real execution, and the production idempotent layer wraps it with structural slots. v1 executes two calls and fails. v2 replays both and executes only the third, so the cumulative handler log is [1, 2, 3] rather than a rerun of all three. A control that runs v2 without the idempotent layer logs [1, 2, 3] again, which locates the saving in replay rather than in the handler. v3 is stopped before it starts. The gate raises dynamic_prefix_changed with the counterexamples call_changed and removed, and the handler log stays at three. The certificate recomputed from the slots has differences=[], and the experiment reports 8 of 8 checks. The episode costs three real executions instead of five. c) A live provider (E5, E5b): E5 puts the spend on a paid image API. A four-shot script requests a 1K image per shot, and the fourth call uses an unsupported size, so the provider returns 400 InvalidParameter after three committed images. The repair loop rewrites the script, the gate accepts the candidate, and the run replays on the same run id and store. Three committed identities are replayed with zero provider calls, and the replayed URLs are byte-identical to those of the first run, so the result is a stored artifact rather than a recomputation. The contract path makes five calls and produces four images in 144.7 s, while a full rerun makes eight calls and seven images. The model’s edit replaces a datadependent size expression with a valid one. The failing identity never committed, so the change falls outside the frozen prefix.

17

9

16

32

fanout width N reset / full rerun

Fig. 5. Per-identity replay against workflow-task reset on an N -way fanout with one failing branch. The contract makes N + 1 calls, and reset and a full rerun make 2N when the batch is restarted. Measured at N = 4, 8, 16, 32, with three repeats each. The gap is N − 1.

E5b adds four runtime failure classes on a second live provider, gpt-image-2 through a LiteLLM proxy. The failures are an invalid n (404), an invalid model (403), a client timeout (0.01 s), and a three-way fanout with one invalid branch. In each case the original run commits one or two calls and fails at the next, the repair changes a variable outside the call expression, the gate accepts, the committed prefix replays, and the failed identity executes once. Across the failed run and the repair the contract makes 3 calls where a full rerun makes 4, and on the partial batch it makes 4 against 6. Replayed artifacts are byte-identical and every certificate has no differences. The four classes and their controls cost 22 provider calls and $0.71. The timeout is the bounded window of Proposition 5. The client aborted before the provider replied, so the provider may have completed the request, and the contract re-executes the failed identity and records the window. d) A durable-execution engine (G1): We ported five cases to Temporal (CLI 1.9.1, server 1.32.0, Python SDK 1.34.0) and ran three recovery paths on the same committed history. The paths are a new run, a reset to the last workflow task before the failed activity, and a replay of the repaired source against the original history. Temporal activities are deterministic local stand-ins that log every dispatch. Table V reports the episode totals, which count the failed run and the recovery run together. On sequential tail repairs the reset matches the contract. For 5698 and e5 both approaches make five attempts and produce four artifacts. Reset keeps the activities completed before the failed one and re-executes from there, which costs the same as replaying committed identities. The advantage appears when the failure falls inside a fanout. On e388 the reset re-executes the three branches after its reset point and makes seven attempts, while the contract replays three committed branches and executes one, for five. The gap grows with width. With the reset point fixed before the batch, the contract makes N +1 attempts and the reset makes 2N , and the measured widths N = 4, 8, 16, 32 save 5 against 8, 9 against 16, 17 against 32, and 33 against 64 calls, with three repeats each. Figure 5 isolates that shape. The identity function also differs. Moving a committed call into a helper leaves the command sequence unchanged, so Temporal resets through the a425 repair and completes it 10

TABLE V T HE SAME REPAIRS UNDER THE CONTRACT AND UNDER T EMPORAL . E ACH CONTRACT / RESET / NAIVE CELL IS ATTEMPTS / SUCCESSFUL EXECUTIONS FOR THE WHOLE EPISODE . R ESET IS T EMPORAL’ S STANDARD RECOVERY, TO THE LAST WORKFLOW TASK BEFORE THE FAILED ACTIVITY, AND NAIVE IS A NEW RUN OF THE REPAIRED SCRIPT. E 388, 5698, E 5, AND A 425 ARE REAL REPAIRS . S 1 IS A CONSTRUCTED PROBE THAT ISOLATES THE COMMITTED - PAYLOAD CASE , AND ITS RESET RETURNS A STALE ARTIFACT, BECAUSE THE FIRST SHOT IS THE RECORDED RESULT FOR THE OLD PROMPT. † R EPLAY ACCEPTS BUT RETURNS THE RECORDED FAILURE , AND ‡ REPLAY ACCEPTS AND RETURNS THE RECORDED RESULT.

Case

Shape

Contract

Reset

Naive Replay

Outcome

e388

parallel fanout

5/4

7/6

8/7

ok

5698 e5

sequential loop sequential, 400

5/4 5/4

5/4 5/4

7/6 8/7

ok ok†

a425

relocate into helper

4/3, no output

7/6

8/7

nondet.

s1

committed payload

4/3, no output 5/4, stale

8/7

ok‡

contract replays committed branches equal spend, four artifacts each equal spend, reset applies the new payload, replay does not gate stops before spending, engine resets through digest stops, engine reuses the old result

DBOS 3.3 with step-level fork reproduces the same limit. On a three-step sequential workflow it re-executes only the failed step, for four calls and equal spend. On a four-way fanout it re-executes three steps, for seven calls against five for the contract. Step-level fork is finer than Temporal’s workflow task, but a completed branch after the fork point is still reexecuted, so the fanout gap follows from the granularity of the identity. A repair that must change a committed payload can append a new call at a new identity and use its result. The committed call replays and its artifact is left out of the product. On s1 this costs two new calls, the failed fourth and the replacement, and returns the corrected artifact, while a full rerun of the repaired script costs five new calls and re-pays the three committed images. The gate admits the append because it adds a callsite, and the digest stays quiet because the new call is a new identity. e) Workload and cost model: The platform history contains 52 unique scripts, and 21 of them contain no capability call. Fourteen use parallel, and 31 use a loop. Thirtytwo fail the current checker, and of those 22 are old-API migrations, eight are the E2 failures, and two are out of scope, one with an R10 import and one with a non-production capability. The 30 recorded jobs are development runs, and the store holds 165 slot records, so the cost evidence is unit costs plus the measured cost of real runs. Prices vary by provider, model, resolution, duration, and plan, so we carry the per-call price p as a variable and use the catalog estimate of $0.02 per image call as one calibration point. Every derived figure is linear in p, and a repair that replays k calls saves k · p. At p = $0.02 a repair that reexecutes three images costs $0.06, and a fanout saves seven calls, or $0.14, at N = 8, and 31 calls, or $0.62, at N = 32. The catalog prices a video call at $0.50 and a video edit at $0.60. A six-shot repair that replays three shots saves 3p, which is $1.50 at p = $0.50, and an N -way video fanout saves (N − 1) · p, which is $2.50 at N = 6. f) Net benefit: The repair pays off in both time and money. It saves N − 1 provider calls on an N -way partial fanout and adds at most 1.19 rewrite attempts, measured as 2.19 against 1.00 in the controlled ablation of RQ3, while the production path of E2 averages 1.12. The measured latencies

in seven attempts, while our gate stops the candidate before spending. The stop is correct under structural identity, because the moved call has a new σ and would execute. A committedpayload change lies outside the view of replay. On s1, a constructed probe, Temporal returns the recorded result for the old prompt, with five attempts and a stale first shot, while the digest raises Divergence before dispatch, with four attempts and no output. Replay itself differs as well, because it preserves the recorded outcome. On e5 the repaired fourth call has a new payload, but the history records a 400 at that position. Replay returns the recorded failure, and the new payload needs a reset, a new run, or a versioned branch. The reset column is therefore the fair comparison, and the replay column is not. On a second provider, gpt-image-2 through a LiteLLM proxy, a six-way fanout with one empty-prompt failure makes seven paid calls and returns six images, five of them replayed byte-identically, while a full rerun makes twelve. The experiment cost $0.47 for twelve billed images across the contract run and its control, and the contract path alone is seven calls, six images, and $0.23. We also asked the model to make the payload edit. Twenty scripts with a committed prefix each carry a constant that feeds the first committed call, and the repair instruction changes the brand color and asks for the constant to be updated without touching the call expression. All twenty candidates keep the call expression and pass the gate. At dispatch the digest raises Divergence in all twenty, while a replay-only engine returns the recorded artifact in all twenty. A payload cache completes all twenty with 48 executions, the supersede append completes all twenty at the same count, and a full rerun executes 68. These are instructed edits, so they show that the model can produce the case. They do not measure how often it would do so unprompted. A reset replays recorded results and re-executes from the reset point. The operator chooses that point, and replay is payload-blind. A repair that changes the payload of a committed call is therefore either replayed with the old result or, when the reset point moves before that activity, re-executed and paid again. The contract closes both gaps with a sourcelevel set of allowed edits that is checked before a container starts, a per-identity replay, and a payload digest. 11

TABLE VI E7 IDENTITY BASELINES OVER THE FOUR E2 B RUNS . Dup. COUNTS EXECUTIONS OF WORK ALREADY COMMITTED UNDER THE RUN , wrong

TABLE VII W HAT THE GATE ADMITS , ON THREE REAL SCRIPTS . YES = ACCEPTED , C C = C A L L _ C H A N G E D , R M = R E M O V E D , — = NOT APPLICABLE TO THAT SCRIPT.

COUNTS REPLAY HITS WHOSE COMMITTED RECORD BELONGED TO A DIFFERENT CALLSITE , AND stops COUNTS RUNS THAT END BEFORE COMPLETION . T HE LINE ROW ’ S EXECUTION COUNT REFLECTS EARLY STOPS .

Scheme structural + gate payload (cap, H(p)) ordinal line

Exec. Replayed Dup. Wrong Stops 15 16 16 8

8 11 7 6

0 0 1 0

0 2 0 0

1 0 1 3

are 17.2 s per rewrite (154.4 s over nine E2 attempts) and 27.3 s per image call (109.1 s for four calls in E5). At those latencies the net time advantage is 61 s and three calls at N = 4, which is 82 s of provider time against 20.5 s of rewriting, and 826 s and 31 calls at N = 32. The break-even point for a rewrite is (N −1)·p/1.19, which is $0.05 at N = 4 and $0.52 at N = 32 for images, and $1.26 and $13.03 for video. A deployment can apply the rule to its own prices.

Edit

e388 a425 5698

literal in payload computed payload statement outside insert a non-call statement wrap in new block delete a call append a new call

cc cc yes yes

— — — yes

rm rm yes

rm rm — rm yes yes

cc cc yes yes

c) Shifts under the production gate: We ran the two runtime shifts against the production gate, runtime rule, and ledger. Widening a fixed-payload retry loop from three to six iterations is accepted by the gate and executes three more calls. The policy warn records three semantic repeats without blocking, deny raises before dispatch and spends nothing, and the default auto behaves as deny here because image.generate has side effects. Inserting a fanout branch shifts every later path index. The runtime digest raises Divergence after one execution, so the addition reports as a failure, and all certificates recompute consistently. d) What the gate admits: The writable set of the contract is callsite-level, and the implementation checks three things. A frozen callsite must exist, it must name the same capability, and its call-expression fingerprint must be unchanged. Statements around the call stay writable. We measure what that admits on the four E2b failure points, first by edit class and then at scale. We apply seven deterministic edits to the real prefix and ask the production gate. Table VII shows the result, and the split is exact. The gate stops every edit to the argument AST of a frozen call, whether it changes a literal or wraps a computed value. It admits every edit to surrounding statements, an insertion of a non-call statement before the call, and an append. It stops every edit that removes the callsite or relocates it into a new block, and it reports removed. The split replicates beyond the three E2 scripts. We applied the same seven edits to twenty E1 scripts that execute end to end against a deterministic local provider, each with its maximal prefix, so every capability call is committed. Of 140 edit-script pairs, 136 apply, and 60 are accepted against 76 stops. The stops are the predicted ones. Thirty-six are call_changed, a literal or a computed value in the payload, and 40 are removed, a block wrap or a deletion. The three accepting classes accept on every script, so the edit classes are a property of the gate rather than of the scripts. Payload values inside a frozen call are frozen with it. The fingerprint hashes the argument AST, so a literal change is as visible as an expression change. The eight real repairs in E2 edited the code around the call, for example a slice on a result list or a slice on the list joined into a prompt. The gate leaves that code writable, and the runtime digest checks it for committed identities. The unit of the contract is the capability call, not the block and not the line, and the choice has a cost. Relocating a

C. Identity and the writable set (RQ2) RQ2 asks which identity the contract should use and what the choice costs. E7 turns the comparison into a measurement on the same four repairs, and the acceptance study measures what the gate admits on real prefixes. a) Four identity functions (E7): Related work positions step identity by argument, and E7 makes it a measurement. We re-ran the four E2b cases under four identity functions that share the slot, divergence, and commit logic and differ only in the key. The keys are the structural identity with the gate, the payload pair of capability and digest, the arrival ordinal, and the source line. Figure 6 draws the five strategies on one timeline, including the full rerun, and Table VI gives the counts. The structural column reproduces E2b exactly, with 15 executions against 27 and eight replays from the store, which validates the harness. Payload identity completes every run, and two of its hits land on a record committed by a different callsite, which is the wrong reuse that the contract’s identity prevents. Ordinal identity re-executes one committed call because arrival order is not semantic order. Line identity stops on three of four runs, because fanout branches and loop bodies share a line, so its execution count reflects the early stops. The comparison runs four real repairs under one slot and commit layer, so the identity function is the only variable. b) A payload cache: E7 counts wrong reuse, and a constructed probe shows what it produces. We built 30 tasks with two identical-payload calls each. Fifteen require two distinct artifacts with different roles, and 15 need one artifact because the second call is a redundant retry. Under a payload cache the second call returns the first artifact, and under structural identity it executes. On the different-role tasks the cache passes 0 of 15 and structural identity passes 15 of 15. On the same-role tasks both pass, and the cache uses 15 executions against 30 for structural identity. A payload key is a deduplication key, so two roles with the same payload share one key. 12

Full rerun

Payload identity

Ordinal identity

Line identity

Structural + gate (Ours)

Task

Task

Task

Task

Task

rerun 1–4

key = (cap, H(p))

key = arrival #

key = source line

replay 1–3 run 4

Output

Output

Output

Stop

Output

27 exec pay twice

16 exec 2 wrong

16 exec 1 duplicate

8 exec 3 stops

15 exec · 8 replay 0 dup · 0 wrong · 1 stop

Fig. 6. Five identity strategies on the same four E2b repairs. Each panel applies one key function to the committed prefix and the failed tail, and the badges summarize the outcome from Table VI. Full rerun pays all calls again. Payload identity returns two results recorded at a different callsite, ordinal identity repeats one committed call, and line identity stops on three runs. Structural identity with the gate replays eight committed identities and stops the one relocation. Solid arrows execute, dashed rules separate strategies, and blue marks the contract.

53% of candidates before acceptance. All eight repaired scripts preserve the capability-call multiset, and three contain no capability call, so the multiset guard applies to the other five, which preserve it. The passing edits are local, a bound or a slice, except for a425, which moves a committed call into a helper and is stopped at replay (RQ1). The one two-rewrite case first cleared R03 and R12 but introduced an R05 fanout-without-guard violation, and the second candidate cleared both, which is why this sample averages 1.12. b) A 32-script benchmark (E2-32): E2 has eight failures, so we drew 32 unique model-authored scripts from the E1 outputs that fail the current checker. Twenty-two come from Gemini-3.5-Flash and ten from DeepSeek-V4.1-Flash. All are loop-bound failures, six also carry R05, and all stay within the four production-bound capabilities. With a two-rewrite budget the loop repairs 32 of 32 at the first rewrite, with a mean of 1.00. All 32 preserve the call multiset, and the checker intercepts half of the candidates. The 32 repairs are generated before the prefix is built, so the store is empty at repair time and the model sees no frozen-site list. We then replay each repaired script against the maximal prefix built from its original script. Twenty-six carry a prefix that the production annotator compiles and that has at least two calls, and six have fewer than two calls. Of the 26, the gate accepts 22 and stops four as removed. The 22 replay 258 committed identities, execute 22 new calls, re-execute no committed identity, and report three unused committed occurrences as orphans. The scale set reproduces the E2b result, and the gate separates static repair success from replay success. c) Four rules: The 32-failure benchmark isolates R03, so we built a 35-script corpus from the P2 destroying-mutant corpus to test rule generality. The rules are R03 with 9 scripts, R04 with 9, R05 with 6, and R12 with 11, each with at least two capability calls. All 35 repair at one rewrite and 34 preserve the call multiset. Thirteen carry replayable prefixes, and 22 are reported separately. The gate passes eight and stops five, and every stopped candidate is an R05 repair that removes the unguarded parallel call, so the static repair succeeded while the committed callsite disappeared. The eight passing scripts

TABLE VIII E2 STATIC REPAIR OUTCOMES ON EIGHT REAL CONTRACT FAILURES . A LL EIGHT ARE ACCEPTED BY THE CHECKER . E2 B REPLAYS THE THREE THAT CARRY A REPLAYABLE PREFIX ( FOUR FAILURE POINTS ), AND ONE CANDIDATE IS STOPPED AT THE GATE (S ECTION VI-B).

Rewrites allowed

Repaired

Rate

0 1 2 3

0/8 7/8 8/8 8/8

0% 87.5% 100% 100%

replay-tested by E2b

3/8

—

committed call into a helper is routine, and the gate stops it because the moved call is a new identity and would execute. The stop prevents a second payment (Figure 1), and Section VI-B0d measures it next to a reset that completes the same repair. A finer freeze at committed occurrences would widen the loop-repair space, while relocation would remain a trace-level check. D. Repair quality (RQ3) RQ3 asks whether the model can produce candidates that the gate admits, and how many rewrites that takes. We measure the repair loop on eight real failures, on a 32-script benchmark, on a corpus that covers four rules, and under a controlled prompt ablation. a) Eight real failures (E2): E2 uses eight real modelauthored scripts with contract violations and initial errors in R03 or R12. They are the strict subset of 32 checker failures from 52 historical scripts that have replayable source and envelope, are deduplicated by digest, and stay within the four production-bound capabilities. Twenty-two of the 32 are old-API R02 migrations and are excluded. The repair driver validates each candidate with the checker and a nondecreasing call-count guard, feeds structured counterexamples back to the model, and stops after three rewrites. The model is gemini-3.5-flash at temperature=0. All eight repairs pass the checker. Mean rewrites on successful tasks are 1.12, the first-attempt rate is 7 of 8 with a Wilson 95% interval of [0.53, 0.98], and the rate within two rewrites is 8 of 8 with [0.68, 1.0]. The checker intercepts 13

TABLE IX R EPAIR AT SCALE . T HE 32- FAILURE BENCHMARK IS DRAWN FROM E1 MODEL OUTPUTS THAT FAIL THE CURRENT CHECKER ( LOOP - BOUND FAILURES , AND SIX ALSO CARRY R05). H ISTORICAL E2 REPLAY IS FOUR POINTS ON THREE SCRIPTS . T HE BENCHMARK REPLAY IS TWENTY- SIX SCRIPTS .

Failures Repaired at one rewrite Repaired within budget Mean rewrites Call multiset preserved Replay-tested Gate pass Replayed identities New executions Committed identity re-executed

Historical (E2)

Benchmark (E2-32)

8 7/8 8/8 1.12 8/8 4 points 3/4 8 4 0

32 32/32 32/32 1.00 32/32 26 22/26 258 22 0

TABLE X C USTOMER - SUPPORT STUDY. Chk. COUNTS CHECKER - VALID SCRIPTS , Exec. THE SCRIPTS EXECUTED AGAINST THE LIVE TEXT PROVIDER , Rub. THE RUBRIC PASSES , Rep. THE REPLAY POINTS , Ids THE REPLAYED IDENTITIES , AND Dup. THE COMMITTED IDENTITIES EXECUTED AGAIN . T HE EXECUTED AND REPLAY SUBSETS ARE FIXED AND REPORTED WITH PER - CELL DENOMINATORS . Model

Tasks Chk. Exec. Rub. Rep. Ids Dup.

Gemini-3.5-Flash DeepSeek-V4.1-Flash

12 12

12 12

6 3

6 3

2 2

4 4

0 0

Total

24

24

9

9

4

8

0

differs. E. Portability (RQ4) The media studies establish the mechanism on high-cost calls, so we built twelve customer-support tasks with a different shape. A task classifies a ticket, extracts fields, drafts a policy-compliant reply, and decides whether a human must review it. The tasks include single tickets, three-ticket fanouts, candidate selection, policy-section summarization, missinginformation follow-up, and a policy-conflict escalation. The capability is text.generate, and the calls are billed and read-only, so the mechanism is exercised without a media artifact. Two models, gemini-3.5-flash and deepseek-v4.1-flash, wrote scripts at temperature zero. Table X reports the study, in which 24 scripts, twelve per model, pass R00 to R12 and use the granted capability. Nine of the accepted scripts were executed against the live text provider and scored by the deterministic rubric of the task, and all nine pass. An author read of three outputs agrees with the rubric. The pass rate is over the nine executed scripts, and the table reports the per-cell denominators. Four accepted scripts were then replayed after a tail failure injected at the third text call. Eight committed identities were replayed and no committed identity was executed again. A support fanout probe tests the boundary, where a repair moves the committed text.generate call into a helper, and the production gate stops it as removed before dispatch. The study applies identity, replay, and the gate to a second domain, and the repair loop itself is measured on the media corpus.

replay 148 committed identities with no duplicate. The replaytested R03, R04, and R12 repairs all pass, with 51, 52, and 45 identities. d) Prompt ablation: E2 reports a 53% static interception rate, and to see which prompt changes that rate, we ran the four E2b failure points under three prompts. Arm A gives the runtime error only, arm B adds the frozen sites, and arm C adds to B an explicit prohibition on moving a committed call into a helper. The rewriter is gemini-3.5-flash at temperature=0.3, and we run four samples per arm. The pooled result favors listing the prefix. Arm A takes 1.00 mean attempts and produces 3 accepted candidates out of 12, arm B takes 2.19 and produces 8 of 12, and arm C takes 2.00 and produces 9 of 12. Arm A measures the unlisted-prefix condition, in which 1.00 attempts suffice across all four samples, because the model produces a checker-valid candidate in one rewrite, and three of twelve final candidates pass the gate. In that condition the default behavior of the model is to restructure a committed call. Listing the frozen sites changes the result. Admissibility rises from 3 of 12 to 8 of 12 at a mean of 2.19 attempts, and the gate stops fourteen candidates along the way that the model then repairs, while under arm A those candidates would have been the final answer. Arm C reaches 9 of 12 at 2.00 attempts, within noise of arm B at this sample size, so we keep B as the shipped prompt. Pooling the three arms and three samples, 36 final candidates reach the gate, 20 pass and 16 stop, and every stop is a removed callsite. Across the 40 final candidates drawn from real failures, which adds four arm-A candidates from the fourth sample, 23 are accepted and 17 stop, all for a moved or deleted callsite. A gate alone turns a restructure into a retry, and a prompt alone has no enforcement. The useful prompt change is naming what is frozen, and the pair works because the gate supplies a counterexample and the prompt supplies a model that can read it. e) A second model: With deepseek-v4.1-flash the loop repairs 5 of 8 at one rewrite and 8 of 8 within three, with a mean of 1.38. For gemini-3.5-flash the rates are 7 of 8 and 8 of 8 within two, with a mean of 1.12. Bounded convergence holds for both models, and the first-attempt rate

F. Authoring and checking (RQ5) RQ5 covers authoring and checking. We measure authoring on 60 tasks, execution on the accepted scripts, held-out transfer, task success with human scoring, and checker validity on two mutation corpora. a) Authoring (E1): E1 contains 60 tasks, of which 22 are anchors from real batches and 38 are synthetic, and they cover nine capabilities, 49 tasks within the four production-bound capabilities, 34 sandbox tasks, and 26 dry_run tasks. Each model receives the same skill document, capability catalog, and fixed envelope, and reference scripts are not included. Sampling uses temperature=0, one sample per task, and max_tokens=16384, and a sample is accepted when R00 to R12 pass.1 E1 runs without a container or a provider, and 1 Four DeepSeek samples were regenerated with a 32,768-token budget.

14

the models are deepseek/deepseek-v4.1-flash and gemini/gemini-3.5-flash. Table XI reports 110 of 120 checker accepts. Ten samples fall outside the checker’s model, and all are R03. Manual review finds eight with a static cap outside the checker model and two without a cap, so 110 of 120 is a lower bound on acceptance. Capability matching is higher, at 117 of 120, so naming the right capabilities is easier than satisfying every syntactic obligation. The difference between 59 of 60 and 51 of 60 is significant on the 60 paired tasks (McNemar p = 0.02), and it describes this sample. The four regenerated samples turn the original 106 accepted outputs into 110, and E1b-60 uses the original 106. A pre-registered 20-task subset is sampled three times at temperature 1.0. Gemini passes 17 of 20, 16 of 20, and 20 of 20, and DeepSeek passes 17 of 20, 15 of 20, and 19 of 20, with a sample standard deviation of about 10 points each. Single-sample acceptance rates carry sampling variance, and we report the two temperature settings separately. b) Execution (E1b): Static acceptance is the first gate and execution is the second. We pre-registered a 24-task stratified subset with 12 production-bound, 6 sandbox, and 6 dry-run tasks, and executed the scripts accepted in the original E1 run against a deterministic local provider without re-sampling a model. The local runtime uses the container Context and a local RPC that enforces grants, approvals, provider-call and concurrency limits, and input schema, and it runs without Docker or a provider. Of 48 nominal task-model units, 43 scripts were executable. All 43 terminated without an uncaught exception or a timeout, made no denied or over-budget call, and returned a serializable object. They make 244 local calls, with a median of 4 ms and a p95 of 15.7 ms, and 60 KB of output. One adequacy boundary appears in Gemini e1-002, which hardcodes MAX_SHOTS = 5 while the fixture has six shots, so it makes 11 calls where 13 are required, with five image and five review calls instead of six each. The gap is in adequacy, and the checker and runtime behave as specified. A pre-registered 60-task extension reuses the 106 stored outputs accepted in the original run. The frozen 24 retain their assertions, and the additional 36 use generic structural evidence, which is a non-empty serializable result, no failure status, and at least one artifact per expected capability. Semantic quality is measured separately in R3, and execution passes 97 of 106 (91.5%, 95% Wilson [84.6, 95.5]), the frozen subset reproduces 42 of 43, and the extension contributes 55 of 63. Nine execution differences remain, which are six missing capability calls, two output-shape failures, and one over-budget call. The 106 scripts make 554 local calls, with a median of 3 ms. c) Held-out transfer (P1-C): The task set of E1 was used during checker development, so we pre-registered 20 new tasks after freezing the definition and the execution manifest. The set covers approval and budget boundaries (6), parallel and partial-failure handling (4), long loops and large inputs (4), data-bearing payloads (3), and prompt-injection and privilege prompts (3). Two models run once per task at temperature 0,

which is 40 calls, and static-valid outputs run against the same local provider. Gemini accepts 17 of 20 and DeepSeek 18 of 20, for a descriptive pool of 35 of 40 (87.5%). Five fall outside the checker model, of which four are bounded idioms and one has two input-derived loops with no static cap. We keep 35 of 40 as the pre-registered lower bound. All 35 static-valid scripts pass the local provider, with no false pass. d) Task success (R3): We ran twenty outputs end to end on real providers, four image tasks on Seedream and sixteen text or storyboard tasks on Gemini. A task-specific rubric checks the requested artifact, which covers shot counts and durations, candidate counts, review counts, coverage, and failure groups. Eighteen of twenty pass, ten of ten authored and eight of ten repaired. One case is a coverage boundary, where the repaired feedback workflow counts 9 of 20 items, and in one repair the failure branch was not reached because the provider succeeded. Three annotators independently scored the same twenty outputs, and a task passes when its mean over the three dimensions is at least 3. All three pass 16 of 20 and agree on every task-level verdict, with a Fleiss kappa of 1.0. Pairwise agreement ranges from 50 to 55 of 60 dimension scores, with 156 of 180 exact (86.7%), and no pair differs by more than one point on any score. Their disagreements with the rubric are identical on six cases. Four are cases where the rubric passes an output that all three annotators judge below the bar. Two are cases where the rubric flags an output that all three accept, namely the coverage miss and the failure branch that the provider did not reach. The rubric is a floor for task completion, and the human read is the stricter measure. e) Checker validity (P2): Static acceptance is a syntactic verdict, so we measured both error directions on a preregistered mutation corpus. The 40 bases are a deterministic hash-selected subset of the 106 unique static-valid scripts of the original E1 run. Destroying mutants cover nine contract rules, and preserving mutants cover five semantics-preserving edits. The mutation study found and closed an R05 coverage gap. Indirect fanout was outside R05 when the fanout function was reached through a list variable, while the direct form ctx.parallel([f(i) ...]) was rejected. After the fix, the 419-mutant corpus gives α = 0/269 with a 95% Wilson interval of [0.0, 1.4] and β = 0/142 with [0.0, 2.6]. Every destroying operator hits its target rule, and the per-operator denominators are in the artifact. The missing_review layer, with 8 of 8 accepted, measures task-level adequacy, which α leaves outside its scope. Mutation testing provides a controlled proxy [8], [9], and our operators are rule-derived, so α is a conservative estimate for real contract failures. A zero rate describes these mutants, and the runtime rule carries the safety claim. The Wilson intervals are descriptive because mutants from one base are dependent. On 35 held-out P1-C bases with 323 mutants, of which 205 are destroying, 111 preserving, and 7 semantic, the corpus gives α = 0/205 with [0.0, 1.8] and β = 0/111 with [0.0, 3.3]. Seven missing_review mutants remain outside α. 15

TABLE XI E1 CHECKER ACCEPTANCE ON 60 TASKS PER MODEL .

Model DeepSeek-V4.1-Flash Gemini-3.5-Flash Pooled

n

Accepted

Rate

95% Wilson

60 60 120

59 51 110

98.3% 85.0% 91.7%

[91.1, 99.7] [73.9, 91.9] [85.3, 95.4]

VII. T HREATS TO VALIDITY

G. Reliability and overhead (RQ6)

a) Construct validity: Our guarantee is identity-level, and it covers the calls that a candidate keeps and the identities that it invokes. A new callsite that repeats an old provider request is outside it, which the ledger reports and the policy may deny, and so is a duplicate inside the provider, which needs a provider idempotency key. The crash window is bounded rather than closed. An unresolved attempt fails closed, and an explicit abandonment can repeat at most k effects per crash. The checker is both an instrument and an object of study, and its acceptance rate describes the syntactic model of the contract rather than the semantic quality of a script, which R3 measures separately. Because the mutation corpora are rulederived, the zero false-accept rate is a conservative estimate for real contract failures. b) Internal validity: Model-dependent measurements carry the pre-registered number and a separate variance study. E1 samples once per task at temperature 0, while a 20task subset sampled three times at temperature 1.0 has a standard deviation of about 10 points, so a single-sample rate carries sampling variance. The prompt ablation compares three prompts at four samples per arm, which is enough to see a large effect and not enough to rank arms B and C. Instructed edits drive the payload-edit study, so it shows that the model can produce the case and not how often it would do so unprompted. Stored model outputs drive E2 and E7, which removes run-to-run variance at the cost of describing one sampling round. c) External validity: One platform, one run store, and one sandbox image support the evaluation, and the media domain dominates it. The customer-support study broadens the task distribution with a read-only, lower-cost capability, and it executes 9 of its 24 scripts. Two billed image providers, one text provider, two model families, one full durable engine, and one step-fork probe cover the provider and engine axes at the resolution of a case study. A deployment with hundreds of capabilities, provider-side idempotency keys, or multi-host storage is outside the measured set. The repair corpora are small by design, because each case needs a replayable prefix and real provider failures are the scarce input. d) Conclusion validity: For the identities that were replayed, the zero duplicate count is exact, and the acceptance, repair, and pass rates carry Wilson intervals with their denominators. Mutants from one base share its structure, so the mutation corpora are not independent samples and those intervals are descriptive, with per-operator denominators in the artifact. The 258 replayed identities come from 22 scripts, and the eight real repairs are a strict subset of 32 checker failures. Because the spend advantage is a property of the fanout shape

RQ6 covers the reliability and overhead of the machinery. We measure the crash window, store failures, orphan reporting, and the latency of the gate. a) The crash window (E4): E2b injects a handler exception and E3 raises inside the script. The fail-closed window needs a durable attempt, a process that dies before commit, and a provider that may or may not have completed. E4 creates that window with a real child process and the production SQLite store. The child writes the attempt and then kills itself with SIGKILL. In the timeout case the parent kills a child whose handler sleeps. In the parallel case three threads write three attempts and synchronize on a barrier, and the process is killed. The parent then replays through _idempotent. Across the five cases, every unresolved attempt was detected before a handler ran, every committed identity was replayed from the store, and every replay returned a stored result. After reconcile_attempt(..., result=None) the abandoned identity executes once and a second replay is a cache hit. After reconcile_attempt(..., result=...) the replay returns the stored result and executes zero times. The parallel case leaves three attempts and blocks all three, which is the k = 3 instance of the analytical bound. Whether the provider completed before the crash is the uncertainty that the fail-closed protocol and reconciliation exist for. b) Store failure and orphans: Storage errors are failclosed by default, so a failed prefix listing or idempotency read raises StoreUnavailableError and the failure is visible. With a store that raises on every read, a one-call script raises with zero handler executions, which trades one visible failure for an invisible duplicate charge. Shrinking a committed loop from three iterations to one leaves every frozen callsite in the source, so the gate accepts, and only occurrence zero is invoked. Two committed identities become orphans and the run otherwise succeeds. DYNAMIC_ORPHAN_POLICY is warn, which persists the report, or stop, which persists the report and fails the run. We keep warn as the default because an orphan is a fidelity event, and a deployment that bills per artifact chooses stop. c) Overhead: The checker, the prefix gate, and the certificate stay in the low-millisecond range on one host. The checker has a p50 of 1.70 ms and a p95 of 4.21 ms over 116 scripts and 2320 samples. The gate ranges from 0.041 ms at one frozen site to 4.869 ms at 200 frozen sites, and certificate persist and verification stay below 0.55 ms up to 200 sites. These are in-process host-CPU numbers with an in-memory store, which is the algorithmic cost of the mechanism. The artifact carries the per-bucket and per-size records. 16

and the sequential case ties, the numbers should not be read as an average saving over repairs in general.

that produced committed effects. A patch can pass every test and still move a committed call, and the gate stops it before the provider is paid. b) Three adjacent lines of work: Workflow instance migration [29], [30], [31] has structural, behavioral, and dynamic correctness criteria, but it can roll back a marking and recompute state. A paid provider call cannot be recomputed for free, so the contract adds a pre-spend source predicate rather than a migration rule. A content-addressed cache or a provider idempotency key [36] removes duplicate charging at the provider, but it does not decide which source edits are allowed, and it can return the artifact of another callsite, which RQ2 measures. The contract composes with a provider key and does not replace it. APR patch validation asks whether a patch is correct, while the gate asks whether a revision may still touch a committed effect. The two predicates are independent. Our candidate must pass the checker and the gate, and the gate can stop a patch that is semantically correct.

VIII. R ELATED W ORK A. Durable Execution and Replay Durable execution engines record a history and require the replayed code to reproduce its command sequence. A tailcompatible edit replays, and an incompatible one becomes a non-determinism failure or needs a version marker [5]. Both families make the same engineering choice. DAG orchestrators serialize a task graph and rerun the graph [10], while durable runtimes journal each step and re-execute the code around the journal [6], [7]. Both replay a fixed program, and the sourcelevel question stays open. Resume Means Resume [1] formalizes prefix continuation, effect exactly-once, and consume-once for a fixed program, and it excludes cross-version checkpoint migration. LIMBO [11] proves that no verification-only policy is exactly-once under late commits without a bound on in-flight time, and it measures that attaching idempotency keys lowers the duplicate rate from 28% to 4%. State Without a Landlord [4] records (callSite, callIndex, argsHash) in replay capsules and assumes the source unchanged. Compensation and checkpointed stream processing [12], [13], [14], contentaddressed build caches and dynamic software updating [15], [16], [17], and provenance [18] keep or restore a history. None of them defines which source edits are allowed.

C. Positioning Table XII states the difference by system. Identity, authorization, and lifecycle are established machinery, and the source-level writable set, the callsite-level freeze, and the prespend predicate are the additions of the contract. The identity is established machinery, and what the contract adds is the allowed set and its measured limit. We define which source edits preserve the committed calls, establish the soundness of the gate and describe its cost on relocation, and measure the limit against a durable engine. The spend bound follows, and it is strict on partial fanout.

B. Identity, Revision, and Repair The orchestration layer is increasingly a model artifact. ReAct [19] interleaves reasoning with tool calls, and AutoGen [20] and LangGraph [21] compile multi-agent interaction into stateful graphs. These frameworks make the plan flexible and leave open which part of a rewritten graph may still touch a paid effect. Pollard [2] assigns semantic step identities over caller-selected canonical input, kind, attempt, and parent. Its strict replay fails closed, and its record and hybrid modes execute the new step. The identity is semantic and chosen by the caller, while ours is syntactic and computed by the host, which is what lets a pre-spend check run without the model’s cooperation. ControlScope [3] compares keeping the code, editing the arguments of the next call, and replacing the unfinished continuation, and it measures task success. Recent work repairs authorization [22], pending decisions [23], and rollback [24], and it studies multi-agent plans and handoffs [25], [26] and gated or verified execution [27], [28]. Classical instance migration [29], [30], [31] is the closest historical analogue, and it can discard earlier loop iterations and recompute a marking. A paid provider call cannot be discarded that way. a) Repair loops and effect validation: LLM repair is usually framed as patch generation. Reflexion [32] and SelfRefine [33] iterate on feedback, ChatRepair [34] repairs bugs through conversation, and the APR literature [35] judges a patch by whether it passes tests. Our loop also uses structured counterexamples, but the acceptance predicate is different. A candidate is admitted only if it preserves the call expressions

IX. C ONCLUSION A workflow written by a model can be revised without paying twice for what it already did, and without returning a result that the revision has replaced. The contract gives every capability call a structural identity and freezes the call expression that produced a committed payload. It stops a rewrite that moves or changes that expression before a container starts, and it stops a committed payload change at dispatch with a digest. The gate stops a relocation that preserves the call, its payload, and its order, because under structural identity the moved call is new and would execute. Proposition 4 states why no local identity avoids the choice. The digest closes the other case and fails closed when the past must change. Against a durable engine’s reset, the contract saves calls on a partial fanout and stops a payload change that reset reuses, while it stops a relocation that reset completes and ties on sequential repairs. Two directions follow from the result. A pre-spend check that works on traces rather than callsites could accept a relocation while preserving the committed call sequence, and the evidence can be widened to more platforms, more domains, and more engines. 17

TABLE XII N EAREST NEIGHBORS BY THE QUESTION THE REVISION CONTRACT HAS TO ANSWER . T HE TWO MIDDLE COLUMNS ARE THE MECHANICALLY CHECKABLE ONES , BECAUSE THEY ASK WHETHER THE SYSTEM DEFINES A SOURCE - LEVEL SET THAT A REWRITE MAY TOUCH AND WHETHER IT STOPS A REWRITE BEFORE A PAID EFFECT. Work

Unit

Writable set

Pre-spend reject

What the contract adds

Resume [1]

fixed program + persistence API semantic step identity runtime revision scope replay capsule

no (fixed program)

yes (non-determinism) yes (hash seal) – no

source-level revision across versions

yes (authorization)

source callsites as the unit

no no (backward) partial no (log level) no

yes (pre-effect) no (rollback) yes (gate) partial partial

source rewrite as the unit forward revision after a tail failure one partial execution’s committed boundary callsite identity and a committed boundary source callsites

partial (tail-compatible) yes (append, site-level freeze)

no (replay-time)

a pre-spend source predicate and a payload digest the full column, with writable set, gate, and digest

Pollard [2] ControlScope [3] State [4] APAS [22] ATR [23] SafeResume [24] SKILL.nb [27] ALAS [25] BRIDGE [26]

authorization-bearing action pending decision checkpoint/rollback reusable workflow artifact multi-agent plan multi-agent handoff

Temporal [5]

command sequence

Ours

callsite (σ, π, ω)

no (identity only) no (runtime scope) no (source assumed unchanged) no

yes (static gate)

R EFERENCES

a writable set with a source predicate a committed-effect set revision over a replay capsule

[18] S. B. Davidson and J. Freire, “Provenance and scientific workflows: Challenges and opportunities,” in Proceedings of the ACM SIGMOD International Conference on Management of Data, 2008, pp. 1345–1350. [19] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao, “ReAct: Synergizing reasoning and acting in language models,” in Proceedings of the International Conference on Learning Representations (ICLR), 2023. [20] Q. Wu, G. Bansal, J. Zhang, Y. Wu, B. Li, E. Zhu, L. Jiang, X. Zhang, S. Zhang, J. Liu, A. H. Awadallah, R. W. White, D. Burger, and C. Wang, “AutoGen: Enabling next-gen LLM applications via multiagent conversation,” arXiv preprint arXiv:2308.08155, 2023. [21] LangChain, “LangGraph: Building stateful, multi-actor applications with LLMs,” 2024, documentation, https://python.langchain.com/docs/ langgraph/. [22] J. Zhu, Z. Liu, S. Fan, J. Chen, and Q. He, “From approval to execution: Reconstruction-aware repair analysis for LLM-agent software,” 2026, arXiv:2609.26529v1, 2026-09-22. [23] Y. Lyu, Y. Ren, R. Lai, and W. Liu, “From version conflicts to decision conflicts: Selective revalidation for long-running AI agents,” 2026, arXiv:2609.08015v1, 2026-09-07. [24] G. Wu et al., “Safe to resume? breaking execution continuity of agent execution via rollback,” 2026, arXiv:2608.29381v1, 2026-08-29. [25] L. Geng and E. Y. Chang, “ALAS: Transactional and dynamic multiagent LLM planning,” 2025, arXiv:2511.03094. [26] E. Su et al., “BRIDGE: Selective boundary repair with dependency graph evidence in multi-agent systems,” 2026, arXiv:2610.17805v1, 2026-10-13. [27] A. El Hattami, N. Chapados, and C. Pal, “SKILL.nb: Selective formalization and gated execution for durable agent workflows,” 2026, arXiv:2606.08049v1, 2026-06-06. [28] H. Dhulipala, X. Rong, A. Yadavally, and T. N. Nguyen, “Step-aligned script generation with verification and recovery for web automation testing,” 2026, arXiv:2610.25601v1, 2026-10-19. [29] M. Reichert, S. Rinderle, and P. Dadam, “On the common support of workflow type and instance changes under correctness constraints,” in On the Move to Meaningful Internet Systems 2003: CoopIS, DOA, and ODBASE, ser. Lecture Notes in Computer Science, 2003, pp. 407–425. [30] S. Rinderle, M. Reichert, and P. Dadam, “Correctness criteria for dynamic changes in workflow systems: A survey,” Data & Knowledge Engineering, vol. 50, no. 1, pp. 9–34, 2004. [31] W. Song, X. Ma, and H.-A. Jacobsen, “Instance migration validity for dynamic evolution of data-aware processes,” IEEE Transactions on Software Engineering, vol. 45, no. 8, pp. 782–801, 2019. [32] N. Shinn, F. Cassano, A. Gopinath, K. Narasimhan, and S. Yao, “Reflexion: Language agents with verbal reinforcement learning,” in Advances in Neural Information Processing Systems (NeurIPS), 2023. [33] A. Madaan, N. Tandon, P. Gupta, S. Hallinan, L. Gao, S. Wiegreffe, U. Alon, N. Dziri, S. Prabhumoye, Y. Yang, S. Gupta, B. P. Majumder, K. Hermann, S. Welleck, A. Yazdanbakhsh, and P. Clark, “Self-refine:

[1] S. Khan, “Resume means resume: A machine-checked conformance contract for checkpoint, interrupt, and resume semantics in workflow persistence layers,” 2026, arXiv:2608.03836v3, 2026-08-08. [2] M. Syed and M. C. Silaghi, “Pollard: Governed semantic execution trees for framework-independent AI agent control and replay,” 2026, accepted at IEEE ICTAI 2026; arXiv:2610.16145v1, 2026-10-12. [3] J. Ning, X. Li, Y. Kong, and D. Li, “ControlScope: Workflow revision and reliability in LLM agents,” 2026, arXiv:2609.34313v1, 2026-09-28. [4] L. Maraschi and M. Collina, “State without a landlord: An architecture proposal for peer-to-peer replication of durable workflow state,” 2026, arXiv:2609.17645v1, 2026-09-15. [5] Temporal Technologies, “Workflow determinism and versioning,” n.d., documentation, https://docs.temporal.io/. [6] DBOS, “DBOS transact: Durable execution as a library,” 2025, documentation, https://docs.dbos.dev/. [7] Restate, “Restate: Durable execution for backends and AI agents,” 2025, documentation, https://docs.restate.dev/. [8] Y. Jia and M. Harman, “An analysis and survey of the development of mutation testing,” IEEE Transactions on Software Engineering, vol. 37, no. 5, pp. 649–678, 2011. [9] R. Just, D. Jalali, L. Inozemtseva, M. D. Ernst, R. Holmes, and G. Fraser, “Are mutants a valid substitute for real faults in software testing?” in Proceedings of the ACM SIGSOFT International Symposium on the Foundations of Software Engineering (FSE), 2014, pp. 654–665. [10] Apache Software Foundation, “Apache Airflow documentation,” 2024, documentation, https://airflow.apache.org/docs/. [11] J. Li, “Where does exactly-once live? model, harness, and toolcontract effects on duplicate side effects in LLM agents,” 2026, arXiv:2609.29095v1, 2026-09-24. [12] H. Garcia-Molina and K. Salem, “Sagas,” in Proceedings of the ACM SIGMOD International Conference on Management of Data, 1987, pp. 249–259. [13] K. M. Chandy and L. Lamport, “Distributed snapshots: Determining global states of distributed systems,” ACM Transactions on Computer Systems, vol. 3, no. 1, pp. 63–75, 1985. [14] P. Carbone, G. Fóra, S. Ewen, S. Haridi, and K. Tzoumas, “Lightweight asynchronous snapshots for distributed dataflows,” 2015, arXiv:1506.08603. [15] M. W. Hicks, J. T. Moore, and S. Nettles, “Dynamic software updating,” ACM Transactions on Programming Languages and Systems, vol. 27, no. 6, pp. 1049–1096, 2005. [16] I. Neamtiu, M. Hicks, G. Stoyle, and M. Oriol, “Practical dynamic software updating for C,” in Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), 2006, pp. 72–83. [17] A. Mokhov, N. Mitchell, and S. Peyton Jones, “Build systems à la carte,” in Proceedings of the ACM on Programming Languages (ICFP), vol. 2, no. ICFP, 2018, pp. 1–29.

18

Iterative refinement with self-feedback,” in Advances in Neural Information Processing Systems (NeurIPS), 2023. [34] C. S. Xia, Y. Wei, and L. Zhang, “Automated program repair via conversation: Fixing 162 out of 337 bugs for $0.42 each using ChatGPT,” in Proceedings of the ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), 2024. [35] L. Gazzola, D. Micucci, and L. Mariani, “Automatic software repair: A survey,” IEEE Transactions on Software Engineering, vol. 45, no. 1, pp. 34–67, 2019. [36] Stripe, “Idempotent requests,” 2024, aPI documentation, https://docs. stripe.com/api/idempotent requests.

19

Related documents

• Conflicted Records: Typed Adversarial Contracts for Auditable LLM Output Quality Enforcement#1414274
• Conflicted Records: Typed Adversarial Contracts for Auditable LLM Output Quality Enforcement#1406559
• Keep the dirt: tainted TreeKEM, adaptively and actively secure continuous group key agreement#665979
• PatchWrite: One Line, Not One Section -- Compile-Gated, Validity-Preserving Editing for AI-Drafted Manuscripts#482204
• Long-Horizon State Tracking in LLMs: Executing MD5 through a Deep Sequence of Dependent Tool Calls#819503