Fail-Closed Lowering of Resident KV Claims onto LLM Serving Runtimes

Unknown

Conceptio › Archive › arXiv CS

arXiv CSopen access

Fail-Closed Lowering of Resident KV Claims onto LLM Serving Runtimes

Unknown · 2026 · arxiv_cs

arXiv CS · Papers · License: Open Access · 2026

Open Source ↗Direct PDF ↓

cloud distributedcomputing parallelcomputing

distributed computing, parallel computing, cloud

Fail-Closed Lowering of Resident KV Claims onto LLM Serving Runtimes Lukas Stepanek [email protected]

arXiv:2606.01387v1 [cs.DC] 31 May 2026

May 2026

Abstract LLM serving runtimes increasingly expose KV-cache primitives that look like future-reuse controls: retention priority, TTL-like duration, host or storage offload, block events, active no-evict scheduling, and KV-aware routing. Feature primitives are weaker than accepted future-KV obligations: a runtime can expose priority, offload, events, and routing without accepting responsibility for a future reuse claim. This paper studies ResidentClaim lowering at the obligation level. A runtime or trusted adapter must bind behavior to accepted claim identity, a materialization predicate, ordered lifecycle events, and claim-scoped outcomes before a primitive can be treated as semantic conformance. We contribute a fail-closed lowering relation, checker, descriptor format, and bad-lowering suite that classify rows as native conformance, adapter-observational evidence, adapter-policy evidence under controlled pressure, approximation substrate, rejected mapping, or unknown evidence. In the descriptors and evidence audited here, the checker validates manually curated, anchored runtime descriptors against obligation bundles; it is not a proof that unaudited runtime behavior is complete. Public TensorRT-LLM, SGLang/HiCache, and Dynamo expose strong substrates and selected adapter positives, not native ResidentClaim conformance. The positive systems witness is a local patched vLLM connector/scheduler-boundary mechanism: claim metadata flows through real in-process offload/load behavior, and controlled same-claim restoration failure reaches vLLM’s invalid-KV-load path and becomes an ordered scheduler-boundary fail-closed active outcome. The result is a calibrated semantics boundary, not a production performance claim or a compatibility survey.

1. Introduction KV-cache reuse has become an explicit systems surface in LLM serving. Production and research runtimes expose token-range retention priorities, duration fields, block stored/removed events, GPU/host/storage cache tiers, loadback paths, active no-evict modes, and KV-aware routing. These mechanisms are real and important. They also create a tempting inference: if a runtime has priority, offload, routing, or no-evict, perhaps it implements futureresident KV claims. This paper argues that the inference is unsound. A ResidentClaim is not a knob name. It is an accepted futurereuse responsibility over a cache identity, a reusable object, a materialization predicate, a footprint, a mode, and an ordered outcome. If a block is stored, that does not show that the claimed future computation state is materialized. If a block is removed, that does not show claim harm. If bytes move to host memory, that does not show the claim can be restored before reuse. If a router chooses a worker with useful cached KV, that does not show the route and later reuse are attributed to an accepted claim. The checker validates curated descriptors and anchored evidence against these obligation bundles. It deliberately does not prove that unaudited runtime behavior is complete. This distinction is the main calibration point: feature names can be useful substrates, but accepted future-reuse obligations require claim identity, acceptance, predicate, order, and claim-scoped outcomes at the depth being asserted. We treat ResidentClaims as the contract abstraction and focus on the lowering question: when can a runtime primitive, adapter, or patch conformantly supply the obligations of that contract? This keeps the paper’s role

separate from the contract definition itself. The contribution here is the evidence relation that decides whether concrete serving surfaces satisfy, approximate, or fail those obligations. The first claim is semantic: accepted future-KV responsibility requires claim-level obligations. Without claim identity, a runtime cannot distinguish ordinary cache behavior from claim outcomes. Without explicit acceptance, there is no responsibility boundary. Without a predicate, block survival is not useful state survival. Without ordered lifecycle events, an observer cannot distinguish restore-before-reuse from restore-after-use, or demotion-before-loss from post-hoc explanation. Without failure outcomes, an offload substrate does not become an offloadable claim. A running example fixes the boundary. Let claim C cover prefix P with predicate leading-prefix-at-least-448. The claim is first accepted by a mechanism that records C, P, and the predicate. The prefix becomes materialized; later, its KV blocks are offloaded from GPU to CPU. A future reuse request for P is not satisfied merely because CPU bytes exist. It requires an ordered CPU-to-GPU restoration before the reuse consumes the prefix. In the patched vLLM connector/scheduler-boundary mechanism, the failure experiment forces that same-claim restoration to fail. The scheduler invalid-KV-load path then reports a claim-scoped restoration failure and a fail-closed active outcome for C. This is the event sequence the checker accepts; generic transfer counters, fallback recomputation, wrong-claim failure, or unclaimed failure are not accepted as satisfying C. For this example, the accepted path is deliberately narrow: accept(C, P, leading-prefix-at-least-448), materialized(C), offloaded(C), restore-required(C), same-claim load failure, restoration_failed(C), and then active_request_refused(blocking_claim_ids=[C]). The same bytes, counters, or request error without that ordering are insuﬀicient. The second claim is methodological: a fail-closed lowering relation can separate native conformance, adapter-scoped evidence, approximation substrates, rejected mappings, and unknown evidence. This matters because several rows are partly positive. TensorRT-LLM block events can be joined by an external adapter to reconstruct selected best_effort materialization observations. TensorRT priority can be joined to external claim state to reconstruct controlled soft-priority retention-order evidence. SGLang request cached-token telemetry and block events can be joined to reconstruct selected materialization observations. These rows are useful, but they are not native backend support and they do not imply enforcement. The third claim is empirical and systems-oriented: public runtimes expose strong substrates and narrow adapter positives, while a targeted patched runtime mechanism demonstrates implementability of the missing lifecycle/outcome semantics. In the current artifacts, no TensorRT-LLM, SGLang/HiCache, or Dynamo descriptor produces native_ sound. The local patched vLLM connector/scheduler-boundary mechanism does pass the offload lifecycle/outcome gate at backend_patch depth: claim metadata flows through real in-process OffloadingConnector store/load jobs and worker transfers, and controlled same-claim CPU -> GPU load failure produces scheduler_resident_claim_ restoration_failed followed by the fail-closed active outcome event scheduler_active_request_refused before request termination. Negative rows are a result, not a weakness in the evaluation. A conventional compatibility table would mark “priority”, “TTL”, “offload”, “events”, and “routing” and appear to close the problem. The lowering matrix asks a different question: which obligations are actually represented, at which adapter depth, under which evidence scope? When active no-evict is active-request scoped rather than accepted future-resident protection, the correct result is rejection. When storage tiers lack restoration-before-reuse and restoration-failure outcomes, the correct result is approximation. When routing lacks claim-scoped route cost, placement, and reuse attribution, the correct result is approximation. Those classifications are what keep the contract meaningful. Intro counterexamples: feature names versus obligations. Feature-only inference

