Pith. sign in

REVIEW 5 major objections 5 minor 1 cited by

OneShield -- the Next Generation of LLM Guardrails

T0 review · 5 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read OneShield claims a model-agnostic, inference-time guardrail layer for LLMs whose parallel detectors bound total detection time by the slowest detector and whose Policy Manager applies customer- and jurisdiction-specific actions.

desk verdict A genuinely deployed guardrail framework with a sensible architecture, but its load-bearing performance claims are not backed by the evidence in the paper. read the letter →

arxiv 2507.21170 v2 pith:2SFTMJH4 submitted 2025-07-25 cs.CR cs.AIcs.CL

Chad DeLuca , Anna Lisa Gentile , Shubhi Asthana , Bing Zhang , Pawan Chowdhary , Kellen Cheng , Basel Shbita , Pengyuan Li
show 2 more authors
Guang-Jie Ren Sandeep Gopisetty
This is my paper · ORCID
classification cs.CRcs.AIcs.CL
keywords LLMguardrailsmodel-agnosticsafetyinference-timemoderationPIIdetectionpolicymanagerself-harmcontentInstructLab
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

OneShield is presented as a standalone, model-agnostic guardrail layer for large language models that operates live at inference time. The central claim is that a modular collection of small detectors—classifiers for risks such as self-harm, health advice, and inappropriate content; extractors for thirteen categories of personally identifiable information; and comparison detectors for text attribution and factuality—can run in parallel in front of any LLM, so total detection time is bounded by the slowest detector. A Policy Manager then consumes the aggregated findings and applies customer- and jurisdiction-specific templates such as blocking, masking, or allowing text. The paper reports per-detector evaluation results and deployment experience: OneShield has run internally since late 2023, handling thousands of daily requests, and has served as a bot that reviews pull requests in the InstructLab open-source project, flagging 8.25% of over 1200 pull requests as Code of Conduct violations.

What carries the argument

The load-bearing mechanism is the parallel containerized microservice layout. Each detector is a small, stateless service with one narrow task and a simple API; the OneShield Orchestrator dispatches text to all detectors at once and waits for every response before handing aggregated findings to the Policy Manager, so end-to-end detection time equals the maximum of the individual detector latencies rather than their sum. In the implementation described, the PII extractor is the slowest detector, averaging 0.521 milliseconds per prompt of up to 150 tokens. Detector internals are heterogeneous: classification detectors use BERT embeddings with either a sequence-classification head or a separable-convolution (SepCNN) head; PII extraction combines rules, regular expressions, and lightweight classifiers; and comparison detectors use vector-space search to narrow candidates before exact text-similarity matching. The Policy Manager is a separate inference-and-decision engine that encodes jurisdiction- and use-case-specific templates, such as GDPR versus CCPA treatment of PII, and decides actions at the aggregate level.

What would settle it

Re-annotate a random sample of the web-crawled training paragraphs with independent human labelers and compare against the URL-derived labels; substantial disagreement would falsify the training-pipeline assumption. Additionally, run an experiment in which one detector is slowed to several seconds while all others finish in milliseconds: if the orchestrator's end-to-end response time grows by more than the slowest detector's own runtime, the paper's latency guarantee is falsified.

Watch

Extended reading notes

Core claim

The paper's central claim is that OneShield constitutes a scalable, open, flexible, and model-agnostic architecture for a comprehensive guardrail layer for LLMs that operates live at inference time. It defines three detector families: classification detectors label text for risks such as health advice, self-harm, and inappropriate content; extractor detectors identify thirteen PII categories; comparison detectors match text against proprietary or verified corpora for text attribution and factuality checking. The architecture runs all detectors in parallel, and the paper asserts this guarantees that total detection time is no longer than the longest-running detector. Once all detectors report, the Policy Manager applies policy templates that can span detector findings, for example blocking text that combines a personal name with hateful content while allowing either alone. Reported results include an accuracy of 85.07% and F1 of 87.70% on the HeAL health-advice benchmark, a self-harm detector F1 of 96.49% on its test set, an adult-content classifier F1 of 93.80%, and a factuality detector F1 of 81.2% on a 2,000-point company-intelligence benchmark.

Load-bearing premise

The load-bearing premise is that the automatically produced labels for training data are accurate enough that detector scores generalize to production text; if the URL-based labeling and keyword selection are noisy or biased, the reported precision and recall will not hold in real traffic.

Editorial extensions

