{"id":"b326ed37-8e87-48c3-825d-088acfad1885","arxiv_id":"2607.21909","paper_version":1,"verdict":"ACCEPT","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"low","formal_verification":"none","parameter_count":0,"one_line_summary":"Claim Plane deterministically admits versioned change intents and promotes contingent scope just in time, so parallel coding agents can only mutate what they are currently authorized to touch.","lead":"Claim Plane is a coordination layer that makes AI coding agents declare what they plan to change and get permission before writing code, distinguishing definite scope from possible future scope. It could make parallel coding agents safer by enforcing boundaries before edits happen instead of repairing conflicts after the fact.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Safety guarantee depends on broker-complete boundary; acknowledged in §7/§11, but it is the key condition that must hold for the central claim to apply.","rationale":"The reader accepted the paper as a design contribution with moderate confidence, and I agree. The paper's strongest claim is carefully scoped: the safety guarantee in §6.3 is conditional on four assumptions, the most fragile of which is broker completeness. The author explicitly acknowledges this in §7 and §11, so the concern is already on the record and does not invalidate the design. I found no internal contradiction: the admission predicate, promotion invariant, and enforcement path are coherent; the prototype exists; and the six-pair evaluation is explicitly labeled as feasibility only. The weakest point is not a flaw in the argument but a deployment-dependent condition: if tool-call hooks are absent, the control plane cannot enforce pre-write authority, and the system falls back to after-the-fact detection. This is exactly what the reader's weakest_assumption identified. Because the paper is explicit about this boundary, the verdict should remain ACCEPT; no adjustment is needed. The proposed concrete test would demonstrate whether the boundary holds in a realistic no-hook runtime, which is the practical question a user would need answered before relying on the guarantee.","tokens_in":8483,"tokens_out":12223,"duration_ms":132373,"concrete_test":"Run the Claim Plane adapter against a coding runtime with no tool-call hooks (e.g., an agent with unrestricted shell access) on a small set of tasks, and deliberately inject an out-of-band write to a tracked file outside the broker. Then check whether the OS monitor or post-hoc verifier detects the write before integration. If the out-of-band write reaches the final tree undetected, the strong safety guarantee does not hold in that deployment tier; if it is always detected, the boundary holds for that runtime.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central safety proposition (§6.3) is explicitly conditional: assumption (i) requires that all governed repository mutations pass through the broker. §7 and §11 acknowledge that when a runtime lacks tool-call hooks, direct host writes bypass the control plane, and the fail-closed guarantee is correspondingly weaker. This is the load-bearing condition for the paper's strong claim that 'an agent can only mutate what the currently admitted intent version authorizes.' If the boundary is incomplete, Claim Plane degrades into a post-hoc diff-verification/auditing layer, which cannot prevent interference before it happens. The paper is honest about this scoping, so it is not an internal inconsistency; however, every real deployment must either provide a non-bypassable broker/OS-monitor boundary or accept a materially weaker guarantee. The proof sketch also abstracts over region containment and capability revalidation, so the actual enforcement code is the only thing standing between the stated invariant and reality. This makes broker completeness the single most load-bearing risk, not because the paper ignores it, but because the central contribution's force depends on it.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes Claim Plane, a coordination architecture for parallel coding agents that treats mutation authority as a pre-write admission problem. It introduces versioned ChangeIntents that split committed from contingent scope, a deterministic admission engine, a Dynamic Scope mechanism that promotes contingent mutations via atomic re-admission, and an enforcement stack consisting of a broker, leases, OS-level locks, fencing tokens, and Git-tree provenance. A safety proposition is stated under four explicit assumptions. A six-pair CooperBench experiment is reported as a mechanism check only: the static arm serializes all pairs and passes all, the dynamic arm activates promotions and fail-closed blocks, and the sample is intentionally too small for comparative conclusions.","tokens_in":8736,"tokens_out":7623,"duration_ms":82338,"significance":"If the architecture holds under its assumptions, it offers a credible way to separate probabilistic planning from deterministic authority, and the committed/contingent split with just-in-time promotion is a distinctive and useful concept. The paper is transparent about limitations, pre-specifies a larger confirmatory study, and releases open-source code. Its current value is primarily conceptual and mechanistic rather than empirical.","major_comments":[{"comment":"The safety proposition in §6.3 lists assumptions (i)–(iv) but does not include an assumption that the resource-coverage predicate Covers(O_c, m) is sound for symbolic, contract, and concept resources. For file/region resources coverage can be exact, but for symbol- or contract-level claims the broker must rely on semantic analysis; §11 acknowledges that high-quality semantic analysis is not yet available beyond Python-first typed extraction. If the broker mis-resolves a mutation, a mutation outside the true declared scope could be accepted, directly violating the proposition. The paper should either add an explicit assumption (v) on resource-resolution soundness or define 'committed authority' relative to the broker's resolved mapping and state that the guarantee holds only up to that mapping. Without this, the 'deterministic authority' claim is formally over-broad.","section":"§6.3, §3.1, §4.2"},{"comment":"Broker completeness is the load-bearing boundary condition for the central safety claim. The paper acknowledges this in §7 and §11, but the abstract and contribution list present the pre-write admission guarantee without that qualification. Since a runtime without tool-call hooks degrades Claim Plane to post-hoc diff verification, the boundary requirement should be stated in the abstract or in the first contribution so readers do not over-read the safety claim. This is not an internal inconsistency, but the user-facing claim currently exceeds the proven scope.","section":"§6.3, §7, §11"}],"minor_comments":[{"comment":"References [10] and [11] are listed but do not appear to be cited in the body text; either cite them or remove them.","section":"References"},{"comment":"The column heading 'Initial serialization' is ambiguous. Clarify whether this refers to pairs fully serialized at admission, pairs that required at least one serialization decision, or another interpretation.","section":"Table 1"},{"comment":"The text states there were 'no rejected promotions' but also reports two trajectories stopped by fail-closed undeclared-scope blocks. Clarify whether these blocks correspond to promotion rejections or to mutation attempts outside any declared scope; if the latter, the distinction should be explicit so the reader does not confuse the two fail-closed outcomes.","section":"§8.2"}],"recommendation":"major_revision","confidential_remarks":"The paper is a reasonable design/architecture contribution, but the unstated soundness assumption for non-file resource coverage is the main formal gap. Once that assumption is made explicit and the abstract is qualified with the broker-completeness boundary, the paper could be acceptable as a systems-design contribution. The six-pair experiment is honestly scoped and should not be used for comparative claims."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"I've read the Claim Plane preprint. Short version: it's a legitimate design paper with one genuinely new mechanism, and it's refreshingly honest about what it does and doesn't show. The committed/contingent split with atomic just-in-time promotion is real—I don't see it in ATM or the other cited work, and the paper correctly disclaims priority on the broader pre-write admission idea. The deterministic control plane, leases, fencing, and immutable integration evidence are all coherent and the prototype is public.\n\nThe evaluation is six pairs, one seed, with oracle-localized context, and the paper says plainly this is a mechanism check, not an effect estimate. Good. The planned 30-pair frozen-plan study is reasonable. The proof sketch is informal but the safety proposition is explicitly conditional on four assumptions, so the logic is clear.\n\nThe soft spot is the one the stress test flagged: the whole guarantee depends on all governed mutations passing through the broker. The paper acknowledges this in §7 and §11—if a runtime lacks tool-call hooks, you're back to diff verification and post-hoc auditing. That's not a hidden flaw, but it is the load-bearing boundary. Every real deployment has to decide whether that boundary holds. I'd have liked a sharper threat model: what counts as a governed mutation, how you detect bypass channels, and what the degradation path actually looks like. But the paper doesn't pretend the guarantee applies when the boundary is absent.\n\nThe other thing I'd note is that the safety proof abstracts over region containment and capability revalidation. The actual enforcement code is what has to carry the invariant. That's typical for systems papers, but it means a referee should ask for the tests around the promotion path, not just the architecture.\n\nWho's this for? People building coordination layers for coding agents. It's a useful reference point, and the related-work table is honest about where it sits. I wouldn't cite the six-pair numbers as evidence of anything except that the mechanism fires, which is exactly how the paper frames it.\n\nMy take: this should go to peer review. It's a solid design paper with a real contribution, and the authors know where the limits are.","headline":"A solid, honest design paper whose new mechanism is dynamic scope promotion; the main caveat is the acknowledged broker-completeness boundary.","tokens_in":9163,"tokens_out":2127,"would_cite":true,"duration_ms":23286,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"By separating probabilistic planning from deterministic authority, Claim Plane gives parallel coding agents an enforceable, fail-closed authorization boundary for every repository mutation.","keywords":["coding agents","multi-agent software engineering","concurrency control","pre-write admission","deterministic enforcement","dynamic scope","change intent","fail-closed coordination"],"falsifier":"Run a pair of agents whose runtimes do not expose tool-call hooks, with one agent holding an intent that does not cover a second agent's target file. If the second agent modifies that file and the broker either does not observe it or reports no block, the boundary assumption fails. More directly: trigger two agents with overlapping contingent declarations to promote the same region simultaneously; if both receive write authority, the atomic promotion invariant is false.","tokens_in":8394,"feed_emoji":"🛡️","tokens_out":3944,"duration_ms":39925,"temperature":0.7,"pith_summary":"The paper argues that concurrent software change by coding agents should be governed before writes happen, not repaired after. It introduces a deterministic control plane that admits versioned ChangeIntents—declarations of committed and contingent scope—so a worker may only mutate what the currently admitted intent authorizes; uncertain future edits are promoted just in time through atomic re-admission. If this works, parallel agents can share a repository without speculative scope expansion or dependency invalidation silently corrupting integration, with every governed mutation attributable to a lease, fencing token, and Git-tree chain. The paper reports a deliberately small six-pair mechanism check as feasibility evidence, not as a comparative result.","feed_headline":"Control plane admits every agent edit before it happens","feed_subtitle":"Parallel coding agents get a fail-closed authority layer: unapproved mutations are blocked, so integration stops depending on luck.","key_machinery":"The load-bearing object is the versioned ChangeIntent with its committed/contingent split, together with the atomic admission and promotion transaction (the Admit predicate and the Promote step). Committed operations define current write authority; contingent operations are read-only projections for coordination. The runtime rule—execute a mutation only if committed scope covers it, or if a contingent covering operation is promoted and re-admitted atomically—is the invariant that lets failed speculation fail closed. Enforcement uses three layered protections: a single writer lease, an OS-level worktree lock, and a monotonic fencing token, plus a Git-tree chain that verifies the expected pre-","core_discovery":"The central discovery is the conceptual separation of probabilistic intent from deterministic authority, implemented as a pre-write admission protocol. A ChangeIntent binds an agent's planned operations to an exact base commit and splits them into committed operations (which participate in admission now) and contingent operations (which express possible future scope but reserve no write ownership). When an agent first attempts to touch a contingent surface, the control plane atomically promotes the concrete path or region, re-runs admission against the current active intent set, and only then grants authority. Alongside admission, the architecture layers brokered execution, capability revali","pith_inferences":["The committed/contingent split is a general coordination primitive: it could model other probabilistic planners that must commit to resource ownership early, such as parallel build systems or database migration tools.","The dependency-invalidation design suggests a testable hypothesis: systems that surface stale dependencies as first-class events will produce fewer integration failures than systems that rely on late merge conflicts, independent of the specific LLM used.","The paper's data flywheel is a latent contribution: every governed run produces labeled traces (parallel success, serialization rescue, scope block) that could train the semantic-dependency model it proposes, making label collection a by-product of use.","For non-Linux runtimes without broker-complete isolation, the guarantee degrades; a practical extension would be an OS-monitoring fallback that intercepts file operations at the system-call level, preserving fail-closed property for agents that lack native tool-call hooks."],"forward_implications":["Parallel coding agents can share one worktree without first merging: each mutation is checked against admitted authority before it lands, so unsafe combinations are denied rather than detected late.","Planners can declare broad contingent scope without paying serialization costs; only the resource that actually becomes necessary is promoted, preserving initial parallelism.","Dependency invalidation propagates staleness transitively, so work built on a changed premise is explicitly flagged and re-admitted rather than silently integrated.","Integration becomes verifiable from immutable snapshots, closing time-of-check/time-of-use gaps between verification and applying patches.","The architecture provides a concrete layered path where deterministic rules handle provable cases, a learned semantic-dependency model handles predictable cases, and frontier intelligence is consulted only for unresolved edge cases."],"fun_headline_variants":["Claim Plane: every agent edit gets pre-write approval","Fail-closed authority: unapproved agent edits blocked","Admission control: serializes overlapping agent changes","Pre-write gate: dynamic scope promoted atomically","Deterministic control plane vets each agent intent"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The guarantee only holds if every governed repository mutation actually passes through the broker; if a coding agent can write files directly, outside the control plane's observable boundary, the fail-closed property does not apply.","fun_headline_variants_meta":{"raw":{"variants":["Claim Plane: every agent edit gets pre-write approval","Fail-closed authority: unapproved agent edits blocked","Admission control: serializes overlapping agent changes","Pre-write gate: dynamic scope promoted atomically","Deterministic control plane vets each agent intent"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000267,"raw_usage":{"total_tokens":1477,"prompt_tokens":795,"completion_tokens":682,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":539,"completion_tokens_details":{"reasoning_tokens":606}},"tokens_in":539,"tokens_out":682,"duration_ms":7755,"temperature":1.0,"reasoning_tokens":606,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-01T06:22:51.845091+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a pair of agents whose runtimes do not expose tool-call hooks, with one agent holding an intent that does not cover a second agent's target file. If the second agent modifies that file and the broker either does not observe it or reports no block, the boundary assumption fails. More directly: trigger two agents with overlapping contingent declarations to promote the same region simultaneously; if both receive write authority, the atomic promotion invariant is false.","supporting_citations":[],"review_version":1}