PaperlayerView exact revision on arXiv

Source-linked AI summary

Tokenized Key-Gated Adapter Routing: A Secure Access Control Mechanism Against Private Data Leakage in LLMs

Mohamed Shaaban, Mohamed Elmahallawy

arXiv:2610.00309v1cs.CRcs.AIcs.CL

TL;DR

Fine-tuning private data can expose PII, while existing defenses can trade utility against privacy and lack per-query control. LOCKET routes keyed requests to policy-specific LoRA adapters, and evaluations report reduced leakage with utility preserved under the corresponding key conditions.

  • Problem

    Fine-tuning on private data can expose memorized PII, while scrubbing and differential privacy can reduce utility and generally lack per-query access control.

    Source: §I · pp. 1–2

  • Method

    LOCKET trains policy-specific LoRA adapters and routes prompts to one adapter using a keyed token and a lightweight gating module.

    Source: §I · p. 2, A. LoRA Adapter Creation and Fine-Tuning · p. 5

  • Results

    Across datasets and LLMs, LOCKET substantially reduces measured PII leakage while preserving task utility, and its gating module achieves 100% adapter-selection accuracy in the evaluations.

    Source: §I · p. 2

  • Takeaways & Limitations

    LOCKET supports policy-controlled disclosure, preserving utility for authorized requests while mitigating PII leakage when tokens are absent or invalid.

    Source: §VI · p. 13

    The stated protection does not cover authorized key holders or stolen keys, and adaptive router probing and key-recovery attacks remain for future study.

    Source: §VI · p. 14

Abstract

from arXiv · show

Large language models (LLMs) are increasingly deployed in privacy-critical domains (e.g., healthcare, finance, and government), but their propensity to memorize and disclose personally identifiable information (PII) poses serious security and compliance risks. Existing defenses typically force a trade-off between model utility, privacy protection, and access to fine-tuned private knowledge. We propose LoRA-Oriented Control via Keyed Entry Tokens (Locket), a practical framework that embeds fine-grained, policy-driven access control directly into LLM generation. Locket trains a set of lightweight LoRA (Low-Rank Adaptation) adapters, each encoding a distinct access policy (e.g., full reveal, partial redaction via PII masking, or reveal under a specified differential privacy level). A compact gating module is trained to associate a learned keyed entry token with exactly one LoRA adapter via sequence-level hard routing; the presence of a valid token acts as an authorization key that unlocks corresponding private knowledge, while an invalid or absent token triggers a privacy-preserving adapter that redacts or sanitizes sensitive content. This design ensures Locket remains fully compatible with off-the-shelf LLMs, supporting scalable deployment while satisfying regulatory and privacy requirements. We evaluate Locket across multiple datasets (Enron, ECHR, Yelp) and a diverse set of state-of-the-art LLMs, including Qwen3 (1.7B and 8B), Meta's Llama-3.2 (1B and 3B), and Google's Gemma-2-2B. Our extensive experiments demonstrate that, when the correct token is provided, Locket preserves perplexity comparable to fine-tuning on raw data (without any defense). Conversely, when the token is missing or invalid, it substantially reduces PII leakage while maintaining utility and perplexity on par with strong baseline defenses.

I. INTRODUCTION

Fine-tuning private data can expose memorized PII, while scrubbing and differential privacy can reduce utility and generally lack per-query access control. LOCKET uses keyed tokens to route requests among policy-specific adapters; evaluations report reduced PII leakage while preserving utility.

A. Memorization Problem and PII Leakage

  • Fine-tuning private data can expose memorized PII, creating confidentiality risks in regulated domains.Scrubbing and differential privacy can degrade utility, and generally lack fine-grained per-query access control.Source: §I · pp. 1–2

I. INTRODUCTION

  • LOCKET routes requests using organization-specific keyed tokens to LoRA adapters that enforce reveal, masking, or differential-privacy policies.A valid key selects the corresponding adapter; absent or invalid keys route to a privacy-preserving adapter.Source: §I · p. 2

