Source-linked AI summary
Uncovering and Understanding Hidden Dependencies in the LLM API Reseller Ecosystem via Prefix-Cache Side Channels
Zimo Ji, Xin Wei, Congying Xu, Wenyuan Jiang, Xin Yang, Zongjie Li, Yudong Gao, Shuai Wang
TL;DR
Multi-level resale obscures dependencies among LLM API resellers, limiting visibility into risks created by shared upstreams. CacheTracer uses prefix-cache reuse as an API-only side channel to measure shared cache reach, finding widespread sharing and deep, concentrated structures across real-world endpoints.
Problem
Existing research provides little visibility into hidden dependencies created by multi-level resale among LLM API resellers, despite associated confidentiality and integrity risks.
Method
CacheTracer exploits prefix-cache reuse as an API-only side channel to measure shared cache reach and containment among reseller endpoints.
Results
37.1% of measured endpoint pairs show shared cache reach, while the containment order spans seven layers and one cache reach is contained within at least 31 others.
Takeaways & Limitations
Seemingly independent resellers can rely on common hidden upstreams, creating potentially large ecosystem-level confidentiality and integrity blast radii.
Takeaways & Limitations
CacheTracer recovers an under-approximation: unreported cache-containment relations remain unknown rather than absent.
Abstract
from arXiv · showhide
LLM API resellers have become an important access layer to modern LLM services. However, multi-level resale creates an opaque supply chain: a user's request may traverse undisclosed upstream resellers, each of which can inspect or modify prompts and responses, inducing ecosystem-level confidentiality and integrity risks. Existing studies audit individual resellers, but provide little visibility into hidden dependencies across resellers. We present CacheTracer, the first API-only measurement of such hidden dependencies. Our key insight is to exploit prefix-cache reuse as a side channel to measure dependency via cache-reach relations. CacheTracer operationalizes this insight with two primitives: Flood populates fresh cache state through one endpoint, and Prove probes whether another can reuse it while excluding probe-created hits. We then conduct a real-world measurement study with CacheTracer on 39 reseller endpoints, sending 1.1 million API requests across 636 endpoint pairs. Our measurements reveal a deep, concentrated cache-reach structure: 37.1% of measured pairs exhibit shared cache reach, the containment order spans seven layers, and one cache reach is contained within at least 31 of other nodes. We further find that the recovered structure is model-specific. We also evaluate the validity of CacheTracer through both real-world consistency checks and controlled experiments. The results show its high reliability and accuracy. These findings reveal substantial hidden dependencies among seemingly independent API resellers. Such deep and concentrated dependencies can create a large potential blast radius, where a confidentiality or integrity failure along a common upstream path may affect users across multiple downstream resellers.
I. INTRODUCTION · II. BACKGROUND AND KEY OBSERVATION · A. Provider-side cache isolation
The paper introduces CacheTracer, an API-only method that exploits prefix-cache reuse to uncover hidden cache dependencies among LLM API resellers. Measurements reveal a deep, concentrated, model-specific cache-reach structure while preserving one-sided under-approximation under telemetry uncertainty.
- II. BACKGROUND AND KEY OBSERVATION: Prefix-cache reuse makes shared cache reach externally observable, and multi-level resale can make the resulting cache-reach signal directional.A fresh prefix cached through one endpoint and later reused through another provides evidence that both reach a common cache domain.
- I. INTRODUCTION: CacheTracer uses FLOOD to populate fresh cache state through one endpoint and PROVE to test whether another endpoint can consistently reuse it.FLOOD repeatedly sends a fresh prefix until it likely covers nearly all of the first endpoint’s routing mass; PROVE then probes the second endpoint.
- I. INTRODUCTION: 39 reseller endpoints and 636 endpoint pairs were measured using 1.1 million API requests, revealing widespread shared cache reach and a deep, concentrated structure.After equivalent cache reaches are contracted, the study reports 34 nodes in the containment order.
- I. INTRODUCTION: Cache-reach containment spans seven layers, with one node’s cache reach contained by at least 31 other nodes.This pattern is consistent with multi-level sourcing and extended trust paths, but does not measure commercial hop count.
- I. INTRODUCTION: Only two of 22 decisive retests retained cache-reach containment on a second model, showing that the recovered structure is model-specific.The second-model retests directly test whether observed containment persists across models.
- A. Provider-side cache isolation: Provider-side cache isolation partitions cache domains by coarse tenancy identifiers and stores cache in chunks, preventing reuse across tenants on the same physical instance.The reported cached_tokens field exposes reused prefix length, while production systems reuse KV state across requests sharing token prefixes,,,,.
- A. Provider-side cache isolation: A HIT requires reported cached-token reuse of the planted prefix, whereas transport errors and timeouts are excluded from cache-state classification.Cache Telemetry integrity assumes that the reported count reflects genuine reuse of state deposited by the earlier request.
- A. Provider-side cache isolation: Telemetry misreporting that suppresses hits can remove true relations but cannot create spurious ones, preserving CacheTracer’s under-approximation.The customer observes an API field rather than the cache itself, so this assumption is necessary for interpreting hits as shared-infrastructure evidence.
B. Reseller-side load balancing · C. How reseller routing exposes the cache channel · D. Threat and measurement model
The paper models reseller endpoints as load-balanced, credential-translating gateways whose routing exposes directional cache-reach relations. CacheTracer measures these relations probabilistically under routing-stability assumptions, using only observations available to an ordinary paying customer.
- B. Reseller-side load balancing: Resellers reissue customer requests upstream with reseller-controlled credentials, replacing the customer’s identity at each resale hop.OpenAI-compatible gateways separate customer-facing tokens from provider-facing channels, and this replacement repeats when an upstream is itself a reseller.
- B. Reseller-side load balancing: Multiple upstream channels, weighted selection, retries, load balancing, and fallback can send repeated requests through different provider-side cache domains.Thus, endpoint-level observations aggregate traffic across upstream credentials and cache namespaces.
- B. Reseller-side load balancing: CacheTracer assumes successful requests during a measurement window are independent samples from a fixed routing distribution whose cached-prefix behavior does not systematically alter that distribution.Temporal stability supports estimating routing mass from hit and miss sequences, while prefix invariance permits different probe prefixes to characterize the same endpoint.
- C. How reseller routing exposes the cache channel: If a downstream endpoint forwards traffic through an upstream endpoint, every cache domain reachable through the upstream is also reachable from the downstream, yielding monotone cache-domain containment.Formally, if vd forwards some traffic through vu, then P(vu) ⊆ P(vd).
- C. How reseller routing exposes the cache channel: Flooding an upstream endpoint can make every subsequent probe there hit, whereas flooding a downstream endpoint produces hits upstream only at the fraction of downstream routing mass selecting the covered subset.This asymmetry exposes directional cache-reach containment without crossing provider-side cache-isolation boundaries.
- C. How reseller routing exposes the cache channel: Cache-reach containment is defined by coverage probability: at δ = 0.05, vy ⪯ vx when at least 95% of vy’s routing mass hits state planted through vx.The relation concerns routing mass rather than literal cache-domain inclusion.
- C. How reseller routing exposes the cache channel: The δ = 0.05 resolution balances measurement precision against request volume, duration, cache-domain redistribution, and cache-state expiration that can create transient misses.Tighter thresholds require longer hit sequences and may increase operational and temporal noise.
- D. Threat and measurement model: The measurer is an ordinary paying customer using low-privilege endpoint credentials, observing responses, metadata, errors, and timing without controlling infrastructure or accessing other tenants’ data.Prompts contain synthetic padding and fresh nonces, preventing exposure of another customer’s data.
III. CACHETRACER … C. FLOOD: covering one endpoint’s cache reach
CacheTracer converts directional cache-reach signals into a practical API-only framework that recovers pairwise relationships and assembles a global structure. Its PROFILE and FLOOD primitives prioritize informative endpoint pairs and cover an endpoint’s hidden cache reach despite unobservable cache domains and changing cache state.
- III. CACHETRACER: CACHETRACER addresses unenumerable cache domains and probe-induced cache changes through five primitives that progressively recover pairwise cache-reach relationships.The framework takes candidate reseller endpoints and converts pairwise cache observations into a global cache-reach structure.
- A. Method overview: PROFILE uses lightweight latency profiles to prioritize endpoint pairs whose testing order may expose short-range cache-reach relations first.It uses time to first token as a coarse path-length proxy and does not determine whether endpoints are related.
- B. PROFILE: prioritizing potentially adjacent pairs: PROFILE enables pruning of redundant long-range tests when previously discovered containment relations already imply them.If A ≺B and B ≺C are known, testing (A, C) can be skipped; PROFILE changes test order rather than deciding relatedness.
- B. PROFILE: prioritizing potentially adjacent pairs: PROFILE ranks endpoints by time to first token, treating nearby ranks as more plausible candidates for nearby relations.Additional forwarding and gateway processing can increase response latency, so TTFT is used only as a coarse proxy for path length.
- B. PROFILE: prioritizing potentially adjacent pairs: PROFILE orders candidate pairs by increasing rank distance, testing adjacent ranked endpoints before pairs separated by larger strides.For example, the order for (A, B, C, D) begins with (A, B), (B, C), and (C, D), then proceeds to larger separations.
- C. FLOOD: covering one endpoint’s cache reach: FLOOD repeatedly sends the same prompt through an endpoint until consecutive cache hits indicate that less than 5% of its routing mass remains uncovered.At δ = 0.05, 59 consecutive hits support this coverage condition, implying no individual uncovered cache domain accounts for 5% or more of the routing mass.
- C. FLOOD: covering one endpoint’s cache reach: FLOOD stops after N_flood consecutive hits, but fails after 1000 total attempts or eight consecutive errors.The stopping rule operationalizes the coverage target without requiring the cache domains behind the endpoint to be listed.
- C. FLOOD: covering one endpoint’s cache reach: FLOOD keeps the planted cache state warm with two low-rate background workers while PROVE runs, reducing the chance that it expires.The calibrated concurrency keeps the cache warm without frequently causing measurement failure from excessive requests.
D. PROVE: directional cache-reach test
PROVE measures directional cache coverage by probing whether endpoint B can reuse cache state planted through endpoint A. A prefix ladder prevents probe-created self-hits, while statistical thresholds classify containment, partial sharing, no observed sharing, or inconclusive outcomes.
- Goal and challenge: PROVE estimates directional coverage c(A, B) as the probability that a successful request through B reuses cache state planted through A.It performs one cache query within the directional FLOOD–PROVE procedure.
- Prefix ladder: A prefix ladder prevents self-hits by advancing after misses to previously unqueried, longer prefixes and requiring cached tokens to exceed reuse created by earlier probes.The prefix stride exceeds the provider’s cache-chunk length, so state created by one miss cannot satisfy the next hit threshold.
- Assumptions and bounds: The method assumes that changing prefixes does not systematically alter probe routing, and calibrates prefix lengths, stride, and cache-chunk length separately for each model.Timeouts consume prefixes but do not count as successful probes, hits, or misses; exhausting clean prefixes returns INCONCLUSIVE.
- Procedure and outcomes: PROVE returns CONTAINED, PARTIAL, NOOBSERVED, or INCONCLUSIVE based on observed hits, misses, clean-prefix exhaustion, and transport failures.CONTAINED supports cache coverage, PARTIAL establishes shared reach but rejects containment, NOOBSERVED observes no hit before termination, and INCONCLUSIVE covers other executions.
E. CLASSIFY: bidirectional pair classification
CLASSIFY performs independent fresh-prompt flood–probe tests in both directions to classify endpoint pairs by cache-reach relationship. The resulting containment indicates shared supply-chain connectivity but does not prove direct supplier relationships.
- Bidirectional classification: CLASSIFY runs independent fresh-prompt flood–probe tests in both directions before assigning a pair classification.An INCONCLUSIVE result in either direction leaves the pair unresolved.
- Bidirectional classification: Two CONTAINED outcomes yield a cache-reach equivalence class, while one CONTAINED outcome yields strict containment when the reverse direction rejects containment.
- Bidirectional classification: PARTIAL without containment records non-directional sharing, whereas two NOOBSERVED outcomes record no sharing at the chosen resolution.
- Containment versus supply: Cache-reach containment is evidence that endpoints may share a supply chain, but it does not establish a direct supplier relationship.Supply implies containment under monotonicity, but the converse is unavailable from cache observations because common upstream providers can produce containment without either endpoint supplying the other.
F. BUILDGRAPH: pruning and global assembly
BUILDGRAPH assembles pairwise cache-reach measurements into a global structure while pruning relations implied by recovered containment paths. It also represents non-directional sharing that may require latent cache-reach witnesses.
- Global assembly: BUILDGRAPH assembles the global cache-reach structure by processing PROFILE-prioritized candidate pairs and recording containment, clone, partial-sharing, or unresolved outcomes.It first ranks endpoints by TTFT, orders candidate pairs, skips implied relations, invokes CLASSIFY, and updates the corresponding graph or endpoint groups.
- Implication pruning: Containment-path pruning skips direct measurements whose relations are already implied, reducing request cost and cache perturbation without introducing new verdicts.For example, recovering A ≺B and B ≺C permits skipping A ≺C; the ordering therefore prioritizes plausibly short-range relations.
- Latent witnesses: PARTIAL outcomes capture shared cache reach without containment and may require SHADOWINSERT to represent latent witnesses outside the measured endpoints.Such sharing can also be explained by a common upper endpoint already present in the recovered containment structure.
IV. MEASUREMENT & EVALUATION
The evaluation investigates hidden cache-containment dependencies among real-world LLM API resellers, validates CacheTracer’s assumptions, and measures its accuracy against known ground truth.
- RQ1 Real-world Measurement: RQ1 characterizes cache-containment topology in the real-world reseller ecosystem, including variation across models and its security implications.The primary evaluation goal is to characterize hidden dependencies among real-world resellers.
- RQ2 Assumption Validation: RQ2 examines whether the cache-observation assumptions underlying CacheTracer are consistent with the measured systems.This assesses the validity of the underlying measurement methodology.
- RQ3 Controlled Evaluation: RQ3 evaluates how accurately CacheTracer recovers cache sharing and containment under known ground truth and what the recovered structure reveals about possible supply relations.The evaluation uses a controlled environment to measure CacheTracer’s accuracy.
A. Experiment Setup … 1) Measurement setup:
CacheTracer’s real-world study evaluates 39 publicly reachable reseller endpoints using ordinary OpenAI-compatible requests and a calibrated prefix-ladder measurement campaign. The study measures 636 of 741 candidate endpoint pairs over 7.2 hours using gpt-5-nano-2025-08-07.
- 1) Prompt construction:: Prompts combined the fixed text “Replay exactly OK” with a nonce, and reported input-token counts calibrated prompt lengths to measurement targets.
- 2) Reseller selection:: 39 publicly reachable reseller endpoints were selected from three discovery sources, then manually verified through registration, payment, and cached_tokens checks.Candidates came from FOFA scans, a community relay directory, and TokenAPI Scan; duplicate endpoints were removed before verification.
- 2) Reseller selection:: All measurements used ordinary OpenAI-compatible requests from one workstation without provider cooperation, privileged reseller access, or telemetry.
- 1) Measurement setup:: CacheTracer measured 39 selected resellers with gpt-5-nano-2025-08-07, chosen to reduce model-isolation risk, cost, latency, and routing changes.The low-cost model mitigates risks from undisclosed model substitution and shortens the measurement campaign.
- 1) Measurement setup:: Each measurement used a fresh 16,384-token prompt body and a prefix ladder beginning at 1,536 tokens with 256-token strides.These parameters exceed the measured 1,024-token cache-admission threshold and 64-token cache-chunk length, and were recalibrated for other models.
- 1) Measurement setup:: 636 of 741 unordered candidate endpoint pairs were measured over 7.2 hours, while 105 pairs were pruned during measurement.
2) How common is shared cache reach?: · 3) Depth and breadth of cache containment: · 4) Security implications:
CacheTracer finds shared cache reach across 37.1% of measured reseller pairs, with a seven-layer, highly concentrated containment structure. This topology implies correlated security exposure: a compromised upstream could read or modify sensitive downstream traffic across multiple resellers.
- 2) How common is shared cache reach:: 37.1% of measured reseller pairs exhibit shared cache reach, revealing hidden dependencies within the measured reseller ecosystem.236 of 636 pairs produced at least one authentic cross-endpoint hit and decisive coverage outcome; each such hit directly evidences access to a common cache domain under the tested assumptions.
- 3) Depth and breadth of cache containment:: The recovered cache-containment order spans seven layers, with a longest chain of six containment relations and 115 ordered node pairs in transitive closure.After contracting six CLONE verdicts, nine endpoints merge into four equivalence classes, leaving 34 nodes and 58 distinct containment relations.
- 3) Depth and breadth of cache containment:: All 26 directional tests involving E2 satisfy containment when counterparts are flooded, while reverse tests produce zero hits across 59 probes per pair.This shows E2’s cache domain is reachable through 31 endpoints but carries only a small share of traffic for most, consistent with a narrow supplier or shared tenancy.
- 3) Depth and breadth of cache containment:: At least 31 of the other 33 clone-contracted nodes contain one cache domain, establishing a conservative lower bound on cache-reach concentration.The domain is directly contained in 24 nodes and indirectly contained in 31; the next-largest upward closure contains 18 nodes.
- 4) Security implications:: Operators on shared cache paths can receive prompts and alter completions, including tool calls, creating confidentiality and integrity risks for nominally independent endpoints.Tool-using agents may expose retrieved records, persistent memory, inter-agent messages, credentials, and tool arguments through these requests.
- 4) Security implications:: A compromised shared upstream could expose sensitive context or corrupt tool-mediated actions across multiple downstream endpoints, expanding risk from one public endpoint to a cross-reseller concern.The recovered depth and concentration imply a potential blast radius larger than any individual endpoint.
5) Model dependence: … 1) Telemetry integrity:
CacheTracer’s topology is model-dependent, while its real-world measurement requires substantial but partially prunable cost. Validation further shows that cache telemetry is reliable for nearly all measured endpoints, with two exceptions excluded from aggregate results.
- 5) Model dependence:: Only 2 of 22 decisive reruns reproduce the original containment relation, indicating that cache-containment topology is model-dependent and should be indexed by model.The other decisive reruns show shared reach without containment or no detectable sharing; 22 additional reruns are inconclusive.
- 6) Measurement cost:: Approximately 1.1 × 10^6 requests over 7.2 hours measure the 39 real-world reseller endpoints, averaging 42 requests per second and 1,730 requests per directly measured pair.The requests include bidirectional measurements, repeated probe observations, and cache-maintenance traffic.
- 6) Measurement cost:: Among 741 candidate endpoint pairs, implication pruning avoids direct measurement of 105 pairs, or 14.2%, by inferring their relations from previously recovered containment relations.This mechanism reduces the repeated bidirectional probing otherwise required for candidate pairs.
- C. RQ2: Assumption Validation:: CacheTracer’s assumption checks use cache telemetry and repeated-request hit patterns across the same 39 reseller endpoints measured in RQ1.The validation targets the assumptions underlying cache-sharing and containment identification.
- 1) Telemetry integrity:: Using fresh nonces and previously unseen prompts, cold-prompt tests ensure that reported full-prefix hits cannot result from cache planted by the experiment.This procedure tests whether cached_tokens reflects an actual cache hit.
- 1) Telemetry integrity:: Among 5,059 usable observations from 5,997 cold-prompt requests, three endpoints lacked sufficient telemetry and the remaining endpoints produced 3 false hits at a rate of 5.9×10−4.A refreshed-prompt check with 1,660 additional observations reproduced one event at one endpoint and none at the other, yielding endpoint-level rates of 1/603 and 2/1270.
- 1) Telemetry integrity:: Cache telemetry is reliable for nearly all measured endpoints, so partial-sharing verdicts from two exceptions are excluded from aggregate results.This is the study’s stated validation finding.
2) Stable routing: · D. RQ3: Controlled Evaluation
CacheTracer’s routing model is broadly supported by real-world probability measurements, and controlled experiments show exact recovery of all tested cache-sharing topologies and their compositions.
- 2) Stable routing:: Across 21 real-world A ≺ B ≺ C chains, predicted and observed hit probabilities have median absolute deviation 0.084, with 14/21 agreeing within 0.10.Randomly permuting observed long-range values raises the median deviation to 0.449, while seven larger deviations indicate that the assumptions are approximations rather than invariants.
- 2) Stable routing:: Whole-prompt cache-domain pinning would sample unrelated routing populations across randomized floods and would not produce the observed agreement.The observed deviations may reflect temporary route changes, quotas, or alternative paths.
- 2) Stable routing:: The measured probabilities broadly follow the multiplicative relationship predicted by the routing model, supporting stable routing and prefix-invariant selection as reasonable approximations.Each probability uses a separate flood and fresh random prompt; the relationship treats C-to-A reach as C-to-B reach multiplied by B-to-A reach.
- D. RQ3: Controlled Evaluation: The controlled evaluation uses eight isolated-cache topologies with known reachability, including pairwise relations, representative three-node compositions, and an eight-node DAG stress case.The stress case uses 12 isolated domains, endpoint reachability up to ten domains, and a minimum terminal routing probability of approximately 8.57%, above the 5% resolution threshold.
- D. RQ3: Controlled Evaluation: Controlled experiments confirm that CACHETRACER distinguishes no sharing, equivalent reach, strict containment, and sharing without containment.These four outcomes are the pairwise relation classes returned by CLASSIFY.
- D. RQ3: Controlled Evaluation: CACHETRACER correctly recovers chain composition, fan-in, and a hidden shared ancestor, while implication pruning skips transitive containment.In the combined stress case, it also recovers all six direct observed relations and keeps overlapping maximal cliques as separate latent explanations.
- D. RQ3: Controlled Evaluation: CACHETRACER exactly recovers all 8/8 configured topologies, distinguishing four pairwise relations and preserving multi-hop, fan-in, pruning, and overlapping latent-sharing structures.Because each configured supply edge aligns with strict cache containment, exact containment recovery also recovers the configured supply graph.
V. DISCUSSION … ETHICS CONSIDERATIONS
CacheTracer provides a conservative, API-only view of hidden cache dependencies among LLM resellers, while distinguishing observable cache topology from the underlying commercial supply chain. The study also frames its contribution against prior side-channel, supply-chain, and tomography work and documents bounded, authorized measurement practices.
- V. DISCUSSION: CacheTracer’s recovered cache-containment structure is an under-approximation: reported relations are supported by directional measurements, while unreported relations remain unknown.Containment may remain unobserved when cache domains fall below resolution δ or routing varies during measurement.
- V. DISCUSSION: The recovered topology describes observable cache reaches among reseller endpoints, not the commercial supply graph; chain length therefore cannot be interpreted as intermediary count.A highly contained cache reach indicates concentration of observable cache reach, not necessarily commercial concentration.
- VI. RELATED WORK: Prior LLM supply-chain studies audit reseller behavior, model substitution, pricing, and malicious gateways, whereas CacheTracer infers hidden dependencies among endpoints.Related work also includes backend routers and cooperative model fingerprints [42],,.
- VI. RELATED WORK: CacheTracer repurposes authentic prefix-cache reuse as a relational infrastructure signal rather than a content leak, building on cache attacks and broader inference side channels [22], [45],,,.Related channels have exposed architecture, identity, or activity,,,,,,,,,.
- VI. RELATED WORK: Like network tomography, CacheTracer infers hidden topology from end-to-end observations, but external traces identify only an equivalence class without extra assumptions or vantage points,,,,,.CacheTracer replaces packet-path correlation with planted prefix state.
- VII. CONCLUSION: The paper presents CacheTracer as an API-only method that uses prefix-cache reuse to reveal shared cache reach and containment among reseller endpoints.Measurements on 39 real-world resellers found widespread sharing, deep dependency structures, and strong concentration, indicating that seemingly independent resellers may rely on hidden common upstreams.
- ETHICS CONSIDERATIONS: The study used paid accounts and synthetic prompts containing random padding and fresh nonces, without user data or attempts to recover other customers’ prompts.Requests used documented interfaces and ordinary customer capabilities; flooding was capped, errors quarantined, and 1.1 × 10^6 requests were sent over 7.2 hours across 39 endpoints.
- ETHICS CONSIDERATIONS: Endpoint identities were withheld under a pre-established disclosure policy because relations describe infrastructure during one model-specific measurement window, not observed commercial arrangements.Redacted endpoint information preserves the measurement’s shape without naming companies.
APPENDIX A MEASUREMENT BUDGET AND REQUEST COMPLEXITY … APPENDIX E INTERPRETING LATENT WITNESSES
The appendices quantify CacheTracer’s request complexity, document redacted endpoint and controlled-evaluation evidence, and examine cross-model persistence. They also clarify that latent witnesses represent unexplained sharing but cannot identify hidden commercial entities or internal structures.
- APPENDIX A MEASUREMENT BUDGET AND REQUEST COMPLEXITY: CacheTracer’s worst-case foreground request complexity is N + N^2(Bf + Nprove), reducing to O(N(Bf + Nprove)) when adjacent chain relations imply longer pairs.The realized cost depends on candidate-pair pruning and is reported empirically in §IV.
- APPENDIX B REDACTED ENDPOINT INDEX: Table III lists 34 Fig. 6 nodes with redacted commercial endpoints, preserving operator counts and domain-shape information needed to sanity-check the measurement.Domains are reduced to public suffixes and the final registrable-label character, with remaining characters block-redacted and subdomains removed.
- APPENDIX C DIRECTIONAL EVIDENCE FOR CONTROLLED EVALUATION: Table IV reports hit/miss observations from both FLOOD–PROVE directions for eight constructed topologies and the resulting CLASSIFY relation for each.The table provides directional evidence underlying the controlled evaluation in §IV-D.
- APPENDIX D CROSS-MODEL CONTAINMENT RELATIONS: Two reproduced cache-containment relations persist across gpt-5-nano-2025-08-07 and gpt-5.1, while only two decisive reruns reproduce the original relation.Figure 9 presents these two cross-model cases.
- APPENDIX E INTERPRETING LATENT WITNESSES: Latent witnesses are explanatory placeholders for unexplained shared cache reach, created from maximal cliques of unexplained PARTIAL pairs and never queried.Maximal cliques preserve overlapping explanations, including cliques that share endpoints but represent distinct structural explanations.
- APPENDIX E INTERPRETING LATENT WITNESSES: Latent witnesses are not identifiable: equivalent forwarding chains, co-tenant surfaces, or combinations can preserve visible cache-reach relations while differing internally.Their number and labels therefore do not identify hidden entities, and witnesses are excluded from observed-node, containment-edge, and cache-reach statistics.