If this is right

  • Deploying OneShield in front of any LLM keeps guardrail behavior independent of the model, so safety updates do not require retraining or replacing the protected model.
  • Adding a new detector does not raise end-to-end latency unless that detector is slower than the current slowest one, making guardrail latency budgets predictable.
  • Policies that span detectors can enforce combination rules, such as blocking a detected name only when it co-occurs with hateful content.
  • Regulated organizations can vary their compliance posture across jurisdictions by selecting policy templates, without changing detector behavior.
  • The same detector stack can guard both live inference traffic and contributed training data, as demonstrated in the InstructLab pull-request vetting deployment.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Editorial inference: the stated parallel-latency guarantee holds only for healthy detectors; timeout and failure behavior of the orchestrator is not reported, so a natural extension is stress-testing total latency with one detector delayed or crashed.
  • Editorial inference: the paper's benchmarking tables evaluate detectors individually, so a direct comparison of the full OneShield stack against an end-to-end open-source guardrail suite on the same prompts would be a testable next step.
  • Editorial inference: because the weakly supervised web-crawled labels are not validated, an immediate reproducibility check is to re-annotate a random sample of those training paragraphs and measure label noise.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 5 minor

Summary. The paper presents OneShield, a modular and model-agnostic guardrail framework for LLMs, consisting of parallel detectors (classification, extraction, and comparison), a Policy Manager for templated actions, and an orchestrator. The authors describe the architecture, training procedures for several detectors, policy templates, scalability considerations, and a real deployment in IBM's internal platform and in the InstructLab open-source project. Evaluation results are reported for a self-harm detector, a health-advice detector, an inappropriate-content detector, and a factuality detector, along with usage statistics from the InstructLab deployment.

Significance. If the stated claims hold, OneShield would be a practically useful industrial guardrail framework: it is model-agnostic, containerized, supports CPU-only execution, runs detectors in parallel to cap latency at the slowest detector, and provides a policy layer decoupled from detection. The paper also documents a real deployment and gives quantitative results on a production-like setting (PR Insights). However, several load-bearing claims are not supported by the evidence presented: the PII outperformance claim has no benchmark table, the text-attribution method has no algorithm or evaluation, the weak-supervision pipeline is not validated, and the self-harm deployment metrics show a dramatic precision drop with likely circular labeling. These gaps currently prevent the paper from substantiating its central contributions of 'robust risk detectors' and reduced manual oversight.

major comments (5)
  1. [Section 4.1, Table 1] Table 1 reports self-harm detector precision of 96.04% on the internal test split but only 37.5%, 29.63%, and 35.29% on PR Insights context, question, and answer fields, respectively, while recall is 100% in all three production columns. This three- to four-fold degradation is not analyzed anywhere. Moreover, if the triage team only reviewed PRs flagged by the detector, then recall=100% and FNR=0.00% are definitional, making these deployment numbers unusable as validation. The paper must describe how PR Insights labels were obtained, report precision-recall tradeoffs under different thresholds, and discuss why the test-set F1 of 96.49% does not transfer to production. As written, Section 4.1 and Section 5's claim that OneShield 'significantly reduc[es] manual oversight' are contradicted by the detector's poor precision, which implies roughly two false positives per true positive.
  2. [Section 1, Section 3.1 (PII extractor)] The introduction claims 'we performed extensive benchmarking showing that it outperforms available state-of-the-art open-source PII detectors,' but the manuscript provides no benchmark table, no baseline names, no datasets, and no metric definitions for this comparison. Since the PII extractor is one of the three detector categories and is cited as a reason for OneShield's superiority, this load-bearing claim is unsupported. The authors should either add the benchmark results with baselines and dataset splits or explicitly weaken the claim.
  3. [Section 3.1 (weak supervision pipeline)] The classification detectors for health advice and inappropriate content are trained using web-crawled pages labeled by IBM X-Force's URL taxonomy, with TF-IDF keyword selection to identify paragraphs, and those paragraphs are treated as ground-truth training data. The paper gives no validation of this labeling pipeline, no estimate of label noise, no inter-annotator agreement, and no analysis of how selection bias from keyword filtering affects classifier generalization. Because this pipeline is the foundation for several reported F1 numbers, the authors should provide an evaluation of the weakly supervised labels (e.g., a manual audit of a sample) or otherwise justify their quality.
  4. [Section 3.1 (Text Attribution)] The Text Attribution detector is described only in prose: vector-space search narrows the scope and then text similarity is applied on a smaller portion of the data, but no algorithm, parameter settings, evaluation, or quantitative results are given. The paper states it was 'successfully used internally' without data. This is a major gap because comparison detectors are listed as one of the three detector categories and a named contribution. The authors should specify the matching method, evaluation protocol, and at least basic precision/recall or qualitative evidence against a defined benchmark.
  5. [Section 2.2 and Section 3.1 (benchmark independence)] Two key evaluation resources are internally authored or generated: the HeAL health-advice benchmark [2] is authored by members of this team, and the PR Insights benchmark is internally generated from the same InstructLab deployment that OneShield monitors. This does not by itself invalidate the results, but the paper does not acknowledge the potential circularity or discuss it as a limitation. To support external validity, the authors should include at least one benchmark from an independent source for each reported detector metric, or explicitly discuss the risk of overfitting to internally constructed labels.