B. PII Mitigation Approaches

  • Across Enron, ECHR, and Yelp and five LLM variants, LOCKET reduces measured PII leakage while preserving task utility, with 100% adapter-selection accuracy in the reported evaluations.The evaluation includes extraction and membership-inference metrics, perplexity, and prompts containing embedded keys.Source: §I · p. 2
  • Prior work spans training-time privacy, preference alignment, unlearning, inference-time sanitization, and red-team evaluation; LOCKET targets per-request controlled disclosure at inference time.The introduction identifies limited empirical validation and practical deployment for token-gated access control and cryptographically regulated disclosure.Source: B. PII Mitigation Approaches · pp. 2–3

III. BACKGROUND AND THREAT MODEL

Fine-tuning adapts pretrained models to labeled tasks, but full-parameter updates can be costly and complicate rollback and auditing. The section contrasts mixture-of-experts routing with LoRA, a parameter-efficient alternative that supports modular policy adapters.

1) LLM Fine-Tuning:

  • Fine-tuning uses labeled input-output sequences and typically minimizes token-level cross-entropy, but full-parameter updates can be costly and complicate rollback and auditing.The passage frames fine-tuning as adapting a pretrained model on a dataset of input sequences and target outputs.Source: 1) LLM Fine-Tuning · p. 3
  • Mixture-of-experts routing selects and combines a subset of expert outputs, offering sparse computation and specialization but often requiring base-model changes.The passage also notes added complexity for per-organization policy enforcement and secure deployment.Source: 1) LLM Fine-Tuning · p. 3
  • LoRA represents weight updates with low-rank factors while keeping the base model frozen, enabling small, independently versioned policy adapters.The passage identifies low inference overhead, simpler rollback and auditing, and compatibility with token-gated routing as advantages.Source: 1) LLM Fine-Tuning · pp. 3–4

2) Defense Mechanisms for PII in LLMs:

The section describes scrubbing and differential privacy as ways to mitigate PII leakage, then specifies an adversary model covering API queries, auxiliary information, and key knowledge. It distinguishes unauthorized access from valid-key access and insider misuse.

2) Defense Mechanisms for PII in LLMs:

  • Data scrubbing transforms sensitive training text through masking, deletion, generalization, or perturbation to reduce downstream extraction risk.Detection may combine patterns, named-entity recognition, and task-specific heuristics.Source: 2) Defense Mechanisms for PII in LLMs · p. 4
  • Differential privacy bounds sensitivity to one record’s inclusion or exclusion; DP-SGD clips per-example gradients and adds calibrated Gaussian noise.Noise and clipping determine the resulting privacy parameters through composition and accounting.Source: 2) Defense Mechanisms for PII in LLMs · p. 4

B. Threat Model

  • The threat model allows black-box API access, adaptive queries, and auxiliary information, while withholding model weights, activations, and training data.Adversary goals include PII extraction, reconstruction or candidate ranking, membership inference, and downstream exploitation.Source: B. Threat Model · p. 4
  • Without a valid key, requests use the defended adapter; stolen-key access is served by the revealing adapter until revocation, while authorized-insider misuse is out of scope.The model also excludes access to weights and server-side logs from the adversary’s observations.Source: B. Threat Model · p. 4

IV. METHODOLOGY

LOCKET combines policy-specific LoRA adapters, keyed entry tokens, and a compact router to enforce per-request access control without changing base-model weights. Adapters are trained on raw or defended data views, then selected through discrete routing at inference.

IV. METHODOLOGY

  • LOCKET uses low-rank adapters, organization-specific keyed tokens, and a compact gating module for discrete, per-request adapter selection.The base model remains frozen, and sensitive knowledge is isolated in adapter artifacts.Source: §IV · pp. 4–5
  • A keyed token is registered for an adapter or access group, and hard-argmax routing selects one adapter; absent or invalid keys select a privacy-preserving adapter.At runtime, the router processes the prompt first and the selected adapter is then activated for generation.Source: §IV · p. 5

A. LoRA Adapter Creation and Fine-Tuning

  • Adapters for each access tier are fine-tuned on raw or defended data views, with defended data produced by PII detection and transformations such as masking or substitution.The framework creates revealing adapters from raw data and defended adapters from transformed data.Source: A. LoRA Adapter Creation and Fine-Tuning · p. 5
  • Adapters may be trained independently for isolation and auditing or jointly for faster convergence, and checkpoint selection considers both perplexity and leakage proxies.The described recipes use AdamW and typically rank r = 8 unless otherwise stated.Source: A. LoRA Adapter Creation and Fine-Tuning · pp. 5–6

B. Keyed-Entry Token Construction

