acceptodds
Under review as a conference paper at ICLR 2027

VersionSeal: Exact-Version Authorization from Federated Route Commit to Citation

Abstract

Two federated retrievals can finish with the same selected site, source identifier, and cited key-version yet disagree on whether that citation was authorized. If a replacement version was visible when routing inspected the site, the old version violates the route snapshot; if publication occurred immediately afterward, the identical citation is valid. Final freshness and provenance records cannot distinguish these histories. VersionSeal preserves the missing witness by atomically naming each query-visible index generation, sealing the selected generations at route commit, and judging every version-addressed cache path against that token before service in Strict mode or asynchronously in Balanced mode. On three paired six-hour replays, the complete Balanced protocol reduces exact-snapshot violations from 2.12% for FreshSketch—a same-stack freshness-aware control without atomic generation publication, route sealing, or exact-generation path disposition—to 1.18% (paired reduction 0.94 pp [0.78,1.09]); p99 retrieval latency changes from 4.84 to 4.62 s and WAN traffic from 146 to 133 KB/query. Strict operation records 0 violations among 443700 served paths at 98.6% query availability, while Balanced provides 99.2% availability and, with generator and context budget fixed, improves temporal-answer correctness by +4.6 pp [1.9,7.2] and reduces outdated or unsafe answers by -3.9 pp [-6.1,-1.8]. A 14-day Wikidata/Wikipedia revision replay and ten paired 24-hour runs preserve the complete-protocol violation-rate ordering; together with the observational separation, these results support treating route commit as an authorization boundary under the evaluated update dynamics.

open until 14 Dec 2026

est. 32% chance this paper gets accepted at ICLR 2027.

Reject 68%Accept 32%

What do you think this paper will get?

All positions stay anonymous.

Related papers

Loading the map…

Discussion (0)

Sign in to comment.