Missing obligation boundary

Correct lowering label

Priority value or retention hint means soft_priority.

Claim identity, claim-scoped telemetry, and controlled evidence that priority changed retention order. Claim-scoped expiry boundary and ordered responsibility transition before loss.

approximate unless the pressure and claim-join evidence are present.

Duration/TTL field means expiring.

approximate under current public evidence.

Feature-only inference

Missing obligation boundary

Correct lowering label

Active no-evict means future-resident hard_protected.

Accepted future-resident identity, protected-victim exclusion, explicit conflict action, blocking claim ids, harm attribution, and order. Restoration before predicate-satisfying reuse and claim-scoped restoration failure outcome. Claim-scoped route cost, placement attribution, later reuse attribution, predicate, and telemetry. Same accepted claim, ordered restore-required event, scheduler-boundary failure/refusal attribution, and blocking ids.

rejected for the observed active-request-scoped mapping.

Host/storage tier means offloadable.

KV-aware routing means routed_ reuse. Generic transfer or request-failure counters mean restoration failure.

approximate or unknown, depending on whether the storage substrate is exercised. approximate under current docs-backed evidence. Rejected by the connector gate.

This paper is not a KV eviction algorithm, not a production offload evaluation, and not a claim that existing runtimes lack useful KV mechanisms. It is a semantic conformance study: what must be true before an accepted ResidentClaim can be lowered onto a serving runtime, and what current evidence can and cannot show. The paper is therefore organized around three pillars: obligation-level lowering and a fail-closed checker; publicruntime boundary studies with false-positive rejection; and the patched vLLM connector/scheduler-boundary mechanism as the positive systems witness for the missing offload lifecycle/outcome semantics.

2. Contributions This paper makes four concrete contributions. 1. It defines an obligation-based lowering model for ResidentClaim modes: best_effort, soft_priority, hard_ protected, demotable, expiring, offloadable, and routed_reuse. 2. It implements a fail-closed checker and false-positive suite over machine-readable runtime descriptors. The checker counts obligations only when evidence is supported and anchored, requires anchored observed evidence atoms, and keeps adapter depth separate from classification. Descriptor and evidence mutation controls fail closed in 16/16 cases. 3. It studies the boundary of public TensorRT-LLM, SGLang/HiCache, Dynamo-style KV routing, and vLLM surfaces. The resulting matrix distinguishes adapter-observational evidence, adapter-policy evidence under controlled pressure, approximation substrates, rejected lowerings, and unknown rows. 4. It demonstrates a local patched vLLM connector/scheduler-boundary mechanism at backend_patch depth. The repeated scheduler-boundary evaluation records 131/131 completed subprocesses, 131/131 valid event sequences, 30/30 successful observation passes, 30/30 same-claim scheduler-boundary failure-outcome passes, and fail-closed rejection of wrong-claim, unclaimed, fallback-recompute, ordinary-offload-without-claim, and generic-counter controls. A clean multi-claim attribution rerun records 3/3 target-only failure/refusal attributions while the non-target claim restores successfully. The contribution is deliberately bounded. We do not claim a better KV eviction policy, production performance, native/upstream vLLM support, native TensorRT-LLM/SGLang/Dynamo support, production offloadable support, pre-admission refusal, or scheduler-native admission protocol support.

3. ResidentClaim Obligations ResidentClaim lowering is strict because accepted responsibility is strict. The obligations are not arbitrary hurdles for existing systems; they define a conservative audit boundary for deciding whether a future-reuse claim was satisfied, 3

demoted, expired, restored, refused, harmed, or simply never accepted. Each obligation blocks a common false positive where ordinary cache behavior is misread as accepted-claim conformance. This is not a proven minimality claim. This section summarizes the contract obligations only to fix the checker input; the paper’s new object is the lowering judgment over runtime descriptors and evidence. Table 1: ResidentClaim obligations. Obligation

Why it is necessary

claim_identity