LOCKET represents each organization’s authorization key as a deterministic special token and uses a compact router to select one policy-specific LoRA adapter. The router selects from the key-derived representation, not later prompt content, and is trained to make confident decisions while defaulting invalid keys to a secure adapter.

B. Keyed-Entry Token Construction

  • Each organization’s key is registered as one local-tokenizer vocabulary entry, while a public tokenizer omits keys to reduce accidental exposure through shared tooling.The keyed embedding is deterministically initialized from the key and remains frozen; the base-model weights are also frozen during router training.Source: B. Keyed-Entry Token Construction · p. 6

C. Gating-Module Training (Sequence-Level Hard Routing)

  • LOCKET’s sequence-level routing applies one privacy-policy adapter to the whole request, rather than routing tokens to experts for capacity or task specialization.The paper distinguishes this model-level access control from task- or domain-conditioned adapters and external role-based permission checks; those mechanisms can complement LOCKET.Source: C. Gating-Module Training… · pp. 6–7
  • The router reads the keyed token’s position-1 hidden state, so later prompt content cannot change the selected adapter.Because the key follows BOS and attention is causally masked, the routing decision depends only on BOS and the key token.Source: C. Gating-Module Training… · pp. 6–7
  • The router is trained as supervised adapter classification with cross-entropy and an entropy penalty that encourages decisive selections.The study selected hidden state alone over input embedding alone or their combination because it produced lower gating entropy and improved selection accuracy.Source: C. Gating-Module Training… · p. 7
  • Training examples include valid keys, corrupted or missing keys, vocabulary-wide no-key inputs, and hard negatives; invalid keys fall back to a designated secure adapter.This covers tokenization edge cases and first-token inputs because the router bases its decision on the keyed-token position.Source: C. Gating-Module Training… · p. 8

D. Inference and Enforcement

LOCKET separates adapter selection from generation in a two-pass inference process. It computes a routing decision from the prompt and key, then removes the key and generates with the selected adapter.

D. Inference and Enforcement

  • The gating pass processes the prompt and key to select an adapter; the adapter pass removes the key and generates using that adapter.This separation avoids basing selection on representations already modified by an adapter, preserving deterministic routing.Source: D. Inference and Enforcement · p. 8
  • Only one adapter is activated per request, so generation costs the same as a single LoRA-adapted model, with the gating pass adding under 4% to end-to-end latency.The gating pass runs once per request using a frozen-base-model forward evaluation followed by a lightweight MLP.Source: D. Inference and Enforcement · p. 8
  • Training uses corrupted or truncated keys and other perturbations, while missing or invalid keys deterministically fall back to a designated secure adapter.The secure adapter may be masked, scrubbed, or DP-constrained.Source: D. Inference and Enforcement · p. 9

V. PERFORMANCE EVALUATION

The evaluation spans three datasets with potentially sensitive content, five LLM configurations, and extraction, inference, and membership-inference attacks. It reports both utility and privacy-related measures, including perplexity and attack performance.

A. Experimental Setup

  • The benchmarks are Enron email, ECHR legal-case text, and Yelp reviews, covering different sources of potentially sensitive information.The descriptions identify naturally occurring PII in Enron, personal and contextual case information in ECHR, and user and business identifiers in Yelp.Source: A. Experimental Setup · p. 9
  • The evaluated models are Gemma-2-2B, Llama-3.2-1B and 3B, and Qwen3-1.7B and 8B, adapted with LoRA.Each adapter uses rank 8, scaling factor 16, dropout 0.05, and 10 training epochs on 5,000 examples per dataset.Source: A. Experimental Setup · p. 9
  • Evaluation covers candidate-ranking inference, PII extraction, and membership inference, alongside perplexity and PII precision and recall.Membership inference reports AUC and TPR at 1% false-positive rate; attack metrics may be evaluated across query budgets.Source: A. Experimental Setup · p. 9

B. Evaluating LOCKET Against Baselines

Across the reported inference and extraction attacks, LOCKET’s key condition changes access to revealing behavior: correct keys permit greater inference success, while invalid or absent keys reduce sensitive-entity reproduction. Results also vary by model and dataset.

