{"id":"a36dca5c-0022-47a8-9c98-1991a525c9ff","arxiv_id":"2607.18347","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"A merchant-side decision envelope with dependency hashes, execution-time revalidation, and a frozen verified-state boundary stopped all eight tested stale or hostile agent decisions, and every deliberate safeguard-bypass reproduced the predicted failure.","lead":"This paper presents a reference architecture that gives an online merchant one canonical place to decide whether an AI shopping agent's requested action — checking out, paying, quoting policy — is currently valid, authenticated, and backed by fresh evidence. It matters because agents now act under delegated authority, and merchants have no standard way to block stale, redirected, or unsupported decisions.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Eleven-invariant conformance contract is a universal claim unsupported by formal verification; eight scenarios cannot establish it.","rationale":"The reader's weakest_assumption focuses on the deployment premise that authoritative sources expose stable revisions; our concern is more internal: the invariants themselves are asserted as a universal contract without formal proof or exhaustive testing. This partially agrees with the reader's structural issue that 'invariants I1–I11 are universal conformance claims demonstrated on eight scenarios with no formal verification' (§7.5). The paper is commendably honest—it lists formal verification as future work, discloses the I11 defect history, and scopes its conclusions to synthetic fixtures—but the combination of a universal contract and scenario-limited evidence leaves the central claim at CONDITIONAL risk. Our proposed model-checking experiment directly tests whether the invariants are sound and complete, which is the load-bearing condition for the 'viable conformance contract' assertion. Since the reader already reached CONDITIONAL for overlapping reasons, we recommend no verdict change.","tokens_in":16773,"tokens_out":10626,"duration_ms":104885,"concrete_test":"Formalize the envelope state machine and invariants I1–I11 in TLA+ or Alloy using the state variables from §4.2 (context C, result R, metadata M, dependency set, generated-claim axes, evidence records). Model a transition system that mutates any dependency, claim-parent lineage, evidence content, or request context, and assert each invariant over all reachable states. Run TLC or the Alloy Analyzer against the full state space (or an exhaustive bound) and check for violations. A clean model check would provide the first non-author-designed support for the invariants' universality; any counterexample would falsify the conformance contract as stated.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim hinges on the eleven invariants in Table 4 being a viable conformance contract for every externally usable decision (§4.3). This is a universal statement, but the evidence consists of eight author-designed scenarios and no formal verification. §3.1 discloses that I11 was added only after a verified-state defect was found, showing that invariant discovery is non-exhaustive; §7.5 lists formal verification or model checking as future work, conceding the current absence. Invariants such as I6 (hash completeness) and I10 (refusal monotonicity) quantify over all possible state changes, dependency mutations, and generated-claim lineage, yet only seven state-change classes and one hostile accessor are tested. A hidden interaction—e.g., a dependency change that leaves the protected hash unchanged under the implemented canonicalizer, or a claim whose taint is altered by a parent not tracked in the bounded lineage—could violate an invariant without appearing in the corpus. The paper does not demonstrate that I1–I11 are sufficient to rule out every stale or hostile decision; it demonstrates that one implementation satisfies them on selected fixtures. This is distinct from the deployment-condition concern about authoritative sources: it questions whether the invariants themselves are internally sound and complete.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a protocol-agnostic, merchant-side decision architecture for agentic commerce: a canonical decision envelope with protected dependency/result/decision hashes, detached Ed25519 or HMAC authentication, live-request rebinding, a seven-axis generated-claim capability gate, execution-time dependency revalidation, and eleven semantic invariants. It reports an open-source JavaScript reference implementation (v0.9.2) and evaluates it with eight deterministic scenarios and five controlled ablations. The reported results are that seven initially valid actions are permitted, all seven are stopped after a relevant state change, the hostile-accessor case remains blocked, surface-bound envelopes agree on action status in 8/8 scenarios, and each ablation produces the predicted unsafe regression when one safeguard is bypassed while the protected path contains the failure. The manuscript consistently and explicitly limits these findings to synthetic fixtures, and disclaims production security, performance, legal compliance, live interoperability, rule completeness, population error rates, and independent replication.","tokens_in":16977,"tokens_out":10009,"duration_ms":92066,"significance":"If the result holds, the paper makes a useful design-science contribution: it gives a concrete, testable articulation of what a merchant-side decision layer must enforce when agents transact under delegated authority. The main strengths are the machine-checked reproducibility of the artifact (66/66 tests, schema validation, committed examples), the frozen archive with checksums and logs, the explicit adversary model, and the transparent disclosure that the author designed the artifact, rules, scenarios, and pass criteria. The stress-test concern about universal invariant sufficiency is real, but the paper already bounds its claims in §3.6 and §7.4; it is a scoping question rather than a demonstrated internal inconsistency. The work does not provide formal verification or external validation, and its value is correspondingly an executable conformance contract for a proposed architecture, not an empirical or formal guarantee.","major_comments":[],"minor_comments":[{"comment":"The invariants are introduced as conditions that must hold 'for every externally usable decision,' and §8 says they make semantic conformance testable. The evidence shows that the frozen implementation satisfies them on the eight scenarios and five ablations; it does not prove that I1–I11 are sufficient to exclude every stale or hostile decision, and §7.5 correctly lists formal verification as future work. Please add one sentence in §4.3 or §8 stating that the invariant set is proposed as a conformance contract and has been demonstrated on the tested fixtures, not claimed to be complete or formally verified. The abstract's caveat is appropriately narrow; the body should be aligned with it.","section":"§4.3, Table 4"},{"comment":"The integrity model relies on a custom deterministic normalizer rather than RFC 8785/JCS, with only a one-sentence justification. Because invariant I6 (hash completeness) and all change-detection claims depend on canonicalization being stable and collision-safe, please add a short note explaining why the custom normalizer was preferred over JCS and which tests establish its equivalence properties (key sorting, unordered-collection normalization, number and string handling). If such tests are among the 66, name them explicitly; otherwise add targeted test vectors.","section":"§4.2, Eq. (1)"},{"comment":"The trust boundary is clearly defined for snapshots, but the paper's own concession that an authenticated envelope can 'faithfully preserve a wrong price, biased rule, or legally incorrect policy' (§7.4) deserves a more prominent visual or structural place in §4.4. A small figure or explicit bullet list marking 'authoritative source correctness' and 'merchant rule correctness' as outside the verified-state boundary would prevent readers from conflating a verified decision with a commercially correct one.","section":"§4.4, §7.4"}],"recommendation":"minor_revision","confidential_remarks":"This is an unusually transparent design-science manuscript: the author discloses the circularity of author-designed rules/fixtures, the prior public disclosure, and the absence of formal verification. The main residual risk is external validity, which the authors themselves disclaim. I do not regard the circularity concern as grounds for rejection; it argues for reading the paper as a reproducible executable conformance contract rather than as a formal guarantee. If the journal's scope requires formal verification or independently acquired data, this manuscript would be a poor fit; otherwise the local scoping and presentation issues above are readily addressable."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Dear colleague — you should know this paper is an unusually honest design-science submission. It claims exactly what the evidence supports and lists its own limitations in readable form. The idea: a merchant-side decision layer that owns commercial eligibility, authority, checkout validity, payment dispatch, and generated-claim truth, independent of the protocol adapters (ACP, AP2, UCP, MCP). That gap is real. The paper's eleven invariants (I1–I11) are a clear conformance contract, and the canonical envelope with protected dependency/result/decision hashes is a sensible way to make them executable.\n\nWhat's genuinely good: the evaluation is thoroughly reproducible — commit hash, SHA-256, fixed toolchain, three npm commands, machine-readable logs. The seven scenarios and five ablations are deterministic, use structured raw facts rather than caller-selected blockers, and pair each protected path with a deliberately unsafe variant. The paper explicitly states that results support six bounded properties under synthetic fixtures, and it discloses prior professional disclosure and AI assistance. That is the right tone.\n\nSoft spots: the evidence base is entirely self-authored — architecture, code, rules, fixtures, pass criteria, expected outcomes. That is disclosed, but disclosure doesn't lower the circularity burden. The invariants are universal claims ('every externally usable decision') but they are demonstrated on eight scenarios, no formal verification, and I11 was added only after a verified-state defect was found. That tells us invariant discovery is not exhaustive. The stress-test concern is fair: a hidden interaction could violate I6 or I10 without being caught. I'd also flag the deployment assumption — the architecture depends on authoritative sources exposing stable revisions. If the source is wrong or lacks revision IDs, the envelope faithfully preserves the wrong price or policy, which the paper concedes in §7.4.\n\nNone of this is fatal. The architecture is a useful step, and the paper is clear that it is not proposing a standard. It belongs in peer review: the problem is significant, the reasoning is coherent, and the open artifact gives referees something concrete to inspect. The main revision pressure should be on weakening the universal phrasing of the invariants and on independent replication or formal verification as a condition, exactly as the paper's own research agenda says. Who should read it: anyone working on agentic commerce protocols or merchant decision layers; it will be a useful reference point even if only as a bounded design candidate.","headline":"A clear-headed, honestly bounded design-science paper: the architecture and invariants are a useful gap-filler, but the evidence is all self-authored and the invariants remain unproven beyond eight synthetic scenarios.","tokens_in":17566,"tokens_out":2102,"would_cite":true,"duration_ms":19919,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A canonical signed decision envelope can stop stale, redirected, or hostile agentic-commerce actions before they take effect.","keywords":["agentic commerce","canonical decision envelope","protected dependency hashes","stale-decision prevention","execution-time revalidation","generated-claim capability","verified-state identity","decision invariants"],"falsifier":"Run the reference implementation against a source system whose price changes but whose exposed revision identifier or hash remains unchanged; if the earlier allowed checkout decision still proceeds, the central claim fails. Equivalently, an independent harness can mutate a protected dependency's underlying content without changing its content-addressable reference and observe whether execution-time comparison catches it.","tokens_in":16480,"feed_emoji":"🛒","tokens_out":4125,"duration_ms":39303,"temperature":0.7,"pith_summary":"The paper argues that the missing piece in agentic commerce is a merchant-owned decision layer that tells agents whether an action is commercially valid at the moment it is requested. It proposes a canonical envelope that hashes the decision's inputs, results, and identity, signs it, and requires recipients to verify it against the live request and current authoritative state before use. The evaluated reference implementation stopped all seven initially valid actions after price, promotion, inventory, mandate, evidence, delivery, or return-policy state changed, and also blocked a hostile accessor that tried to alter state after verification. If this holds in real deployments, merchants can rely on one authoritative decision representation across protocols and surfaces rather than letting each adapter interpret commercial meaning.","feed_headline":"Signed envelopes stop stale AI-commerce decisions in 8 of 8 tests","feed_subtitle":"Merchant-side revalidation of price, stock, policy, and mandate blocks every stale agent action in the tested fixtures.","key_machinery":"The canonical decision envelope: one content-addressed object for one requested action in one context. It carries three protected hashes—an input dependency hash over normalized request and dependency state, a result hash over computed result state, and a decision hash over metadata plus the first two—authenticated by Ed25519 or HMAC. A trusted projection boundary deep-freezes a single detached JSON snapshot and projects only from that verified state, and execution-time dependency revalidation compares protected dependency identities and hashes with current authoritative snapshots. Eleven semantic invariants (including payment non-escalation, projection non-recomputation, generated-claim cap","core_discovery":"On the paper's own terms, the discovery is that a merchant can express 'is this action valid now' as a single signed object whose meaning cannot drift: a canonical envelope containing protected input-dependency, result, and decision hashes, with a detached frozen snapshot projected only after live-request rebinding and execution-time comparison with current authoritative dependencies. The evaluation supports this for the tested classes: after any of seven protected state changes, earlier decisions became unusable and required fresh decisions; a caller-controlled accessor was read once and could not flip a blocked result; and five ablations produced predicted unsafe regressions only when safe","pith_inferences":["The architecture effectively relocates the trust bottleneck to the dependency-adapter layer: if a source system cannot expose stable revision identifiers, or the authoritative store itself is wrong, execution-time revalidation compares only what adapters exposed and the envelope will faithfully preserve the incorrect fact.","The same signed-envelope pattern could be applied beyond commerce—any domain where a decision about current state must be projected to multiple consumers and where stale decisions create liability, such as eligibility, entitlement, or compliance checks.","A natural testable extension is to measure stale-decision rates with real catalogs whose revision metadata is noisy, to see whether the protected-dependency comparison degrades gracefully or silently accepts unchanged revision IDs.","Because the trusted decision builder is assumed uncompromised, the architecture does not by itself defend against prompt injection in the agent's reasoning context; complementary controls at the model and tool layers remain necessary."],"forward_implications":["Any change in a protected dependency—price, stock, policy, mandate, evidence, delivery promise—invalidates earlier decisions, so agents must obtain a fresh decision before acting.","The same action status can be projected consistently across feed, tool, checkout, protocol, and support surfaces without recomputing commercial meaning.","Generated product or policy language becomes unusable when its source evidence disappears, its freshness expires, or a parent claim is refused; rewriting cannot launder a refusal.","A merchant can adopt the pattern as a domain function without replacing its commerce platform, but must revalidate the owning aggregate immediately before any mutation.","Integrity verification alone is insufficient: target-surface binding and live action/actor/subject rebinding are necessary to prevent replay and redirection."],"fun_headline_variants":["Signed envelopes block stale AI-commerce actions in 8/8 tested cases","Canonical signed hashes force fresh decisions: 8/8 stale actions blocked","Merchant-side envelope revalidation stops every stale agent action","Decision center: signed state guard blocks 8 of 8 stale actions","Protected hashes rebind live: no stale decision survives in 8 tests"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The guarantee presupposes that every commercially material input can be represented as a protected, content-addressable dependency from an authoritative source system that exposes stable identifiers, timestamps, revisions, or hashes; if a source lacks stable revisions or the authoritative store itself is wrong, revalidation compares only what the adapter exposed and the envelope preserves the wrong fact.","fun_headline_variants_meta":{"raw":{"variants":["Signed envelopes block stale AI-commerce actions in 8/8 tested cases","Canonical signed hashes force fresh decisions: 8/8 stale actions blocked","Merchant-side envelope revalidation stops every stale agent action","Decision center: signed state guard blocks 8 of 8 stale actions","Protected hashes rebind live: no stale decision survives in 8 tests"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000994,"raw_usage":{"total_tokens":4070,"prompt_tokens":787,"completion_tokens":3283,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":531,"completion_tokens_details":{"reasoning_tokens":3186}},"tokens_in":531,"tokens_out":3283,"duration_ms":22102,"temperature":1.0,"reasoning_tokens":3186,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-01T17:18:32.650741+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the reference implementation against a source system whose price changes but whose exposed revision identifier or hash remains unchanged; if the earlier allowed checkout decision still proceeds, the central claim fails. Equivalently, an independent harness can mutate a protected dependency's underlying content without changing its content-addressable reference and observe whether execution-time comparison catches it.","supporting_citations":[],"review_version":1}