minor comments (5)
  1. [Section 2.1] There are several typos and grammatical issues, e.g., 'sentence transformers embeds the prompt', 'LLamaGuard' (inconsistent capitalization), and 'this solution do not provide granular predictions'.
  2. [Section 3.3] The reported average response time of 0.521 milliseconds for the PII extractor on prompts up to 150 tokens seems implausibly low for a model-based service; the paper should specify the hardware, the number of tokens, whether this includes network/overhead, and the distribution (e.g., percentiles) rather than only the mean.
  3. [Section 4.1] The text has typos such as 'unathorizez', 'deplyed', and 'potential potential violations'. Also, the claim that the detectors were run on '1200+ PRs' should report how many PRs were actually flagged and how the 8.25% confirmed violation rate was computed (percentage of all PRs or of flagged PRs?).
  4. [Section 2.2] The list of datasets is long but not all are used in the experiments; for example, ALERT, SALAD-Bench, and StrongREJECT are listed but no detector is evaluated on them. Please state explicitly which datasets are used for training versus evaluation for each detector, to avoid implying unused resources.
  5. [Table 1] The column label 'False Positive Ratio' is ambiguous; it is presumably the false positive rate, but it should be defined, and the relationship between this ratio and precision should be stated (e.g., at the reported operating point).

Circularity Check

1 steps flagged · score 6.0 of 10

PR Insights deployment metrics are circular by construction: recall=100% and FNR=0.00% follow from the flag-and-confirm labeling protocol; the OneShield architecture itself is not circular.

  1. self definitional [Section 4.1 (OneShield for InstructLab); Table 1 (PR Insights rows); Section 2.2 (PR Insights Data)]
    "A triage team of∼ 10 people is task with ensuring that each PR does not violate the Code of Conduct - OneShield was leveraged to provide automatic annotation of potential violations, for the triage team to confirm. OneShield detectors have been deplyed in the form of a bot on the GitHub repository, that would comment and mark every potential potential violations, holding the automatic merge until human verification by the triage team. ... PR Insights Context 99.76% 37.5% 100% 54.55% 0.24% 0.00%; Question 99.68% 29.63% 100% 45.71% 0.32% 0.00%; Answer 88.82% 35.29% 100% 52.18% 0.18% 0.00%"

    PR Insights is described as an internally generated benchmark from the same InstructLab deployment that OneShield monitors. The only labeling protocol described in Section 4.1 is that OneShield flags potential violations and the triage team confirms those flags; no independent review of unflagged PRs is described. Under this protocol, the 'positive' set is definitionally the set of detector-flagged-and-confirmed PRs, so recall=100% and FNR=0.00% are true by construction. These deployment metrics therefore cannot independently validate detector quality or support the conclusion that OneShield 'significantly reduc[es] manual oversight'—they reduce to the flag-then-confirm loop itself.

full rationale

OneShield's architectural contributions—parallel containerized detectors, the Policy Manager, model-agnostic operation, and inference-time execution—are self-contained design statements and are not circular. The main circularity is confined to the deployment validation. Section 4.1 describes a bot that flags PRs and holds them for triage-team confirmation, and it does not describe any independent labeling of unflagged PRs. Consequently, the PR Insights rows of Table 1 (recall 100%, FNR 0.00%) are definitional: the positive label set is exactly the set of OneShield-flagged-and-confirmed PRs, so the detector cannot produce a false negative by construction. This makes the deployment metrics unusable as independent evidence for the 'robust risk detectors' contribution or for the claim that OneShield significantly reduces manual oversight. The weak-supervision training pipeline (X-Force URL taxonomy plus TF-IDF keyword paragraph selection) is a correctness and generalization concern, but it is not a circularity concern. The HeAL benchmark is authored by overlapping authors, but because it is a publicly available, manually annotated dataset rather than a quantity fitted from the detector itself, it does not by itself constitute circularity under the independence rules. Overall, one deployment-evaluation metric reduces to its own flagging process, yielding a partial-circularity score of 6.

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

