{"id":"7fa064a5-04cd-4e47-b07b-98348621fbcb","arxiv_id":"2608.11632","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"A deterministic activation contract called the Continuity Kernel records one of four decisions (Commit, Reject, Quarantine, Defer) inside an atomic transaction, and only Commit advances an agent's authoritative branch head.","lead":"This paper proposes a software \"Continuity Kernel\" that decides which version of a long-lived AI agent's state is the true authoritative version, using a short transactional check that only allows clean, authorized updates. It aims to stop stale overwrites, un-audited data exposure, and self-granted privilege escalation in persistent agents.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"A4 is the linchpin and the bounded model assumes it; absent a storage-level realization the conditional safety claims remain unvalidated.","rationale":"I agree with the reader that A4 is the weakest load-bearing premise. The paper's own Section 5.3 admits the model treats atomic activation as a single logical state step; therefore the bounded-model result cannot establish that A4 holds on a real storage substrate. This is a scoping gap, not an internal inconsistency: the safety propositions are explicitly conditional, and Section 3.5 identifies the need for coupled protocols when atomic ordering cannot be shared. My proposed test distinguishes between 'the protocol logic is sound given atomicity' and 'A4 is satisfiable'. If the non-atomic decomposition creates invariant violations, then the zero-violation result only confirms the former, and the practical applicability of the central claim remains unverified. If the decomposition still yields no violations, the model is more robust than the text suggests. Either way, the appropriate verdict remains CONDITIONAL: the activation contract is plausible, carefully scoped, and transparent about its limits, but the linchpin atomic-serialization assumption is not demonstrated by the accessible evidence, and the artifact was not available for independent verification.","tokens_in":19222,"tokens_out":10324,"duration_ms":120175,"concrete_test":"Modify the provided bounded_model.py so that a Commit transition is split into two non-atomic substeps (e.g., install branch row/head, then install effect/outcome/context rows) with an explicit crash or abort allowed between them, while keeping all other activation guards unchanged. Re-run the depth-7 BFS; if any reachable state violates Exact Succession (at-most-one accepted successor per complete head) or At-most-once effect binding, then the published zero-violation result depends on A4 being hard-coded as one atomic step and does not validate the storage-level assumption.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's safety claims are conditional on A1-A9, and A4 (Appendix D.2) is the load-bearing one: the complete accepted unit, lifecycle changes, and reclamation changes must serialize over every named mutable key and be durably all-or-none. Proposition 2 (Section 3.4) reduces to this: two contenders for one predecessor both pass ExpectedHead only if the substrate lets them both read the same branch head, and the first Commit changes the serialization point atomically. If the substrate can commit only a subset of the named rows (e.g., branch row but not effect/outcome rows, or directory and branch storage with independent orders), Propositions 2 and 3 fail: two commits could install from one head, or an effect identifier could be bound twice. Section 5.3 concedes that WAL crashes, partitions, and storage-engine bugs fall outside the model, and Section 3.5 concedes that polling cannot establish writer isolation when directory and branch storage cannot share atomic ordering. The executable model does not test A4: its transitions are defined as single logical state steps, so the BFS zero-violation result is consistent with a substrate that violates A4. The paper is honest that this is conditional, but it never maps 'every named mutable key' to concrete storage primitives, so a reader cannot check whether the linchpin assumption is satisfiable.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes that authoritative state for long-lived AI agents is an infrastructural activation problem rather than a storage-retention problem, and introduces the Continuity Kernel (CK), a two-phase activation contract. Models, tools, and operators prepare typed candidate proposals off-commit; a short deterministic activation transaction revalidates ownership, exact predecessor head or typed absence, pre-state authority, freshness, and effect uniqueness, then records one of four terminal dispositions (Commit, Reject, Quarantine, Defer). Only Commit atomically installs the complete accepted unit and advances the branch head. The paper states three conditional safety properties (owner-bound stable outcomes, single exact continuation, and at-most-once accepted effects), proves them by short serialization arguments under explicit assumptions A1–A9, and evaluates the protocol with a bounded Python BFS model over 2,808,230 reachable states and 5,526,474 state-changing transitions, reporting zero invariant violations. The authors are explicit that the guarantees are conditional on storage-level atomic serialization and do not extend to physical storage crashes, partitions, or unbounded correctness.","tokens_in":19496,"tokens_out":4389,"duration_ms":51863,"significance":"If the conditional contract is taken at face value, the paper makes a useful and timely conceptual contribution: it separates candidate evaluation from state activation, makes the authority boundary explicit, and provides a clean target for implementations layered on standard transaction substrates. The strengths are the explicit assumption ledger A1–A9, the short checkable serialization proofs in Appendix B, the bounded executable artifact that ships with the paper, and an unusually honest calibration of what the model does and does not establish (Section 5.3). The paper does not claim semantic correctness of policies, and it explicitly disclaims external side-effect atomicity. The main weakness is that the central storage assumption A4 is stated abstractly and never mapped to a concrete key set or storage primitive, so the reader cannot check whether the linchpin of the safety claims is satisfiable in any real substrate.","major_comments":[{"comment":"Assumption A4 is load-bearing for Propositions 1–3, but the paper never specifies the concrete set of 'named mutable keys' or the storage-level primitive that serializes them atomically. The examples in Section 3.5—a relational database locking branch and named context rows, an object store conditionally installing one commit manifest, a replicated service serializing one command—are not checkable as stated. Please provide an exact key inventory for the accepted unit in Eq. (9): branch row B[k], authority context Γ′, effect records E[eid], outcome O[pid], receipt R[drC], and the handoff/directory records for lifecycle actions. For at least one concrete substrate, show the precise conditional-update predicate, unique-insert mechanism, or row-lock ordering that makes the complete unit all-or-none and gives every named key a single serialization order. Without this, a reader cannot determine whether A4 is satisfiable, and the safety properties collapse if it is not.","section":"Appendix D.2 (A4) and Section 3.5"},{"comment":"The bounded model represents preparation and activation as single logical state steps, so the BFS result cannot detect partial commits, lock failures, or reorderings that violate A4. The zero-violation outcome is therefore consistent with a substrate that commits only a subset of the named rows. The paper acknowledges this in Section 5.3, but the abstract and Section 5.1 still say the model 'verifies' the protocol. Please restate the verification claim as 'verifies the protocol logic under A4', and either add an explicit model invariant at the storage-interface boundary that checks atomicity and ordering of the accepted unit, or state clearly that such an invariant is outside the model. The reader should be able to see exactly what the 2,808,230-state result does and does not cover.","section":"Section 5.1 and Section 5.3"}],"minor_comments":[{"comment":"The depth-6 timing includes generating depth-7 states while the depth-7 timing includes only terminal validation, so a direct column-wise comparison of per-depth timings is misleading; please make the measurement boundary explicit in the table caption or in the text immediately preceding Table 6.","section":"Table 6"},{"comment":"The artifact is referenced by path only (artifacts/bounded_model.py). For archival reproducibility, please either include the invariant list and the SHA-256 digest in the paper itself or state the permanent public location of the artifact.","section":"Appendix D.3"}],"recommendation":"major_revision","confidential_remarks":"The paper's conditional framing is a genuine strength, and I do not see an internal inconsistency in the serialization arguments. My recommendation of major revision is driven by the need to close the gap between the abstract A4 assumption and a concrete, checkable storage realization, and to calibrate the model-verification language accordingly. If the authors provide the A4 key inventory and an explicit single-substrate example, I would expect the paper to be acceptable."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nRead this if you're working on agent memory or state infrastructure. The paper delivers a precise activation contract—17-stage check order, four terminal dispositions, receipts with four evidence levels, lifecycle rules for handoff, fencing, and restoration—that separates off-commit candidate preparation from atomic activation. That separation is the real contribution: it gives long-lived agents an auditable boundary between stored state and authoritative state. The assembly isn't radically new—OCC, RIFL-style retries, writer fencing, provenance receipts—but the combination, and the level of normative detail, is. The appendices are unusually careful: closed stage–reason maps, typed construction dependencies, explicit postconditions, a deterministic canonicalization profile.\n\nThe proofs are short serialization arguments, and they work under A1–A9. A4 is the load-bearing one: the complete accepted unit plus lifecycle and reclamation changes must serialize over every named mutable key and be durably all-or-none. The paper is honest about this. It says in Section 3.5 that if directory and branch storage can't share atomic ordering, polling alone won't establish writer isolation, and in Section 5.3 it concedes WAL crashes, partitions, and storage-engine bugs fall outside the model. The bounded model (depth 7, 2.8M states, zero violations) is a finite consistency check, not an unbounded proof, and the paper says so. So the conditional safety claims are properly scoped.\n\nThe soft spot is not a hidden flaw—it's that the linchpin is stated as an assumption, not tested or realized. The paper never maps 'every named mutable key' to concrete storage primitives, so a reader can't check whether A4 is satisfiable in, say, PostgreSQL or FoundationDB. The accompanying artifact is mentioned but wasn't accessible in the submission; that's a practical issue for verification, not an intellectual one. There's also a self-citation to the PCI framework, but it's used as context, not as a load-bearing reference.\n\nWho this is for: anyone building agent memory or state infrastructure who wants a rigorous contract to implement against. It deserves a serious referee. The main things a referee should push on are A4's realizability and whether the 17-stage predicate is implementable at acceptable latency.\n\nRecommendation: send to peer review. It's a well-defined design with explicit limits, not an overclaiming system paper.","headline":"A well-scoped systems-design contract whose safety claims are honestly conditional on the load-bearing A4 assumption; worth refereeing, but don't expect a storage-level verification.","tokens_in":19981,"tokens_out":2613,"would_cite":true,"duration_ms":27019,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper argues that storage retention alone cannot identify authoritative agent state, and proposes the Continuity Kernel, an activation contract in which only a short atomic transaction may advance a branch head.","keywords":["AI agent memory","state activation","authoritative branch head","activation contract","transactional continuity","pre-state authorization","at-most-once effects","bounded model checking"],"falsifier":"Run two conflicting activation attempts that name the same exact predecessor head against a storage substrate that commits the branch row and the named context rows in separate non-atomic operations; observing two durable Commit receipts with the same predecessor would violate Proposition 2 and show A4 is doing the work.","tokens_in":19034,"feed_emoji":"🧠","tokens_out":5478,"duration_ms":54274,"temperature":0.7,"pith_summary":"Persistent AI agents keep accumulating versioned memory, profiles, plans, and policies, but merely storing those versions does not say which one is authoritative. The paper's central claim is that agent-state governance is an infrastructural activation problem: authority should be created only by a deterministic, atomic transition that advances a branch head from an exact predecessor. To that end it introduces the Continuity Kernel (CK), an activation contract that lets untrusted models, tools, and operators prepare candidate states off-commit, then revalidates ownership, pre-state authority, freshness, and effect uniqueness inside one short serialized transaction. A sympathetic reader would care because, if this holds, long-lived agents can get an unbroken, authorized lineage of accepted heads without trusting the components that propose changes, and stale overwrites and self-authorizing privilege escalation become protocol violations rather than accidents.","feed_headline":"State authority is a transaction, not a memory","feed_subtitle":"The Continuity Kernel makes one atomic activation decide which candidate becomes the authoritative agent state.","key_machinery":"The load-bearing object is the activation contract itself: a signed proposal $\\tau$ targeting an exact predecessor head or typed absence, a sealed candidate derived off-commit, and one short transaction that evaluates the ordered predicate vector $G^{\\mathrm{kind}}(C,P) = \\langle G^{\\mathrm{kind}}_a(C,P) \\rangle_{a \\in \\mathrm{ActCheck}}$ stage by stage. The contract binds proposal identity, evidence, pre-state authority context $\\Gamma$, lifecycle status, effect manifest, lineage, and receipt into a single all-or-nothing accepted unit $U^{\\mathrm{accept}}$. Its work is to make the moment of authority a linearizable point: after the first Commit, every competing proposal fails exact-head or absence admission, so the sealed candidate — not a later re-derivation — is what becomes authoritative.","core_discovery":"CK's core discovery is that safety for long-lived agent state can be reduced to a small set of conditional serialization guarantees. The protocol evaluates an ordered 17-stage activation predicate against the current branch row and every named mutable key; only an all-Pass vector yields Commit. Commit atomically installs the complete accepted unit — candidate state, updated authority context, finalized branch head, lineage edge, outcome record, and receipt — while Reject, Quarantine, and Defer leave authoritative state untouched. On a bounded model with 2,808,230 reachable states and 5,526,474 state-changing transitions, exploration found zero invariant violations and reached 100% of named coverage witnesses. The safety properties are exact succession (at most one commit per complete predecessor or serialized absence), pre-state authorization, stable execution identity, and lifecycle isolation, all conditional on assumptions A1–A9.","pith_inferences":["The contract is substrate-agnostic by design; a concrete testable extension would be to implement the same activation predicate as a single stored procedure over a relational engine that supports conditional multi-row updates and measure whether the 17 stages preserve the stated at-most-once guarantees under real crashes.","The bounded-model result is evidence of logical consistency within depth seven, not unbounded correctness; one could extend the exploration to depth eight or add a storage-engine fault model to see whether missing atomic ordering produces the first violation.","If CK were composed with an idempotent outbox for external actions, the combination would amount to end-to-end 'effect once' semantics across internal state and remote side effects, a guarantee the paper explicitly does not claim.","The exact-predecessor discipline suggests a direct test for memory systems: record whether every accepted memory write names the head it was derived from; systems that allow blind writes would be expected to exhibit stale-overwrite failures that CK's contract rules out."],"forward_implications":["If CK is right, no number of stored versions or high retrieval scores makes a state authoritative; only reachability from the committed branch head does.","Two concurrent proposals claiming the same complete predecessor cannot both commit; exactly one sealed candidate becomes the successor, and the other receives a stable terminal disposition.","Retrying a proposal with the same identifier cannot double-execute effects: the kernel returns the previously recorded outcome, and reclaimed identifiers are retired by a monotone watermark.","Writer handoff becomes a typed, directory-serialized state machine in which the source is fenced before a target can activate, so a crash cannot expose two active writers.","Schema migration and checkpoint restoration are always forward transitions from the current head, never rewrites of accepted history, so lineage remains acyclic."],"supporting_citations":[{"why":"Supplies the commit-time revalidation paradigm: read assumptions are checked at commit, which CK extends to exact-head and typed-absence admission.","marker":"[10]"},{"why":"Provides the standard atomic-transaction substrate that CK's activation step assumes for durably installing the accepted unit.","marker":"[11]"},{"why":"Contributes replicated consensus and term fencing, the model for stale-writer exclusion CK adapts to writer handoff.","marker":"[12]"},{"why":"Supplies unique request identifiers, atomic completion records, and safe reclamation, which CK composes into stable proposal and effect identity.","marker":"[13]"},{"why":"Provides the notion of commit-time authorization for LLM agents that CK places inside a persistent state transition.","marker":"[14]"},{"why":"Is the closest agent-memory transaction system, staging evidence-bearing beliefs under a snapshot; CK positions its typed branch-head activation relative to it.","marker":"[8]"},{"why":"Contributes staged effects, delegated authorization, compensation, and audit evidence, which CK treats as complementary to its branch-head boundary.","marker":"[15]"}],"fun_headline_variants":["One atomic commit decides which AI state is real","Continuity Kernel: state safety as a single transaction","Zero invariant violations across 2.8M agent states","Decouple proposal from activation for trustworthy agents","Transactional continuity replaces memory for agent authority"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is Assumption A4: the storage engine must atomically serialize the branch row together with every named context, effect, and directory row, durably all-or-none; if that single atomic step cannot be provided, the exact-succession, at-most-once, and isolation claims collapse.","fun_headline_variants_meta":{"raw":{"variants":["One atomic commit decides which AI state is real","Continuity Kernel: state safety as a single transaction","Zero invariant violations across 2.8M agent states","Decouple proposal from activation for trustworthy agents","Transactional continuity replaces memory for agent authority"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000287,"raw_usage":{"total_tokens":1667,"prompt_tokens":911,"completion_tokens":756,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":527,"completion_tokens_details":{"reasoning_tokens":684}},"tokens_in":527,"tokens_out":756,"duration_ms":8320,"temperature":1.0,"reasoning_tokens":684,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T00:33:11.648495+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run two conflicting activation attempts that name the same exact predecessor head against a storage substrate that commits the branch row and the named context rows in separate non-atomic operations; observing two durable Commit receipts with the same predecessor would violate Proposition 2 and show A4 is doing the work.","supporting_citations":[{"cited_title":"On optimistic methods for concurrency control.ACM Transactions on Database Systems (TODS), 6(2):213–226, 1981","cited_arxiv_id":null,"evidence_quote":"Supplies the commit-time revalidation paradigm: read assumptions are checked at commit, which CK extends to exact-head and typed-absence admission."},{"cited_title":"Morgan Kaufmann, 1992","cited_arxiv_id":null,"evidence_quote":"Provides the standard atomic-transaction substrate that CK's activation step assumes for durably installing the accepted unit."},{"cited_title":"In search of an understandable consensus algorithm","cited_arxiv_id":null,"evidence_quote":"Contributes replicated consensus and term fencing, the model for stale-writer exclusion CK adapts to writer handoff."},{"cited_title":"Imple- menting linearizability at large scale and low latency","cited_arxiv_id":null,"evidence_quote":"Supplies unique request identifiers, atomic completion records, and safe reclamation, which CK composes into stable proposal and effect identity."}],"review_version":1}