Without a stable claim id, block/request events cannot distinguish claimed KV from unclaimed KV. Without acceptance, an application hint never becomes runtime responsibility. Without a useful-state predicate, stored blocks cannot be interpreted as satisfying the claimed future reuse. Without footprint at claim granularity, active/resident infeasibility cannot be attributed or budgeted. Without order, the observer cannot tell whether demotion, expiry, restore, refusal, or loss happened before or after the relevant claim transition. Without a claim-scoped materialization event, best-effort telemetry remains block/request telemetry. Without an ordered demotion, losing protected state is indistinguishable from breaking a still-protected claim. Without a responsibility boundary, post-duration loss cannot be classified as violation or post-expiry non-responsibility. Without restoration before reuse, a storage tier is only bytes somewhere else. Without claim-scoped failure, offload failure is indistinguishable from ordinary miss, unrelated error, or fallback recomputation. Without victim exclusion, hard protection collapses to soft priority under pressure unless another explicit contract transition occurs first. Explicit active/resident conflict action: refusal, defer, route elsewhere, bound active KV, offload, split/recompute, or explicit claim relaxation/demotion when the contract permits it. Without blocking ids, the chosen conflict action cannot be attributed to the resident claim that caused infeasibility. Without harm attribution, predicate-breaking loss is ordinary cache loss, not claim harm. Without claim-scoped telemetry, observations cannot become claim outcomes. Soft priority requires evidence that priority affects policy, not merely that a field exists. Without route cost attribution, routing cannot report what cost was paid to preserve or reuse a claim. Without placement attribution, worker choice is orchestration state, not a claim action. Without reuse attribution, later hit/miss behavior cannot be assigned to the routed claim path.

explicit_acceptance materialization_predicate footprint_accounting ordered_lifecycle_events

claim_materialized_event claim_demoted_before_loss claim_expired_boundary

offload_restorability restoration_failure_outcome

victim_exclusion_before_violation

explicit_conflict_action

blocking_claim_ids

claim_harm_attribution claim_scoped_telemetry priority_influence route_cost_attribution placement_attribution reuse_routing_attribution

The checker keeps the older key active_refusal_or_defer only as a backward-compatible alias for explicit_ 4

conflict_action; the manuscript tables and descriptions use the latter name. The current checker groups these obligations into mode bundles. Each bundle is defined in modes.yaml; the checker test used here is: • best_effort: claim identity, a fixed materialization predicate, and claim-scoped materialization telemetry. Raw stored/removed block events are not enough. • soft_priority: claim identity, priority influence, claim-scoped telemetry, and anchored pressure observations. Priority values or duration fields alone are not enough. • hard_protected: explicit accepted-claim responsibility, footprint accounting, victim exclusion before violation, an explicit conflict action, blocking claim ids, harm attribution, and order. Refusal/defer is one valid implementation path, not the only one: routing elsewhere, bounding active KV, offloading active or resident state, recompute/split, or explicit relaxation/demotion can satisfy the action-space obligation only if the descriptor claims that action and provides anchored evidence for it. Active no-evict for running requests is not enough. • demotable and expiring: an ordered claim-level responsibility boundary before loss. Priority updates, lower cache levels, or wall-clock arithmetic are not enough. • offloadable: restoration before predicate-satisfying reuse and a claim-scoped restoration-failure outcome. Storage tiers, prefetch, write-back, load-back, transfer counters, or generic failures are not enough. • routed_reuse: claim-scoped route cost, placement, and later reuse attribution. KV-aware routing or worker overlap scoring alone is not enough. Evidence-to-obligation summary.

Mode

Required obligations

Allowed adapter/patch depth

best_effort

Identity, predicate, materialized event, claim telemetry.

telemetry_join or deeper under registry/join preconditions.

soft_priority

Identity, priority influence, claim telemetry, and controlled pressure atoms.

Native priority plus telemetry_ join for claim attribution.

hard_protected

Identity, acceptance, predicate, footprint, victim exclusion, explicit conflict action, blocking ids, harm attribution, and order.

scheduler_hook plus allocator_ hook, or backend_patch when the patch supplies both.

Accepted evidence shape

Rejected false positive

Evidence source class

Anchored block, token, or request evidence joined to a pre-registered claim and named predicate at a named observation point. Original, swappedpriority, and equal-priority pressure controls with claim-scoped retention order. Anchored conflict trace for the claimed action: refusal, defer, route elsewhere, bound active KV, offload, split/recompute, or explicit relaxation/demotion.

Raw block stored/removed events.

Source, trace, artifactgenerated.

Priority value, duration field, or source-level priority API alone.

Source, trace, controlled pressure.

Active no-evict for the running request.

Source, trace, failure injection, artifactgenerated.

Mode demotable

expiring

Required obligations Identity, acceptance, demotion before predicatebreaking loss, and order. Identity, acceptance, expiry boundary, and order.

offloadable

Identity, acceptance, predicate, restorability, restorationfailure outcome, order, and harm attribution.

routed_reuse

Identity, predicate, route cost, placement, reuse attribution, and telemetry.

Allowed adapter/patch depth

Accepted evidence shape

Rejected false positive

Evidence source class

claim_registry plus ordered lifecycle evidence, or backend_patch.

Claim-scoped demotion boundary before loss.

Priority update, lower cache level, or post-hoc explanation.

Source, trace, artifactgenerated.

claim_registry plus ordered lifecycle evidence, or backend_patch. storage_ restorability or backend_ patch.