The paper introduces a named system and a policy-manager concept, but no new physical or mathematical entities. The free parameters and assumptions above are the load-bearing choices a reader would need to reproduce or question the reported results.

free parameters (2)
  • TF-IDF keyword count N = Not disclosed
    In Section 3.1, the authors manually select the top N indicative keywords per risk category to pull training paragraphs. This choice shapes the training data and is not reported.
  • Policy manager decision thresholds = Not disclosed
    The Policy Manager chooses actions such as block, mask, or pass based on detector confidence scores and templates, but the thresholds and template parameters are not specified.
assumptions (4)
  • domain assumption IBM X-Force URL taxonomy categories map correctly to OneShield risk categories.
    Web-crawled pages labeled by XForce are used as weak supervision for risk-category classifiers in Section 3.1, with no validation of the mapping.
  • domain assumption LLM Internal Interactive Logs (156 million records) are representative production data and safe for detector training.
    These logs are used to train the self-harm detector in Section 3.1, but no bias analysis, privacy review, or representativeness check is reported.
  • domain assumption Parallel execution of detectors bounds total latency by the slowest detector with no resource contention.
    Section 3.3 claims a hard guarantee that total time is no longer than the longest-running detector, ignoring contention, network overhead, and the orchestrator waiting for all detector responses.
  • domain assumption Public benchmarks such as HeAL and the Kaggle adult-content dataset are valid gold standards for the target tasks.
    Evaluations in Section 3.1 rely on these benchmarks; HeAL was created by members of this team, weakening its independence.

how reviews work

0 comments
Cite this review

Pith. "Pith review of OneShield -- the Next Generation of LLM Guardrails." pith.science (2026). https://pith.science/paper/2SFTMJH4

@misc{pith2026250721170,
  author       = {Pith},
  title        = {Pith review of: OneShield -- the Next Generation of LLM Guardrails},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/2SFTMJH4}},
  note         = {Machine review of arXiv:2507.21170}
}
read the original abstract

The rise of Large Language Models has created a general excitement about the great potential for a myriad of applications. While LLMs offer many possibilities, questions about safety, privacy, and ethics have emerged, and all the key actors are working to address these issues with protective measures for their own models and standalone solutions. The constantly evolving nature of LLMs makes it extremely challenging to universally shield users against their potential risks, and one-size-fits-all solutions are unfeasible. In this work, we propose OneShield, our stand-alone, model-agnostic and customizable solution to safeguard LLMs. OneShield aims to provide facilities for defining risk factors, expressing and declaring contextual safety and compliance policies, and mitigating LLM risks, with a focus on each specific customer. We describe the implementation of the framework, discuss scalability considerations, and provide usage statistics of OneShield since its initial deployment.

Figures

Figures reproduced from arXiv: 2507.21170 by the authors.

Figure 1
Figure 1. OneShield Flow Diagram Classification Detectors. OneShield classification detectors are a list of independent classifiers, currently covering the following list of risks: Health Advice. While the OneShield framework allows plugging any openly available external classification model, we trained our internal models for each risk factor. This is because the challenge in constructing effective and robust guardrails is o… view at source ↗
Figure 2
Figure 2. Policy Manager PII entities and determines the privacy level based on the policy template. The decision engine determines the action based on the entities detected and active policies. Finally, the action engine acts upon the input text to take policy defined actions. 3.3 Scale and Implementation Considerations While the services are not required to be co-located, it is beneficial for both performance and security t… view at source ↗

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. LLM Harms: A Taxonomy and Discussion

    cs.CY 2025-12 unverdicted novelty 3.0 of 10

    This paper proposes a taxonomy of LLM harms in five categories and suggests mitigation strategies plus a dynamic auditing system for responsible development.

Reference graph

Works this paper leans on