B. Evaluating LOCKET Against Baselines

  • On ECHR with 50 candidates, inference accuracy with a correct key was ≈46.0% for Llama-3.2-3B, ≈52.6% for Qwen3-8B, and ≈65.8% for Gemma-2-2B.Under wrong/no-key conditions, the corresponding accuracies were ≈11.6%, ≈7.5%, and ≈6.3%; Table I covers candidate sizes 50 and 100 across datasets and models.Source: B. Evaluating LOCKET Against Baselines · p. 10, Table I · p. 10
  • Under invalid or absent keys, extraction recall falls sharply, indicating reduced reproduction of ground-truth PII even though occasional generated tokens may still be correct.Precision is generally high across models and access conditions; Table II reports precision and recall averaged over attack trials.Source: B. Evaluating LOCKET Against Baselines · p. 10, Table II · p. 10
  • Gemma shows relatively low direct-extraction vulnerability but remains susceptible to candidate-ranking inference when a correct key or contextual cues are present.The passage distinguishes defenses against verbatim reproduction from those that reduce probabilistic preference for ground-truth candidates.Source: B. Evaluating LOCKET Against Baselines · p. 10
  • Larger models tend to achieve higher attack success with a correct key, while ECHR generally yields higher inference and extraction success than Yelp, with Gemma as the stated exception.The authors relate the domain pattern to legal text containing exploitable PII and stronger contextual cues.Source: B. Evaluating LOCKET Against Baselines · p. 10

C. Evaluating LOCKET In-depth

Across attack settings, LOCKET routes correct keys to revealing adapters and wrong or missing keys to defended adapters, reducing unauthorized PII leakage. Results also show that leakage depends on the chosen defense and evaluation conditions.

Defense variants

  • With correct keys, inference accuracies remain identical across defenses at 29.41%, 19.35%, and 10.0% for candidate sets of 50, 100, and 500; the hybrid defense lowers wrong-key accuracy at sizes 50 and 500.At 500 candidates, the hybrid adapter reaches up to 2.3× lower wrong-key accuracy than DP alone.Source: C. Evaluating LOCKET In-depth · p. 11
  • Under wrong/no-key conditions, the hybrid scrubbing+DP adapter yields extraction precision 11.5× below scrubbing alone and 1.7× below DP alone, with similar recall.The paper attributes the scrubbed adapter’s increased precision under wrong/no key to fewer outputs and coincidental matches; adding DP dampens this effect.Source: C. Evaluating LOCKET In-depth · p. 11

Query-budget variation

  • Across a thirty-fold query-budget increase from 500 to 15,000 generations, correct-key extraction grows from 3 to 46 PII strings, while wrong-key extraction stays between 0 and 3.Routing was correct in every run.Source: C. Evaluating LOCKET In-depth · p. 11

Membership inference

  • Wrong-key membership-inference AUC falls to 0.628/0.629 with scrubbing and 0.503/0.502 with DP, while correct-key AUC is 0.689 LOSS and 0.670 reference.The router selected the intended adapter for 100% of queries.Source: C. Evaluating LOCKET In-depth · p. 11

Multi-dataset authorization

  • Correct keys yield 29.41% ECHR, 28.89% Yelp, and 40.62% Enron inference accuracy; wrong/no-key leakage tops out at 11.69%, 6.90%, and 8.00%, respectively.Routing achieved 100% adapter-selection accuracy on the test set.Source: C. Evaluating LOCKET In-depth · p. 12

Rank and corpus-size impact

  • Correct-key inference accuracy rises from 19.61% at LoRA rank 4 to 34.55% at rank 16, while wrong/no-key accuracy remains between 3.64% and 9.26%; routing stays at 100% across corpus fractions.Correct-key perplexity saturates by 25% of the ECHR corpus, and wrong-key perplexity and inference accuracy show no upward trend.Source: C. Evaluating LOCKET In-depth · p. 12

Computational footprint and modularity

  • Two adapters and a gating module add 0.79–1.34% to base parameters, while a two-adapter deployment adds about 66 MB of policy artifacts and at most 64 MB of resident memory.The defended adapter can be updated without modifying the base model or gating logic.Source: C. Evaluating LOCKET In-depth · pp. 11–12

D. Routing Invariance and Injection Resistance

The routing tests report that prompt content cannot change adapter selection, and the prototype chatbot demonstrates keyed access to revealing or defended responses. The conclusion presents LOCKET's scope and notes security boundaries that remain.

