{"id":"859c810f-b122-4967-b623-0ade4e6d99af","arxiv_id":"2605.28097","paper_version":1,"verdict":"UNVERDICTED","confidence":"LOW","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"ICAN-Deploy maintains cryptographic identity invariant across canary windows for embodied agents via name-version separation, verified by proof, lint, TLA+ checking, and 100 robot trials showing zero drift.","lead":"ICAN-Deploy is a middleware construction that keeps an embodied agent's cryptographic identity hash fixed during canary deployments by separating frozen capability names from mutable versions. This lets safety-certified robots receive capability updates without triggering re-certification each time.","discovery_kind":"new_method","skeptic_critique":{"model":"grok-4.3","headline":"Identity invariance via name freezing does not entail that evolved versions preserve the originally certified safety properties","rationale":"The reader's weakest assumption is precisely the load-bearing gap: the construction secures name-based identity but provides no evidence that safety properties survive version mutation. Because the full text was not supplied here, the concern remains at the level already flagged by the reader; no stronger internal inconsistency is visible from the abstract alone.","tokens_in":1716,"tokens_out":329,"duration_ms":20543,"concrete_test":"Inspect the TLA+ specification (and the closed-form proof) to check whether it encodes the agent's safety properties (e.g., collision avoidance, torque limits) or only the identity-state-machine transitions; if the former are absent, re-run the N=100 MuJoCo trials with a version change that alters a certified safety behavior while keeping the name fixed and measure whether the original certification still holds.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that a once-certified identity (hash over frozen capability names) can host arbitrary version evolution while the certification remains valid. The paper's verifications (closed-form proof, AST lint, TLA+ model-checking) establish only that the identity hash stays constant across the canary window. They do not establish that the safety properties certified for the initial name+version pair continue to hold after the version mutates. In embodied agents, capability versions can alter control loops, sensor fusion, or failure modes even when the public name is unchanged; nothing in the described construction prevents such drift from violating the certified invariants.","agreement_with_reader":"agree"},"referee_report":{"model":"grok-4.3","summary":"The paper introduces ICAN-Deploy, a middleware construction for canary deployment in safety-critical embodied agents. It separates frozen capability names (used to compute a stable identity hash) from mutable capability versions, ensuring the cryptographic identity remains invariant across canary windows. This is claimed to allow one-time certification at identity creation to cover arbitrary subsequent version evolution within the name-and-version envelope. The construction is implemented in a runtime governance layer for LLM-driven robots and verified via closed-form proof, AST linting, TLA+ model checking, and N=100 real-robot canary cycles on a Franka Panda arm in MuJoCo (zero identity drift reported, with entry latency 95% BCa CI [1.52, 2.01] ms). A strawman that folds versions into the manifest is said to falsify on the same workload.","tokens_in":1844,"tokens_out":627,"duration_ms":25008,"significance":"If the result holds, the work would be significant for safety-critical robotics and embodied AI, where re-certification per deployment change is costly. The use of multiple independent verification methods (closed-form proof, AST lint, TLA+ model checking) plus real-robot trials with zero observed drift provides stronger evidence than typical deployment papers; the reproducible experimental setup and parameter-free identity construction are particular strengths.","major_comments":[{"comment":"Abstract: The central claim that 'a system certified once at identity-creation time can then ship arbitrary capability evolution under that same certification' is not supported by the described verifications. The closed-form proof, AST lint, and TLA+ model checking establish only that the identity hash (computed over frozen names) remains constant; they do not establish that safety properties or control invariants certified for the initial name+version pair continue to hold after version mutation. In embodied agents, version changes can alter control loops or failure modes even with unchanged public names. This mismatch is load-bearing for the final sentence of the abstract.","section":"Abstract"},{"comment":"Robot trials (N=100): The experiments report zero drift and a latency CI, but provide no description of the safety properties or behavioral invariants that were monitored during version changes. Without explicit checks that evolved versions preserve the originally certified properties (rather than only the hash), the trials corroborate only identity stability, not the broader certification claim.","section":"Robot trials description"}],"minor_comments":[{"comment":"The strawman comparison is mentioned but not quantified (no metrics, failure rates, or statistical comparison provided), weakening the claim that the feature-flagged strawman 'falsifies on the same workload.'","section":"Abstract"},{"comment":"Notation for the identity hash computation and the precise definition of the 'version-and-name envelope' should be introduced earlier with an equation or pseudocode to make the separation between names and versions fully precise.","section":null}],"recommendation":"major_revision","confidential_remarks":null},"author_rebuttal":{"model":"grok-4.3","summary":"We appreciate the referee's insightful comments on the distinction between identity stability and preservation of safety properties. Below we address each major comment.","responses":[{"response":"We thank the referee for highlighting this important distinction. Our verifications indeed establish only that the cryptographic identity remains invariant across canary windows. The abstract's claim is intended to convey that, by preserving the identity, a one-time certification of the identity can apply to subsequent deployments without re-certifying the identity itself. However, we agree that this does not imply automatic preservation of specific safety properties or control invariants, which may change with version updates. We will revise the abstract to more precisely articulate that the contribution enables identity-stable deployment, with the understanding that behavioral safety within the version envelope requires separate assurance. This revision will be made in the next version of the manuscript.","revision_made":"yes","referee_comment":"[Abstract] Abstract: The central claim that 'a system certified once at identity-creation time can then ship arbitrary capability evolution under that same certification' is not supported by the described verifications. The closed-form proof, AST lint, and TLA+ model checking establish only that the identity hash (computed over frozen names) remains constant; they do not establish that safety properties or control invariants certified for the initial name+version pair continue to hold after version mutation. In embodied agents, version changes can alter control loops or failure modes even with unchanged public names. This mismatch is load-bearing for the final sentence of the abstract."},{"response":"The N=100 robot trials were conducted to empirically validate the absence of identity drift in a real embodied setting, complementing the formal verifications. The primary metric was identity hash stability, with secondary measurement of entry latency. We did not include explicit monitoring of safety properties or behavioral invariants in the reported experiments, as the focus was on the novel identity mechanism. We acknowledge that describing any additional monitored metrics, such as task completion rates or stability measures during the canary cycles, would provide useful context. We will add a brief description of the experimental setup's behavioral monitoring in the revised manuscript to clarify the scope of the trials.","revision_made":"partial","referee_comment":"[Robot trials description] Robot trials (N=100): The experiments report zero drift and a latency CI, but provide no description of the safety properties or behavioral invariants that were monitored during version changes. Without explicit checks that evolved versions preserve the originally certified properties (rather than only the hash), the trials corroborate only identity stability, not the broader certification claim."}],"tokens_in":1529,"tokens_out":546,"duration_ms":47620,"standing_objections":[]},"desk_editor":{"model":"grok-4.3","letter":"The main thing to know is that the paper builds a middleware construction for LLM-driven embodied agents that separates frozen capability names from mutable versions so the cryptographic identity hash stays constant across canary windows. This is presented as a way to avoid re-certification when shipping updates.\n\nThey implement it in a runtime governance layer and verify the invariance with a closed-form proof, AST lint, TLA+ model checking, plus N=100 canary cycles on a Franka Panda arm in MuJoCo. The trials report zero identity drift and entry latency in the low milliseconds. A strawman that folds versions into the manifest fails on the same setup. The name-version split is a concrete systems technique that fits the embodied-agent setting and is not just a rehash of standard canary controllers.\n\nThe formal and empirical pieces are straightforward to inspect and give the identity claim a reasonable foundation. The TLA+ work and the real-robot corroboration are the parts that stand out as reproducible.\n\nThe softer spot is the connection to certification. The checks establish that the hash does not change, but they do not test whether the safety properties certified for the initial version continue to hold once the version mutates. In robots, a version change can affect control loops or failure modes even when the public name stays the same. The paper treats the name envelope as sufficient to carry the certification forward, yet the evidence shown is limited to identity invariance rather than safety invariance.\n\nThis is for researchers working on deployment and certification of autonomous systems. Anyone already using formal methods for runtime governance would find the TLA+ and trial details useful. It has enough grounded verification to merit sending out for peer review.","headline":"ICAN-Deploy keeps the identity hash fixed during canary updates for robots by freezing capability names while versions mutate, with TLA+ checks and 100 trials showing zero drift, but the verifications stop at identity stability and do not directly confirm preserved safety properties.","tokens_in":2322,"tokens_out":437,"would_cite":false,"duration_ms":23672,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"grok-4.3","headline":"ICAN-Deploy keeps the cryptographic identity of safety-critical agents fixed during canary deployments.","keywords":["canary deployment","identity stability","embodied agents","safety certification","middleware","robot governance","capability versioning"],"falsifier":"A workload in which version changes alone, without name changes, produce measurable deviation from the originally certified safety properties.","tokens_in":2616,"feed_emoji":"🤖","tokens_out":600,"duration_ms":23795,"temperature":0.7,"pith_summary":"The paper shows that standard canary deployment controllers alter an agent's cryptographic identity when routing traffic to new versions, which invalidates prior safety certifications for embodied systems such as robots. ICAN-Deploy counters this by enforcing an invariant on the identity hash throughout the canary window. It achieves the invariant through a state machine that treats capability names as frozen and hashed while treating versions as mutable runtime state. If the construction holds, a single certification performed at identity creation covers all subsequent capability updates that stay inside the name-and-version envelope. The authors implement the approach inside a runtime governance layer, confirm the invariant via proof and model checking, and measure zero identity drift across one hundred canary cycles on a simulated robot arm.","feed_headline":"Canary updates keep robot identity fixed without re-certification","feed_subtitle":"Separating frozen names from mutable versions lets a certified embodied agent evolve under one certification.","key_machinery":"ICAN-Deploy state machine that maintains identity hash invariance by separating frozen capability names from mutable versions","core_discovery":"ICAN-Deploy is a middleware construction whose state machine holds the identity hash invariant across the canary window by separating capability names (frozen, hashed) from capability versions (mutable runtime state). A system certified once at identity-creation time can then ship arbitrary capability evolution under that same certification, within the version-and-name envelope.","pith_inferences":["The name-version separation could be applied to deployment patterns other than canary routing.","The approach might lower the recurring cost of certifying continuously updated embodied agents.","Hardware-in-the-loop tests without simulation would provide a direct check on the invariance claim."],"forward_implications":["One initial certification covers all future updates that remain inside the name-and-version envelope.","Re-certification is not required for each canary phase.","The same certified identity applies to LLM-driven robots under runtime governance.","Closed-form proof, AST linting, and TLA+ model checking together establish the invariance.","Real canary cycles on a Franka Panda arm show zero identity drift and sub-2 ms entry latency."],"fun_headline_variants":["ICAN-Deploy keeps robot identity fixed in canary windows","Separate frozen names from mutable versions for identity stability","Identity-stable canary deployment avoids re-certification for agents","Middleware holds identity hash invariant across robot canaries"],"cache_read_input_tokens":2112,"weakest_assumption_plain":"Freezing capability names while allowing version changes preserves the functional behavior and safety properties that were originally certified.","fun_headline_variants_meta":{"raw":{"variants":["ICAN-Deploy keeps robot identity fixed in canary windows","Separate frozen names from mutable versions for identity stability","Identity-stable canary deployment avoids re-certification for agents","Middleware holds identity hash invariant across robot canaries"]},"model":"grok-4.3","cost_usd":0.003325,"raw_usage":{"total_tokens":1772,"prompt_tokens":669,"num_sources_used":0,"completion_tokens":62,"cost_in_usd_ticks":33249500,"prompt_tokens_details":{"text_tokens":669,"audio_tokens":0,"image_tokens":0,"cached_tokens":256},"completion_tokens_details":{"audio_tokens":0,"reasoning_tokens":1041,"accepted_prediction_tokens":0,"rejected_prediction_tokens":0}},"tokens_in":669,"tokens_out":62,"duration_ms":10865,"temperature":1.0,"reasoning_tokens":1041,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-06-29T12:05:18.509130+00:00","model_set":{"reader":"grok-4.3"},"falsifier":"A workload in which version changes alone, without name changes, produce measurable deviation from the originally certified safety properties.","supporting_citations":[],"review_version":1}