26 extracted references · 11 canonical work pages · cited by 1 Pith paper

  1. [2]

    Kellen Tan Cheng, Anna Lisa Gentile, Pengyuan Li, Chad DeLuca, and Guang- Jie Ren. 2024. Don’t be my Doctor! Recognizing Healthcare Advice in Large Language Models. In Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing: Industry Track , Franck Dernoncourt, Daniel Preot,iuc-Pietro, and Anastasia Shimorina (Eds.). Associa...

    work page 2024

  2. [1]

    Jonathan Brokman, Omer Hofman, Oren Rachmil, Inderjeet Singh, Vikas Pahuja, Rathina Sabapathy Aishvariya Priya, Amit Giloni, Roman Vainshtein, and Hisashi Kojima. 2024. Insights and Current Gaps in Open-Source LLM Vulnerability Scanners: A Comparative Analysis. arXiv:2410.16527 [cs.CR] https://arxiv.org/ abs/2410.16527

    work page Pith review arXiv 2024

  3. [3]

    François Chollet. 2017. Xception: Deep learning with depthwise separable con- volutions. In Proceedings of the IEEE conference on computer vision and pattern recognition. 1251–1258

    2017

  4. [4]

    Leon Derczynski, Erick Galinkin, Jeffrey Martin, Subho Majumdar, and Nanna Inie. 2024. garak: A Framework for Security Probing Large Language Models. (6 2024). http://arxiv.org/abs/2406.11036

    arXiv 2024

  5. [5]

    Leon Derczynski, Hannah Rose Kirk, Vidhisha Balachandran, Sachin Kumar, Yulia Tsvetkov, Mark R Leiser, and Saif Mohammad. 2023. Assessing language model deployment with risk cards. arXiv preprint arXiv:2303.18190 (2023)

    arXiv 2023

  6. [6]

    Erik Derner, Kristina Batistič, Jan Zahálka, and Robert Babuška. 2024. A Security Risk Taxonomy for Prompt-Based Interaction With Large Language Models.IEEE Access 12 (2024), 126176–126187. https://doi.org/10.1109/ACCESS.2024.3450388

    work page arXiv 2024

  7. [7]

    Jacob Devlin. 2018. Bert: Pre-training of deep bidirectional transformers for language understanding. arXiv preprint arXiv:1810.04805 (2018)

    arXiv 2018

  8. [8]

    Yi Dong, Ronghui Mu, Gaojie Jin, Yi Qi, Jinwei Hu, Xingyu Zhao, Jie Meng, Wenjie Ruan, and Xiaowei Huang. 2024. Position: Building Guardrails for Large Language Models Requires Systematic Design. In Proceedings of the 41st In- ternational Conference on Machine Learning (Proceedings of Machine Learning Research, Vol. 235), Ruslan Salakhutdinov, Zico Kolter...

    work page 2024