D. Routing Invariance and Injection Resistance

  • All 3,922 stress-test prompts route to the intended adapter with probability 1.0000, and a sweep of 128,259 vocabulary tokens finds only the key selects the revealing adapter.The tests include paraphrases, other domains and languages, jailbreak templates, corrupted or displaced keys, and injected genuine keys.Source: D. Routing Invariance and Injection… · pp. 12–13

E. Evaluating LOCKET on Our Developed Chatbot

  • In the chatbot examples, correct keys produce context-aware revealing responses, while incorrect keys route to the defended adapter and replace protected entities with [MASK].The demonstrations use Llama-3.2-1B on ECHR and Qwen3-8B on Yelp.Source: E. Evaluating LOCKET on Our Developed… · p. 13

VI. CONCLUSION AND FUTURE WORK

  • The conclusion reports that LOCKET preserves utility and comparable perplexity with authorized tokens while mitigating PII leakage when tokens are invalid or absent across the evaluated datasets and models.Its modular policies range from full disclosure to differential-privacy-based controls.Source: §VI · p. 13
  • Protection is bounded by the defended adapter's training defense and does not extend to an authorized or stolen key; adaptive probing and key-recovery attacks remain unstudied.The paper identifies key rotation as the remedy for a stolen key.Source: §VI · pp. 13–14

APPENDIX A HASH-BASED KEY EMBEDDING INITIALIZATION AND

The appendix describes authorization tokens as private special tokens and outlines deterministic key-embedding initialization. It gives a key-space entropy estimate and explains why recovering the original authorization string from its embedding is intended to be infeasible in practice.

Key representation

  • Authorization tokens are special length-L strings over an alphanumeric alphabet, excluded from the public tokenizer and stored in hashed form in each organization's private tokenizer.The public tokenizer can be shared externally.Source: PRACTICAL NON-INVERTIBILITY · p. 16

Embedding initialization

  • The initialization procedure derives a shared seed from the key-token set, computes token-specific and final seeds, then samples each key embedding from the combined seed.The text describes deterministic initialization and practical non-invertibility.Source: PRACTICAL NON-INVERTIBILITY · p. 16

Key-space size

  • With 20 alphanumeric characters drawn from an alphabet of 62, the implementation estimates key entropy at approximately 119 bits.The stated brute-force success bound depends on the adversary's number of guessing attempts.Source: PRACTICAL NON-INVERTIBILITY · p. 16

Practical non-invertibility

  • The embedding is described as computationally infeasible to invert because it is a pseudorandom function of a seed derived from a fixed-length portion of the key's MD5 digest.The text says truncation discards information about the original key string.Source: PRACTICAL NON-INVERTIBILITY · p. 16

APPENDIX B SYNTHETIC ROUTING DATA AND GATING AUGMENTATION

Appendices B–D describe authorization-key routing data, measure gating latency, and quantify the parameter, training, and memory costs of deployment. They characterize LoRA as a modularity and isolation substrate, not as a claim of improved task accuracy.

APPENDIX B SYNTHETIC ROUTING DATA AND GATING AUGMENTATION

  • The gating dataset includes valid keys, malformed or corrupted keys, empty key fields, and prompts with no key, to train default secure fallback behavior.The appendix documents the routing data; behavior outside that data, including injection and vocabulary-sweep conditions, is evaluated separately in Appendix F.Source: Appendix B · pp. 16–17

APPENDIX C RUNTIME COST OF THE GATING MECHANISM

  • At 4,096 tokens, truncated gating stays near 18 ms versus 79 ms for naive gating, a 4.4× reduction.The naive pass rises from 19 to 79 ms as prompts grow; the truncated pass uses only the prefix through the keyed token, with identical routing decisions.Source: Appendix C · p. 17, Table VII · p. 17
  • Under 4% end-to-end latency overhead, the gate still accounts for 42%–50% of time-to-first-token across batch sizes.The gating pass runs once before generation; Table VIII reports both latency measures.Source: Appendix C · p. 17, Table VIII · p. 17