Claim-scoped boundary where responsibility ends before later loss. Restore-beforereuse success evidence plus claim-scoped restoration failure/refusal, demotion, expiry, or harm when restoration fails. Route decision, placement, and later reuse success/failure attributed to the accepted claim.

TTL/duration metadata alone.

Docs, source, trace.

Storage tier, generic transfer counters, fallback recompute, wrong-claim failure.

Source, trace, failure injection, artifactgenerated.

KV-overlap routing score or worker choice alone.

Docs, source, trace.

routing_hook or backend_ patch.

Three kinds of “acceptance” must also be kept separate. Claim registration by an external adapter can be suﬀicient for selected observational rows if the claim is pre-registered and the join is unambiguous. Backend primitive acceptance, such as accepting a retention-priority field, shows only that a primitive was configured. ResidentClaim semantic acceptance requires enough obligations to treat the claim as runtime responsibility.

4. Lowering Relation and Checker The core judgment is: backend + adapter + evidence |= ResidentClaim mode A backend/adapter/evidence tuple lowers a mode only if every required obligation for that mode is represented by the native backend or by an adapter whose depth and preconditions allow it to supply that obligation. Missing required obligations fail closed. The row becomes approximate, rejected, or unknown, depending on whether approximation signals exist, enforcement critical obligations are absent, or the evidence is inconclusive. The checker core is intentionally small: O[m] d a E e

= the obligation bundle required by mode m = descriptor with native evidence d.native = selected adapter depth and adapter evidence d.adapters[<= a] = anchored evidence atoms from docs, source, traces, controls = one native or adapter evidence item

supports(e, o) true when e marks obligation o as supported and has a concrete anchor. anchored(e) true when e names an anchor kind, path or public source, and note. For trace evidence, the anchor must also preserve the relevant order and claim scope. depth_allowed(a, o) true when o is native, or adapter depth a is allowed to supply o and its required preconditions hold. Lower(d, a, E, m) iff for every o in O[m], there exists evidence e in d.native, d.adapters[<= a], or E such that supports(e, o), anchored(e), and depth_allowed(a, o). label(d, a, E, m): native_sound sound_with_adapter rejected approximate unknown

if Lower holds using native evidence only. if Lower holds using allowed adapter or backend-patch evidence under its stated trust boundary. if the proposed mapping violates a forbidden lowering or misses enforcement-critical obligations. if related primitives or approximation signals exist, but Lower does not hold. if the evidence is inconclusive and no recognized approximation signal is exercised.

The checker does not require the exact event names used by the local vLLM patch. Equivalent runtime evidence can satisfy an obligation if it is anchored, ordered, claim-scoped, and supplied at an allowed adapter depth. The patch event names are one concrete witness, not a naming convention that public runtimes must copy. The implementation is a small Python checker over YAML mode definitions and backend descriptors. The artifact section gives the exact source, descriptor, and generated-output paths.

native_sound native backend conformance

capability descriptor native primitives + adapter depth

evidence atoms docs, source, traces, controls

anchors commit, path, event order

fail-closed checker

sound_with_adapter adapter or backend_patch under trust boundary

mode obligation bundle identity, predicate, lifecycle,

approximate / rejected / unknown

outcome

missing obligation, unsound mapping, or inconclusive evidence

Figure 1: Fail-closed lowering pipeline The checker enforces seven rules: Table 2: Fail-closed checker rules.

Rule

Consequence

Approximation signals never satisfy obligations by themselves.

Priority, duration, block events, storage tiers, and routing can make a row plausible without making it conformant. An obligation counts only when obligation_evidence is supported and has an anchor. Pressure atoms such as pressure_controls_observed cannot upgrade a row without trace anchors. Docs-only and source-inspection adapter rows do not become adapter-scoped positives without adequate runtime or conformance evidence. Telemetry joins can reconstruct observations; they cannot create allocator, scheduler, routing, or restoration enforcement. Block events can describe what happened, but cannot create refusal, victim exclusion, blocking claim ids, or restoration failure outcomes. Missing registry, unstable ids, cache-identity mismatch, partial event streams, duplicate ownership, and ambiguous event order do not produce claim outcomes.

Obligations are evidence-gated. Observed evidence atoms must be anchored. Evidence scope matters.

Adapter depth constrains obligations.

Telemetry cannot create enforcement.

Ambiguity fails closed.

The generated matrix uses five labels: Table 3: Checker labels and interpretation in this paper. Checker label

Meaning

Interpretation in this paper

native_sound

The backend natively satisfies all obligations for the mode without an adapter or patch. A represented adapter, hook, or patch supplies all obligations under explicit trust assumptions and adequate evidence.

Native backend conformance. No current descriptor has this label.

sound_with_adapter

approximate

rejected

unknown

The backend exposes related primitives but misses at least one required obligation. The proposed lowering would misrepresent the contract and must fail closed. Current evidence is inconclusive or the relevant primitive was not exercised.

Use a precise subtype, such as adapter-observational evidence, adapter-policy evidence under controlled pressure, or backend-patch mechanism. Useful substrate, not ResidentClaim conformance. Unsound mapping.

No classification claim yet.

The label names are implementation vocabulary rather than a formal proof claim. In particular, native_sound and sound_with_adapter mean that all required obligations are supported by curated, anchored descriptor evidence at the stated depth. They do not certify unaudited runtime paths. The risky label is sound_with_adapter, so the manuscript uses more precise phrases. Adapter-observational evidence reconstructs selected claim-scoped observations. Adapter-policy evidence under controlled pressure reconstructs selected policy behavior in the tested pressure regime. A backend-patch mechanism supplies obligations inside a modified runtime path. These are not interchangeable and none implies native backend conformance. Descriptor-to-row examples. 8