Show all 26 references
  1. [9]

    Zhichen Dong, Zhanhui Zhou, Chao Yang, Jing Shao, and Yu Qiao. 2024. At- tacks, Defenses and Evaluations for LLM Conversation Safety: A Survey. In Proceedings of the 2024 Conference of the North American Chapter of the As- sociation for Computational Linguistics: Human Languag...

    2024 doi

  2. [10]

    Joseph Gatto, Parker Seegmiller, Garrett M Johnston, Madhusudan Basak, and Sarah Masud Preum. 2023. HealthE: Recognizing Health Advice & Entities in Online Health Communities. Proceedings of the International AAAI Conference on Web and Social Media 17, 1 (Jun. 2023), 1024–1033...

    2023

  3. [11]

    Venkata Subrahmanyan Govindarajan, Benjamin Chen, Rebecca Warholic, Katrin Erk, and Junyi Jessy Li. 2020. Help! Need Advice on Identifying Advice. In Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP) , Bonnie Webber, Trevor Cohn, Yu...

    2020 doi

  4. [12]

    IBM Granite Team. 2024. Granite 3.0 Language Models

    2024

  5. [13]

    Danny Halawi, Alexander Wei, Eric Wallace, Tony Tong Wang, Nika Haghta- lab, and Jacob Steinhardt. 2024. Covert Malicious Finetuning: Challenges in Safeguarding LLM Adaptation. In Forty-first International Conference on Ma- chine Learning, ICML 2024, Vienna, Austria, July 21-2...

    2024

  6. [14]

    Seungju Han, Kavel Rao, Allyson Ettinger, Liwei Jiang, Bill Yuchen Lin, Nathan Lambert, Yejin Choi, and Nouha Dziri. 2024. Wildguard: Open one-stop mod- eration tools for safety risks, jailbreaks, and refusals of llms. arXiv preprint arXiv:2406.18495 (2024)

    2024 arXiv

  7. [15]

    Xiaowei Huang, Wenjie Ruan, Wei Huang, Gaojie Jin, Yi Dong, Changshun Wu, Saddek Bensalem, Ronghui Mu, Yi Qi, Xingyu Zhao, Kaiwen Cai, Yanghao Zhang, Sihao Wu, Peipei Xu, Dengyu Wu, Andre Freitas, and Mustafa A. Mustafa. 2024. A survey of safety and trustworthiness of large la...

    2024 doi

  8. [16]

    Hakan Inan, Kartikeya Upasani, Jianfeng Chi, Rashi Rungta, Krithika Iyer, Yuning Mao, Michael Tontchev, Qing Hu, Brian Fuller, Davide Testuggine, et al. 2023. Llama guard: Llm-based input-output safeguard for human-ai conversations. arXiv preprint arXiv:2312.06674 (2023)

    2023 arXiv

  9. [17]

    Yingya Li, Jun Wang, and Bei Yu. 2021. Detecting Health Advice in Medical Research Literature. In Proceedings of the 2021 Conference on Empirical Methods in Natural Language Processing , Marie-Francine Moens, Xuanjing Huang, Lucia Specia, and Scott Wen-tau Yih (Eds.). Associat...

    2021

  10. [18]

    Sapna Negi, Tobias Daudert, and Paul Buitelaar. 2019. SemEval-2019 Task 9: Suggestion Mining from Online Reviews and Forums. In Proceedings of the 13th International Workshop on Semantic Evaluation, Jonathan May, Ekaterina Shutova, Aurelie Herbelot, Xiaodan Zhu, Marianna Apidi...

    2019 doi

  11. [19]

    Traian Rebedea, Razvan Dinu, Makesh Sreedhar, Christopher Parisien, and Jonathan Cohen. 2023. Nemo guardrails: A toolkit for controllable and safe llm applications with programmable rails. arXiv preprint arXiv:2310.10501 (2023)

    2023 arXiv

  12. [20]

    Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. 2023. Toolformer: Language Models Can Teach Themselves to Use Tools. arXiv arXiv:2302.04761 (2023). arXiv:2302.04761 [cs.CL] https://arxiv.org/ab...

    2023 arXiv

  13. [21]

    Renee Shelby, Shalaleh Rismani, Kathryn Henne, AJung Moon, Negar Ros- tamzadeh, Paul Nicholas, N’Mah Yilla-Akbari, Jess Gallegos, Andrew Smart, Emilio Garcia, and Gurleen Virk. 2023. Sociotechnical Harms of Algorith- mic Systems: Scoping a Taxonomy for Harm Reduction. In Proce...

    2023

  14. [22]

    Jitesh Shetty and Jafar Adibi. 2004. The Enron email dataset database schema and brief statistical report. Information sciences institute technical report, University of Southern California 4, 1 (2004), 120–128

    2004

  15. [23]

    Shivchander Sudalairaj, Abhishek Bhandwaldar, Aldo Pareja, Kai Xu, David D Cox, and Akash Srivastava. 2024. Lab: Large-scale alignment for chatbots. arXiv preprint arXiv:2403.01081 (2024)

    2024 arXiv

  16. [24]

    Alexander Wei, Nika Haghtalab, and Jacob Steinhardt. 2023. Jail- broken: How Does LLM Safety Training Fail?. In Advances in Neu- ral Information Processing Systems , A. Oh, T. Naumann, A. Globerson, K. Saenko, M. Hardt, and S. Levine (Eds.), Vol. 36. Curran Associates, Inc., 8...

    2023

  17. [25]

    Laura Weidinger, Jonathan Uesato, Maribeth Rauh, Conor Griffin, Po-Sen Huang, John Mellor, Amelia Glaese, Myra Cheng, Borja Balle, Atoosa Kasirzadeh, Court- ney Biles, Sasha Brown, Zac Kenton, Will Hawkins, Tom Stepleton, Abeba Birhane, Lisa Anne Hendricks, Laura Rimell, Willi...

    2022

  18. [26]

    Wenjun Zeng, Yuchi Liu, Ryan Mullins, Ludovic Peran, Joe Fernandez, Hamza Harkous, Karthik Narasimhan, Drew Proud, Piyush Kumar, Bhaktipriya Rad- harapu, et al. 2024. Shieldgemma: Generative ai content moderation based on gemma. arXiv preprint arXiv:2407.21772 (2024)

    2024 arXiv

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.