APPENDIX D COMPUTATIONAL FOOTPRINT

  • A two-adapter deployment plus gate adds 0.8–1.3% of the base-model parameter count, with relative cost decreasing as model scale grows.The gate itself is 0.60–0.97× the size of one LoRA adapter.Source: Appendix D · p. 17, Table IX · p. 17
  • Adapter training takes 1.5 h at 1 B and 3.7 h at 3 B; DP-SGD adds per-step cost only to the defended adapter.The two adapters train independently and can run in parallel; the DP cost does not affect the revealing adapter, gate, or inference latency.Source: Appendix D · p. 17, Table X · p. 17
  • A two-adapter, one-gate deployment requires about 66 MB of policy artifacts; resident-memory overhead is 43 MB in bf16 and 64 MB under 4-bit quantization.Both resident-memory figures are under 7% of the base weights.Source: Appendix D · pp. 17–18
  • LOCKET uses LoRA for modularity and isolation rather than claiming accuracy gains, and its keyed routing also applies to fully fine-tuned policy models.Sensitive knowledge is confined to swappable, revocable artifacts; organizations may use fully fine-tuned policy models instead.Source: Appendix D · p. 18

APPENDIX E DIFFERENTIAL PRIVACY CONFIGURATION

Appendix E specifies the DP adapter’s training guarantee and its boundaries; Appendix F tests whether prompt content or non-key opening tokens can alter adapter routing. The tests report consistent routing across the evaluated prompts and vocabulary sweep.

APPENDIX E DIFFERENTIAL PRIVACY CONFIGURATION

  • The DP-SGD adapter uses C = 1.0, σ = 0.51, q = 0.0064, and 10 epochs, yielding (ε, δ) = (8.03, 2 × 10^-4) under the PRV accountant.Source: Appendix E · p. 18
  • The DP guarantee covers example-level privacy for trainable adapter parameters, not LOCKET’s system outputs; routing is deterministic and consumes no privacy budget.The base model is frozen, and one training record is the privacy unit.Source: Appendix E · p. 18

APPENDIX F ROUTING INVARIANCE AND INJECTION RESISTANCE: FULL

  • All 3,922 tested prompts routed as intended with selected-adapter probability 1.0000, including 80 injected prompts routed to defend and 40 with the correct key at position 1 routed to reveal.The tests varied prompt bodies, key conditions, injection placements, and prompt lengths; Table XI summarizes the routing outcomes.Source: Appendix F · p. 18, Table XI · p. 19
  • Only the key among 128,259 vocabulary tokens routed to the revealing adapter; the other 128,258 routed to the defended adapter with p ≥0.993.The vocabulary sweep is described as a release check for each gate; no confidence threshold was needed for these results.Source: Appendix F · pp. 18–19, Table XII · p. 19

APPENDIX G CORPUS-SIZE ABLATION

Across reduced-corpus, query-budget, and membership-inference evaluations, LOCKET maintained key-based routing while the defended adapter limited unauthorized leakage. The membership protection varied with the defense used to train that adapter.

APPENDIX G CORPUS-SIZE ABLATION

  • Across ECHR training fractions from 10% to 100%, routing remained 100% correct, while wrong-key perplexity and inference accuracy showed no upward trend as data grew.Correct-key perplexity improves from 8.38 at 10% to 5.98 at 25%, within 3% of the full-corpus value; authorized utility degrades below 25% of the corpus.Source: Appendix G · p. 20, Table XIII · p. 20

APPENDIX H EXTRACTION LEAKAGE VERSUS QUERY BUDGET

  • With 500 to 15,000 generations, correct-key PII recovery rises from 3 to 46 strings, while wrong-key recovery stays between 0 and 3.Wrong-key recall is at most 0.49%, and routing to the intended adapter is 100% in all runs.Source: Appendix H · p. 20, Table XIV · p. 20

APPENDIX I MEMBERSHIP INFERENCE: FULL RESULTS

  • Under wrong keys, DP AUC falls to 0.503 and 0.502, while scrubbing yields 0.628 and 0.629; correct-key AUC remains 0.689 (LOSS) and 0.670 (reference).The DP wrong-key AUC is near random guessing; the correct-key rows are identical across defense configurations because only the defended adapter differs.Source: Appendix I · pp. 20–21, Table XV · p. 21
  • The wrong-key membership gap reflects the defended adapter’s training: scrubbing leaves membership signal in non-PII tokens, whereas DP-SGD reduces it to chance.LOCKET routes unauthorized requests to the defended adapter, so the membership leakage available to them is that of the selected defense.Source: Appendix I · p. 21
Loading 2610.00309v1…