Positive row: TensorRT soft_priority + telemetry_join combines pre-registered claims, stable joins, priority assignment, pressure controls, and observed priority influence. For mode soft_priority at telemetry_join depth, those fields become adapter-policy evidence under controlled pressure. The checker label is sound_with_adapter, but the row is positive only for the tested controlled pressure family; it is not native TensorRT conformance or hard protection. Approximate row: TensorRT claim_joined_offload + generic_onboard_counters has one claim-joined offload plus generic onboard counters. For offloadable, the row remains approximate because it lacks claim-joined restorebefore-reuse and a restoration-failure outcome. Storage movement is useful substrate evidence, not offloadable ResidentClaim conformance.

5. Adapter Depths and Trust Boundaries The adapter boundary is part of the result because an adapter is part of the trusted computing base for any adapter-scoped row. The current depth ladder is: Table 4: Adapter depths and trust boundaries. Adapter depth

Meaning in this study

none telemetry_join

Only native backend obligations count. External registry and deterministic request/cache/event joins reconstruct selected observations. Accepted claim state is represented outside the backend or at a shallow integration point. Storage/load-back hooks can report claim-scoped restoration success and failure. Routing hooks can attribute route cost, placement, and later reuse to claims. Scheduler hooks can emit an explicit active/resident conflict action and report blocking claim ids. Allocator hooks can exclude accepted claim victims before violation. A modified backend path supplies the represented obligations.

claim_registry storage_restorability routing_hook scheduler_hook allocator_hook backend_patch

The telemetry_join depth is intentionally narrow. It can satisfy selected observational obligations only under these preconditions: Table 5: Telemetry-join preconditions. Preconditions for telemetry_join

Required meaning

External accepted-claim registry

Claims are pre-registered before the events being classified. Claim identity is stable and distinct from backend request ids. The reusable KV object is named consistently. The adapter knows the predicate being evaluated, such as leading_prefix_at_least(k). Request construction is derived independently from tokenizer output. Joins are scoped to model, tokenizer/token-hash domain, runtime, namespace, adapter identity, and block size.

Stable claim id Reusable object id Fixed materialization predicate Deterministic request-token map Fixed cache identity

Preconditions for telemetry_join

Required meaning

Named observation point

Materialization is evaluated at a named event or time boundary. Backend events expose enough block hashes, token ids, cache levels, and ordering to join to the predicate. Missing fields, duplicate owners, cache mismatch, post-hoc claim naming, and event ambiguity produce insuﬀicient evidence.

Joinable backend events Ambiguity fails closed

Telemetry-only adapters cannot satisfy enforcement obligations. They cannot create hard protection, victim exclusion, active conflict actions, blocking claim ids, demotion-before-loss, expiry boundaries, restoration failure outcomes, or claim harm. They can only make selected observations defensible when the join keys are trustworthy. The deeper adapter levels have analogous trust boundaries. They are stronger than telemetry joins only when the descriptor anchors the specific behavior claimed. Deeper adapter trust boundaries.

Depth storage_restorability

routing_hook

scheduler_hook

allocator_hook

Preconditions for counting obligations Claim is accepted before offload; store/load hooks name the same claim and cache identity; restoration is ordered before predicate-satisfying reuse; failure outcome is emitted before fallback or terminal handling. Route decision sees the accepted claim; worker/cache namespace is fixed; route cost, placement, and later reuse are all attributed to the same claim and predicate. Conflict is detected at a named active/resident boundary; the claimed action is emitted before terminal handling; blocking claim ids are stable and specific. Allocator exposes the victim candidate set, protected resident footprint, and ordered exclusion or release before predicate-breaking loss.

What can go wrong

Fail-closed handling

Hook can lie about media, race with reuse, lose load-failure events, or relabel fallback recompute as restoration.

Missing order, wrong claim id, storage-only evidence, fallback recompute, or generic counters do not satisfy offloadable.

Router can optimize overlap without accepting responsibility, misattribute worker state, or lose later hit/miss attribution.

Routing-only evidence remains approximate until all route, placement, and reuse obligations are claim scoped.

Scheduler can emit post-hoc reasons, smear blocking ids across claims, race with termination, or report refusal without the claimed resident cause.

The checker requires evidence for whichever conflict action is claimed. Ambiguous or smeared attribution fails closed.

Allocator can hide victims, race with compaction, report aggregate pressure only, or lose protected-victim identity.

Hard-protection rows remain rejected without victim exclusion or an explicit alternative contract transition.

Depth backend_patch

Preconditions for counting obligations Patch stack and imported source are identified; patched code lies on the exercised runtime path; adjacent hooks not used by the claim are absent or disabled; analyzer checks order and identity after the run.

What can go wrong

Fail-closed handling

Patch can bypass the real path, rely on adjacent instrumentation, misattribute claims, or overstate coverage beyond the exercised branch.

Patch evidence is a backend-patch witness only, not native support; the row counts only anchored obligations supplied by the patch and exercised trace.

Adapter composition is conjunctive and fail-closed. Selecting a deeper adapter depth permits obligations from shallower represented adapters only when each obligation has anchored evidence at a depth allowed to supply it. For hard_protected, scheduler_hook + allocator_hook means both sides are required: scheduler evidence may supply the explicit conflict action and blocking claim ids, while allocator evidence must separately supply victim exclusion before violation. Telemetry joins cannot fill either enforcement role, and a scheduler-only or allocator-only row remains rejected unless an explicit alternative contract transition supplies the missing obligation. These trust assumptions are part of the result. An adapter can lie, race, drop events, or misattribute claims. The checker cannot prove such failures absent; it handles them by refusing to upgrade ambiguous evidence into a claim outcome.

6. External Runtime Boundary Studies The central result is a semantic lowering table, not a feature compatibility chart. It summarizes the generated matrix and the boundary memos without treating feature names as conformance. Table 6: Runtime boundary study summary. Substrate

Best current evidence

Fail-closed boundary

Patched vLLM connector/scheduler boundary

backend_patch witness for the offloadable lifecycle/outcome bundle.

TensorRT-LLM

Adapter-observational best_effort and adapter-policy soft_priority under controlled pressure.

SGLang/HiCache

Adapter-observational best_effort under explicit telemetry-join preconditions.

Dynamo-style routing

Docs-backed boundary evidence and routing comparator.

Not upstream/native vLLM support, not production offload performance, and not pre-admission scheduler refusal. Active no-evict and storage movement do not supply future-resident hard protection or offloadable outcomes. Storage tiers and cached-token telemetry do not supply claim-scoped restoration success/failure. KV-aware routing alone lacks claim identity, route cost, placement, and later reuse attribution.

6.1 TensorRT-LLM TensorRT-LLM is the strongest public-runtime boundary study in this artifact set. The audited source descriptor at commit 06cff70502 records priority, duration, KV events, host secondary cache, and active no-evict mechanisms as substrates. The executable container descriptors represent the oﬀicial TensorRT-LLM 1.3.0rc14 and 1.3.0rc15

release containers separately, with runtime traces for block-event telemetry, priority/duration assignment, controlled soft-priority pressure, duration boundary probing, active no-evict, and corrected adaptive block-tier movement. The positive TensorRT rows are adapter-scoped. The best_effort + telemetry_join row reconstructs materialization for selected leading-prefix claims from an external registry, tokenizer-derived request map, cache identity, named observation point, and joinable block/token events. The soft_priority + telemetry_join row is adapterpolicy evidence under controlled pressure: original trials lost lower-priority prompt B first in 5/5 runs, swapped trials lost lower-priority prompt A first in 5/5 runs, equal-priority trials lost both tracked prompts in the same first-loss event in 3/3 runs, both claims were joinable before pressure in 13/13 trials, no pre-pressure claim loss occurred in 13/13 trials, and materialization changes were reconstructable in 16/16 tracked loss claims. The negative rows are equally important. GUARANTEED_NO_EVICT is available and runnable, but the observed API/source scope is active-request scheduling: the trace emitted 103 KV events, all created or stored, and did not expose native future-resident claim identity, explicit conflict action, blocking claim ids, harm fields, or victim exclusion before violation. The checker therefore rejects native hard_protected and hard_protected + telemetry_join. Duration remains approximation. A duration boundary trace assigned a 15s short claim and a 60s long control, then applied pressure after the short duration and before the long duration. It observed 480 pressure events, 448 stored events, 32 removed events, and 995 removed block hashes, but no duration/expiry event fields and no joined loss for either duration claim. That is retention metadata, not a claim-scoped expiry boundary. Offload remains below the offloadable bar for public TensorRT evidence. A corrected May 25, 2026 TensorRTLLM 1.3.0rc15 adaptive capture observed same-prompt block-hash tier movement: tracked assignment hashes moved from cache level 0 to 1 under pressure and back from 1 to 0 on before-removal same-prompt reuse. The corrected no-retention control shows this movement does not require retention config on either assignment or reuse. Differentprompt reuse did not onboard the tracked hashes, and post-removal same-prompt reuse stored/recomputed rather than restoring. This is runtime-observed block-tier movement substrate evidence, not ResidentClaim offloadable conformance: TensorRT still lacks accepted claim identity, a claim-scoped materialization predicate, restorationfailure outcome, and active/resident outcome attribution.

6.2 SGLang/HiCache SGLang/HiCache is the calibrated storage comparator. Source inspection at bbe9c7e shows radix priority, lock/reference state, protected and evictable accounting, GPU/host/storage tiers, prefetch, write-back, load-back, storage success/failure flags, cached-token details, and block events. These are strong mechanisms, but most are request, page, hash, token, or cache-node scoped rather than claim-outcome scoped. The positive SGLang row is best_effort + telemetry_join. A model-level trace and fresh-process repeat used an external accepted-claim registry, a tokenizer-derived request-token map, cache identity, request cached-token telemetry, and native block events to reconstruct materialization for leading_prefix_at_least(17). The cold shared-prefix request reported cached_tokens=0, the warm shared-prefix request reported cached_tokens=35, the salted wrong-prefix control reported cached_tokens=0, and native event replay returned 100 BlockStored events. This is adapter-observational evidence, not native SGLang ResidentClaim support. The HiCache/storage row remains approximate. HiCache exposes real storage and load-back mechanics, but the current evidence does not report claim-scoped restoration success before reuse, restoration failure as refusal/demotion/expiry or harm, ordered offload lifecycle, or claim harm attribution. A guarded cached_tokens_ details.storage proxy can support storage-backed materialization observations, but its ceiling explicitly excludes restoration success/failure semantics.

6.3 Dynamo-Style Routing Dynamo-style KV routing is included as a first-class boundary row because routing and placement are natural places to preserve future reuse. The public docs-backed descriptor records KV-aware routing, overlap and prefill-cost routing, worker KV event tracking, queue priority, and placement decisions as useful orchestration substrates. The routed_reuse mode asks for more: claim-scoped route cost, placement attribution, later reuse-routing attribution,

materialization predicate, accepted claim identity, and claim-scoped telemetry. Those obligations are not shown in the current docs-backed evidence, so routing remains approximate rather than conformant. Dynamo would upgrade from routing comparator to ResidentClaim evidence only if it exposed claim-scoped route cost, placement attribution, and later reuse success/failure attribution for an accepted claim.

7. Patched vLLM Connector/Scheduler-Boundary Mechanism The local patched vLLM connector/scheduler-boundary mechanism supplies the missing offloadable lifecycle/outcome witness at backend_patch depth. It patches the vLLM pydev OffloadingConnector path rather than replacing the offload path with a standalone simulator. Native vLLM supplies real in-process connector lookup, store/load job creation, worker transfer submission/completion, and failed-load propagation into the scheduler invalid-block path. The patch supplies ResidentClaim metadata, lifecycle joins, scheduler-boundary restoration failure telemetry, and claim-scoped outcome emission.

patch metadata C, P, predicate

native connector path lookup, jobs, transfer

invalid-KV-load boundary same-claim load fails

patch fail-closed outcome restoration_failed(C) active_request_refused([C])

checker accepts offloadable @ backend_patch

Figure 2: Patched vLLM connector/scheduler-boundary witness The mechanism has three trust boundaries. Native vLLM supplies connector lookup, store/load job creation, worker transfer submission/completion, and failed-load propagation into scheduler invalid-block handling. The patch supplies the accepted claim metadata, lifecycle joins, controlled same-claim failure injection, scheduler-boundary restoration failure telemetry, and active outcome emission. The artifact analyzer supplies no runtime behavior; it only checks order, claim match, and controls after the run. This separation is why the row is a backend-patch witness rather than native support. In this mechanism, “accepted” means that pre-request claim metadata is accepted by the patched path before the relevant lifecycle events. It does not mean an upstream user-facing vLLM ResidentClaim API exists. “Refused” means the patched scheduler emits a fail-closed active outcome after same-claim restoration failure is detected at the invalid-KV-load path and before terminal error handling. The scheduler-side active-refusal event is not pre-admission scheduling refusal. “Scheduler-boundary” means the patched path emits the active outcome at vLLM’s invalid-KV-load handling boundary before terminal request-finished/error handling. It is not initial scheduling admission and not upstream/native scheduler API support. Failure injection is disabled unless the resident-claim load-failure flag is enabled. When enabled, the hook matches only CPU -> GPU transfers and can filter by claim id. Unclaimed generic failures require a separate flag. The decisive positive path is not “a request failed”; it is the ordered sequence: accepted claim metadata exists, the claim has been offloaded, reuse requires restoration, the matching CPU -> GPU load fails under controlled injection, scheduler invalid-block handling identifies the affected request, emits scheduler_resident_claim_restoration_failed, and emits scheduler_active_request_refused with that claim in blocking_claim_ids before the request-finished boundary. The previous connector-level resident_claim_restoration_failed and active_request_refused events remain as downstream evidence. The witness tables use short aliases for layout; these are exact artifact event names and the observed failure reason: E0 E1 E2 E3 E4 E5 E6

request_initialized offload_lookup_result offload_store_job_created offload_worker_transfer_submitted offload_worker_transfer_finished resident_claim_offloaded resident_claim_restore_required 13

E7 offload_load_job_created E8 resident_claim_restored E9 offload_job_completed E10 offload_request_finished_no_pending_jobs E11 offload_worker_load_failed E12 scheduler_resident_claim_restoration_failed E13 scheduler_active_request_refused E14 offload_request_finished_pending_jobs F0 controlled_resident_claim_cpu_to_gpu_load_failure vLLM witness path A: successful offload/load observation. Order

Events

What it establishes

E2, E3, E4 success, E5

E0 reuse, E1 hit=448

E6, E7

E3, E4 success, E8, E9

E10 plus summary served

Claim metadata exists before the offload/load lifecycle. Store/offload job and GPU-to-CPU transfer complete for the claim. Reuse lookup hits the offloaded claim footprint. Restore/load is required before reuse can satisfy the predicate. CPU-to-GPU restoration succeeds before reuse completion. Reuse is served after predicate-satisfying cached tokens are restored.

vLLM witness path B: same-claim failure outcome. Order

Events

What it establishes

2 3

E2, E3, E4 success, E5 E1 hit=448, E6

E7, E3, E4 failure F0

E11

E12 with matching claim and FINISHED_ERROR E13 with blocking_claim_ids=[C] E14 after E12/E13

Claim metadata exists before lifecycle events. The same claim was offloaded. Reuse lookup hits and restoration is required. The CPU-to-GPU load failure is tied to the same claim. vLLM’s invalid-KV-load path has affected block evidence. Scheduler-boundary failure is claim-scoped. The active request is fail-closed because of the blocking claim. The scheduler outcome occurs before terminal request-finished handling.

7 8

vLLM witness path C: multi-claim attribution control. The clean attribution rerun creates two accepted ResidentClaim-shaped identities in one process. The non-target claim restores successfully through the offload/load path. The target claim arms controlled CPU -> GPU restoration 14

failure and receives scheduler-boundary scheduler_resident_claim_restoration_failed, scheduler_active_ request_refused, and blocking_claim_ids attribution. In 3/3 repetitions, scheduler events and blocking_ claim_ids named only the target claim; the non-target claim restored successfully in 3/3 repetitions and received 0/3 failure or refusal attributions. This is a target-attribution control for the backend-patch witness. It is not upstream/native vLLM support and not pre-admission refusal. The rerun provenance is deliberately narrow. The attribution summary is recorded in the paper artifact submodule at commit 558a069bd6fd897f4c5e7273e95d05f69c835a23. The vLLM source tree was at 0b129d97135c1f01 cc907008b7c93ad65256ea64 with no uncommitted changes, and the imported vLLM module matched that source in 3/3 repetitions. The adjacent 0004 prefix-cache materialization hook emitted 0/3 events in the raw traces. The target-attribution result therefore depends on the clean 0001–0003 connector and scheduler-boundary stack, not on the adjacent prefix-cache hook. Equivalent event names would be acceptable in another runtime. What matters is the anchored order: same accepted claim, offload, restore-required reuse, restore-before-reuse on success, and same-claim restoration failure becoming a claim-scoped fail-closed active outcome on failure. This mechanism is not native/upstream vLLM support. It is not scheduler-native pre-admission refusal, and it is not a production offload performance result. Its purpose is narrower and important: it demonstrates that the missing offload lifecycle/outcome obligations are implementable in a real connector path with scheduler-boundary invalid-load handling. What would make public runtimes native? Runtime family

Native evidence the checker would accept

TensorRT-LLM and SGLang/HiCache

Accepted claim identity, a materialization predicate, ordered lifecycle events, and claim-scoped outcomes. For offload, the trace must also expose restore-before-reuse and a restoration-failure outcome. Accepted claim identity, a materialization predicate, claim-scoped route cost, placement attribution, and later reuse success/failure attribution. Equivalent anchored evidence is enough; the checker requires obligation conformance, not the patch’s event names.

Dynamo-style routing

Any public runtime

8. Evaluation The evaluation answers four questions. The first two are matrix questions: does the checker reject false positives, and do studied runtimes natively satisfy the obligations under current public evidence? The second two are mechanism questions: can the missing offloadable semantics be implemented in a real runtime path, and is the mechanism stable in the tested setting with characterized artifact/analyzer costs but no production performance claim? Table 7: Evaluation questions and answers. Question

Evidence used

Answer

Does the checker reject false positives?

Generated matrix, bad-lowering counterexamples, descriptor provenance, independent TensorRT descriptor audit, and descriptor/evidence mutation controls.

Yes. Feature-only mappings and small evidence mutations remain approximate, rejected, unknown, or invalid unless the required obligations and observed atoms are present.

Question

Evidence used

Answer

Do studied runtimes natively satisfy the obligations under current public evidence?

TensorRT-LLM, SGLang/HiCache, and Dynamo descriptors plus boundary studies.

Can the missing offloadable semantics be implemented in a real runtime path?

Patched vLLM connector/scheduler-boundary run.

Is the mechanism stable in the tested setting?

131 repeated subprocess runs, 3 multi-claim attribution repetitions, and the common analyzer.

No native conformance is established. Public evidence supports substrates and selected adapter positives. Yes, at backend_patch depth: real in-process offload/load behavior carries claim metadata and same-claim restoration failure becomes a scheduler-boundary fail-closed active outcome. Yes for the local semantic gate: 131/131 subprocesses completed with valid event sequences, and 3/3 multi-claim repetitions attributed failure/refusal only to the target claim.

8.1 Matrix Evaluation The generated matrix contains no native_sound rows. This is expected. TensorRT-LLM and SGLang/HiCache produce selected adapter positives and many approximation rows. Dynamo routing produces approximation rows for routing/placement. The patched vLLM reference produces backend-patch witness rows only at backend_patch depth for represented state-machine and connector obligations. The matrix is regenerated from manually curated descriptors and mode obligations, not edited by hand. The bad-lowering suite separately checks feature-table false positives against the same checker. The positive rows also have an explicit provenance index. The generated companion files results/descriptorprovenance.* in the artifact, mirrored as studies/lowering/results/descriptor-provenance.* in this worktree, keep the full per-obligation anchor list. The compact version uses obligation codes so each row can be traced to the obligation bundle: I=claim_identity, A=explicit_acceptance, P=materialization_predicate, F=footprint_accounting, L=ordered_lifecycle_events, M=claim_materialized_event, D=claim_demoted_ before_loss, E=claim_expired_boundary, R=offload_restorability, RF=restoration_failure_outcome, V=victim_exclusion_before_violation, X=explicit_conflict_action, B=blocking_claim_ids, H=claim_ harm_attribution, T=claim_scoped_telemetry, and Pr=priority_influence. Descriptor provenance for positive rows.

Descriptor path

Mode / depth / evidence

capabilities/ sglang_hicache_ bbe9c7e.yaml

best_effort / telemetry_join / litmus_trace

capabilities/ tensorrt_llm_1_3_ 0rc14_container. yaml

best_effort / telemetry_join / litmus_trace

Anchor/result path

Obligations

Non-claim

results/sglang/ sglang_claim_ telemetry_ adapter_join_ summary.json; fresh repeat adapters/tests/ test_telemetry_ join.py; TensorRT L3 block-event summary

I, P, M, T

No native SGLang; no offloadable restoration outcome.

I, P, M, T

No native TensorRT; no hard/offloadable claim.

Descriptor path

Mode / depth / evidence

capabilities/ tensorrt_llm_1_3_ 0rc14_container. yaml

soft_priority / telemetry_join / litmus_trace