Pith. sign in

REVIEW 3 major objections 4 minor 43 references

A multi-artifact agent release should pass only after its cross-file relations are checked on a separate path from the generator's own acceptance logic.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · deepseek-v4-flash

2026-08-02 05:52 UTC pith:WWJINS7W

load-bearing objection Honest design/experience report on relational release validation; the formal counterexample holds, but the empirical anchor is a pending spec, so the failure-class claim is a hypothesis, not a demonstrated fact. the 3 major comments →

arxiv 2607.14155 v1 pith:WWJINS7W submitted 2026-07-14 cs.SE

Beyond Object Validation: Relational Conformance in Multi-Artifact Agent Releases

Tengjiao Liu This is my paper
classification cs.SE
keywords relational conformanceartifact graphagent release validationmulti-artifact deliverableseparate-path recomputationrelease state machineclaim verificationSIP-RC
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

The paper argues that validating each artifact in an agent-produced release against its own schema is not enough: the package can still contain mutually contradictory claims. It introduces a relational conformance model, SIP-RC, in which a release is a typed graph of evidence, decisions, certificates, reports, and assets, and acceptance depends on predicates over the graph plus publishability, not just per-object validity. The central case is a DRSS batch in which the ledger supported 60 points and a failed certificate while the final report announced a 100-point Gold Path; every local gate was green. The paper proposes that a separately versioned validator recompute critical decisions from the canonical ledger and policy, that hard failures cannot be averaged away by quality scores, and that published bytes must match what was verified. It presents the profile as a candidate, with comparative evaluation explicitly left as future work.

Core claim

The paper's central claim is the non-implication: satisfying every per-object contract Ci(vi) does not imply ReleaseConform(G), defined as (∧ Ci(vi)) ∧ (∧ Rj(G)) ∧ Publishable(G). The minimal DRSS example shows the failure: ledger(60) → dec(fail) → cert(fail, 60) → report(Gold, 100), where all local schemas pass but a recomputation from ledger plus policy returns fail/60, triggering SIP_RC_ARTIFACT_CONTRADICTION. The remedy is to shift the checked object from individual artifacts to the frozen artifact graph, recompute decisions on a separate path, enforce scope and execution-mode honesty, and gate publication on a freeze–verify–publish transaction.

What carries the argument

The typed artifact graph G = (V, E, τV, τE, ν, A) with node types such as evidence, certificate, report, and rendered view and edge types such as supports, summarizes, renders, and authorized_by. Release conformance is the conjunction of object contracts, relational predicates, and publishability. The profile's guard is separate-path decision recomputation, d* = f_validator(L, P), so the generator does not grade its own work; non-compensatory gates enforce that quality only matters after every mandatory gate passes.

Load-bearing premise

The DRSS ledger(60)/dec(fail)/report(Gold,100) contradiction actually happened in a real release and was not an artifact of a pending acceptance specification or a post-hoc interpretation; if that incident evaporates, the derived invariants lose their empirical anchor.

What would settle it

Re-examine the original DRSS Batch 16 records: if the 100-point Gold Path report can be traced to a different ledger version or a separate legitimate policy, or if no actual release ever contained that contradictory combination, then the central counterexample does not establish a real failure class.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Per-object schema validity can no longer be used as a standalone acceptance criterion for multi-artifact agent releases; relation predicates must be part of the release decision.
  • A separately versioned validator recomputing decisions from canonical evidence and policy can block packages whose ledger, certificate, report, and audience claims disagree, even when every local test passes.
  • Hard failures such as missing evidence, invalid signatures, or hash mismatches cannot be traded away by high quality scores.
  • A freeze–verify–publish state machine with atomic rename ensures external consumers cannot observe a partial or post-review-modified package.
  • The conditional conformance guarantee states that if the manifest declares all relevant artifacts and relations and the validator is correct, no modeled fault in the declared set is present in the published graph.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • If the profile is validated, the same graph-relational view could apply to other multi-artifact outputs, such as software release bundles, ML model cards, or regulatory submissions, where cross-document agreement is the real risk.
  • A likely practical bottleneck is manifest completeness: SIP-RC can only enforce declared semantics, so adversarial or sloppy manifests could undermine it, making completeness testing a natural next step.
  • The separate-path principle might generalize to any delegated generation setting: two independent implementations of critical decision logic should catch systematic errors that a shared codebase reproduces.
  • The paper's own evaluation plan—blind corpus, two independent validators, and an external system—is the testable extension; until then the profile's detection advantage over existing checks remains an open experiment.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 4 minor

Summary. The paper argues that per-object validation is insufficient for multi-artifact agent releases and proposes a graph-based relational conformance model. It defines a typed artifact graph G=(V,E,τV,τE,ν,A), a release conformance predicate combining per-object contracts, relational predicates, and a publishable state, and a candidate Schema-SIP Relational Conformance profile (SIP-RC) with invariants over claim support, decision authority, execution risk/assurance, lineage, rendered views, completeness, and publication integrity. Evidence is drawn from three systems in the author's research program: DRSS as the central negative case, Schema Docs as a successful interoperability case, and Brand Shuttle GEO as an illustrative transfer case. The manuscript derives a set of relational invariants, specifies implementation requirements for the profile, and presents a planned evaluation protocol. It explicitly states that comparative detection performance, false-block rate, and cross-implementation interoperability remain untested.

Significance. If the central incident is real and the profile is validated, the paper would make a useful contribution by shifting the unit of analysis from object-level schema validation to release-graph conformance, connecting provenance and relational constraints to release gating. The formalization is clear, and the paper is commendably explicit about its own limitations and evaluation status. The non-implication that per-object validity does not imply release conformance is correctly stated. However, the significance is currently limited by two structural gaps: the DRSS incident is not independently verifiable, and no empirical comparison supports the normative recommendation. The paper is best understood as a design/experience study and hypothesis-generating framework rather than a validated solution; if the empirical anchor is not strengthened, its central claim of having established a real failure class is not supported.

major comments (3)
  1. [§4.2, §5.1.1, Table 2] The load-bearing empirical premise is that DRSS Batch 16 was an actual release in which every local gate was green and the package still contradicted itself. This is not verifiable from the manuscript. Section 4.2 states that the Batch 16 DRSS document is a pending acceptance specification, not a completion report, and that it is "never used as proof" that gates passed. Section 5.1 defers the full batch chronology to internal supplementary evidence, and §5.1.1 is a heading with no incident description in the main text. Table 2 reports 417/417 passing for a different batch (Batch 13), not for the D1 incident. Under the paper's own evidence grading, the disclosed material for D1 is at best E4 rather than E1/E2. Unless the batch chronology or a completion report is made available, the statement "every local gate was green" is an assumption, and the claimed failure class reduces to a hypothe
  2. [§7, RQ3, §9.6] No comparative evidence supports the practical value of the proposed profile. Section 7 states that performance, false-block rate, and cross-implementation interoperability "remain unanswered" and that the current evidence stops at implementation feasibility. The abstract says the paper "shows that several mechanisms are practical," which is stronger than the evidence: Schema Docs and GEO implement selected checks, but none of the six planned baselines or ablations is run, and no measurement of false blocks, detection recall, authoring cost, or validation latency is reported. Because the working claim in §1.1 is normative (a multi-artifact deliverable should be accepted only after separate-path relational checks), the absence of any empirical support for that recommendation should be acknowledged not only in the limitations section but also in the abstract and conclusion, where the contr
  3. [§5.4, §9.1, Table 2] The seven recurring invariants are derived from the same three cases used as evidence, all originating from one research program; Table 2 shows no external replication for any case, and §9.1 candidly admits common-source bias. This creates a circularity risk: the incident set and the invariant set are not independent, and the cross-case synthesis in §5.4 cannot establish that the same seven relations "recur" beyond the author's own systems. The planned blind hold-out and external transfer test in §7 are prospective and cannot validate the present findings. The paper should either present independent replication evidence or explicitly classify the seven invariants as a hypothesis to be tested, not a derived-and-confirmed result.
minor comments (4)
  1. [§3.6] The comparison d^* = f_validator(L,P), \hat d = d^* is written as an assignment or equality, but the text says the two are compared. This should be expressed as a verification condition, e.g., assert(\hat d == f_validator(L,P)), to avoid the appearance that the validator overwrites the generator's decision.
  2. [§5.1, §5.2, §5.3] Several incident subsections (D1–D3, S1–S3, G1–G2) are headings only in the main text, with details deferred to a supplement. If the supplement is in the open-source repository, the paper should cite permanent artifact identifiers so readers can inspect the incidents; if not yet public, the cross-case analysis is uncheckable.
  3. [§5.1.4, §5.2.4] The heading numbering appears garbled: "5.1.4 5.1.1 How the DRSS failures accumulated" and "5.2.4 5.2.1 What the product case establishes" duplicate subsection labels. Please fix the numbering to reflect the actual hierarchy.
  4. [References] Several references contain formatting anomalies, such as underscores instead of spaces in author names (e.g., [9], [11], [21], [22], [40]) and inconsistent internal punctuation. Please run the bibliography through a consistent citation style.

Circularity Check

0 steps flagged

No significant circularity: the core non-implication is a concrete counterexample, the profile's guarantees are explicitly conditional targets, and the self-citations are disclaimed as non-generalizing lineage.

full rationale

The paper's central derivation is not circular. The non-implication in §3.2 (∧ Ci(vi) = 1 does not imply ReleaseConform(G) = 1) is exhibited by the minimal DRSS example: ledger(60) → dec(fail) → cert(fail,60) → report(Gold,100), where all nodes pass local schemas but the recomputation from ledger + policy-v3 contradicts the report. This is a constructed counterexample, not a fitted prediction. The relational invariants in §6.4 (e.g., report.score == certificate.score) are explicit encodings of observed failure modes, stated as requirements, and the paper does not claim these invariants predict anything; §7 states the profile 'has not been compared with the baselines' and calls the study 'a design and experience contribution.' The conditional conformance guarantee in §3.9 is explicitly labeled a 'target, not a theorem' with assumptions listed, so it is analytic rather than an empirical claim smuggled in as a result. Self-citations appear in §1.1, but the paper itself disclaims their evidentiary force: 'because they share an author and research program, they do not establish generality.' Limitations §9.1–§9.7 candidly identify common-source bias, retrospective collection, unequal maturity, validator fallibility, and evaluation status. The reader's concern that D1 rests on a pending acceptance specification (§4.2) is a real evidence-quality limitation, but it is not a reduction of the derivation to its own inputs; it affects the empirical anchoring of the incident, not the logical structure of the model. No step was found where a prediction is equivalent to a fitted parameter, a uniqueness theorem is imported from the authors, or a known result is merely renamed.

Axiom & Free-Parameter Ledger

1 free parameters · 6 axioms · 2 invented entities

The paper contains no fitted numeric parameters; the formal guarantee is conditional on the manifest, the validator implementation, the cryptographic primitives, and byte-equality (§3.9). The main external burden is the reliance on three same-author retrospective cases as evidence for the failure class and derived invariants.

free parameters (1)
  • release quality threshold θ
    Appears in Accept(G) = (∧ g_k) ∧ (q ≥ θ) (§3.5); the paper does not specify or fit θ, leaving acceptance threshold a free design parameter.
axioms (6)
  • domain assumption Hash and signature primitives behave as specified
    Assumption (iii) in §3.9; the conditional guarantee presumes cryptographic primitives are not broken, and no independent validation is provided.
  • domain assumption The validator correctly implements the declared SIP-RC predicates
    Assumption (ii) in §3.9; §9.5 reports a prior canonicalization bug, so implementation correctness is load-bearing and untested here.
  • domain assumption The manifest declares every artifact and relation instance for every fault in F
    Assumption (i) in §3.9; §9.4 concedes an incomplete or permissive manifest may validate a non-conformant method.
  • domain assumption Published bytes equal the verified bytes
    Assumption (iv) in §3.9; atomic-rename publication is intended to guarantee this, but it is still an assumption in the formal statement.
  • domain assumption The three retrospective case reconstructions accurately reflect real development history
    Evidence grading E1–E4 in §4.2 and the statement in §9.2 that histories were not preregistered; no outside organization has replicated the systems (§4.3).
  • domain assumption A multi-artifact release is adequately modeled as a typed artifact graph
    §3.1 defines G=(V,E,τV,τE,ν,A) as the model; this is a design choice, not a derived fact.
invented entities (2)
  • SIP-RC profile no independent evidence
    purpose: Release-level relational conformance validation for multi-artifact agent deliverables
    The profile is introduced and sketched in §6; its detection advantage, false-block rate, and interoperability are explicitly untested (§7), so it has no external falsifiable evidence yet.
  • Typed artifact graph G=(V,E,τV,τE,ν,A) no independent evidence
    purpose: Formal representation of a release and its relations
    Modeling construct from §3.1; not an independently observed entity.

pith-pipeline@v1.3.0-alltime-deepseek · 11919 in / 15512 out tokens · 161910 ms · 2026-08-02T05:52:59.344905+00:00 · methodology

0 comments
read the original abstract

Agent systems validate inputs, tool calls, and generated objects. The final package often escapes the same scrutiny. In one DRSS release, the ledger supported 60 points and a failed certificate; the report announced a 100-point Gold Path. Every local gate was green. The package contradicted itself. We study that failure alongside Schema Docs, where similar faults became product contracts, and Brand Shuttle GEO, where evidence is turned into repair work. The result is a candidate Schema-SIP Relational Conformance profile (SIP-RC). It models a release as a graph: claims point to evidence, decisions carry bounded authority, derived artifacts retain their execution conditions and lineage, and published bytes must match the package that was checked. Hard failures cannot be averaged away, and a validator recomputes critical decisions on a separate path. The paper establishes the failure class and shows that several mechanisms are practical. Whether the full profile performs better than existing checks remains an open experiment.

Figures

Figures reproduced from arXiv: 2607.14155 by Tengjiao Liu.

Figure 1
Figure 1. Figure 1: Local validity does not imply release conformance. The failure [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

43 extracted references · 9 canonical work pages · 3 internal anchors

  1. [1]

    Schema Sandbox: A Nine-Layer Architecture and Inter- operability Contract for Constrained Agent Execution,

    T. Liu, “Schema Sandbox: A Nine-Layer Architecture and Inter- operability Contract for Constrained Agent Execution,” psi.run,

  2. [2]

    JSON Schema: A Media Type for Describing JSON Documents,

    JSON Schema, “JSON Schema: A Media Type for Describing JSON Documents,” Draft 2020-12, 2022

    2020

  3. [3]

    Shapes Constraint Language (SHACL),

    W3C, “Shapes Constraint Language (SHACL),” W3C Recommen- dation, 20 July 2017

    2017

  4. [4]

    PROV-O: The PROV Ontology,

    T. Lebo, S. Sahoo, and D. McGuinness, eds., “PROV-O: The PROV Ontology,” W3C Recommendation, 30 April 2013

    2013

  5. [5]

    in-toto: Providing Farm-to-Table Guarantees for Bits and Bytes,

    S. Torres-Arias, H. Afzali, T. K. Kuppusamy, R. Curtmola, and J. Cappos, “in-toto: Providing Farm-to-Table Guarantees for Bits and Bytes,” in28th USENIX Security Symposium, 2019

    2019

  6. [6]

    C2PA Tech- nical Specification,

    Coalition for Content Provenance and Authenticity, “C2PA Tech- nical Specification,” Version 2.4, 2026

    2026

  7. [7]

    Pram ¯an. a: A Protocol-Layer Treatment of Claim Verification in Autonomous Agent Networks,

    R. K. Kadaboina, “Pram ¯an. a: A Protocol-Layer Treatment of Claim Verification in Autonomous Agent Networks,”arXiv:2605.20312,

    Pith/arXiv arXiv

  8. [8]

    AgentSpec: Cus- tomizable Runtime Enforcement for Safe and Reliable LLM Agents,

    H. Wang, C. M. Poskitt, and J. Sun, “AgentSpec: Cus- tomizable Runtime Enforcement for Safe and Reliable LLM Agents,” accepted atICSE 2026;arXiv:2503.18666, 2025. doi:10.48550/arXiv.2503.18666

    Pith/arXiv arXiv doi:10.48550/arxiv.2503.18666 2026

  9. [9]

    doi:10.48550/arXiv.2605.20312

    work page internal anchor Pith review Pith/arXiv arXiv doi:10.48550/arxiv.2605.20312

  10. [10]

    Specification,

    Model Context Protocol, “Specification,” Revision 2025-11-25, ac- cessed 14 July 2026

    2025

  11. [11]

    SkillGuard: A Permission-Centric Framework for Agent Skill Security

    S. Pan, X_Sun, T_Zhang, D_Liao, K_Yang, and Z_Xing, “Skill- Guard: A Permission-Centric Framework for Agent Skill Security,” arXiv:2606.03024, 2026. doi:10.48550/arXiv.2606.03024

    work page internal anchor Pith review Pith/arXiv arXiv doi:10.48550/arxiv.2606.03024 2026

  12. [12]

    Efficient Guided Generation for Large Language Models,

    B. T. Willard and R_Louf, “Efficient Guided Generation for Large Language Models,”arXiv:2307.09702, 2023

    Pith/arXiv arXiv 2023

  13. [13]

    JSONSchemaBench: A Rigor- ous Benchmark of Structured Outputs for Language Models,

    S. Geng, H_Cooper, M_Moskal, S_Jenkins, J_Berman, N_Ranchin, R_West, E_Horvitz, and H_Nori, “JSONSchemaBench: A Rigor- ous Benchmark of Structured Outputs for Language Models,” arXiv:2501.10868, 2025

    Pith/arXiv arXiv 2025

  14. [14]

    NIST,Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, 2023

    2023

  15. [15]

    MemGPT: Towards LLMs as Operating Systems,

    C. Packer, S_Wooders, K_Lin, V_Fang, S_G. Patil, I_Stoica, and J_E. Gonzalez, “MemGPT: Towards LLMs as Operating Systems,” arXiv:2310.08560, 2023

    Pith/arXiv arXiv 2023

  16. [16]

    Design and Refinement of a Data Quality Assess- ment Workflow for a Large Pediatric Research Network,

    R. Khare et al., “Design and Refinement of a Data Quality Assess- ment Workflow for a Large Pediatric Research Network,”eGEMs, vol. 7, no. 1, article 36, 2019. doi:10.5334/egems.294

    work page doi:10.5334/egems.294 2019

  17. [17]

    SIP: Session Initiation Protocol,

    J. Rosenberg et al., “SIP: Session Initiation Protocol,” IETF RFC 3261, June 2002

    2002

  18. [18]

    Trav-SHACL: Efficiently Validating Networks of SHACL Constraints,

    M. Figuera, P . D. Rohde, and M.-E. Vidal, “Trav-SHACL: Efficiently Validating Networks of SHACL Constraints,” arXiv:2101.07136, 2021

    Pith/arXiv arXiv 2021

  19. [19]

    The Structured Output Benchmark: A Multi-Source Benchmark for Evaluating Structured Output Quality in Language Models,

    A. K. Singh, H_V . Khurdula, Y_D. Khemlani, and V_Agarwal, “The Structured Output Benchmark: A Multi-Source Benchmark for Evaluating Structured Output Quality in Language Models,” arXiv:2604.25359, 2026

    Pith/arXiv arXiv 2026

  20. [20]

    AC4A: Access Control for Agents,

    R. K. Sharma and D_Grossman, “AC4A: Access Control for Agents,”arXiv:2603.20933, 2026. PREPRINT, JUL Y 2026 10

    arXiv 2026

  21. [21]

    Fixpoint Semantics for Recursive SHACL,

    B. Bogaerts and M_Jakubowski, “Fixpoint Semantics for Recursive SHACL,”arXiv:2109.08285, 2021

    Pith/arXiv arXiv 2021

  22. [22]

    AIRGuard: Guarding Agent Actions with Runtime Authority Control,

    S. Qin, H_Zhuang, Y_Zhou, Y_Han, and X_Zhang, “AIRGuard: Guarding Agent Actions with Runtime Authority Control,” arXiv:2605.28914, 2026. doi:10.48550/arXiv.2605.28914

    Pith/arXiv arXiv doi:10.48550/arxiv.2605.28914 2026

  23. [23]

    ChainCaps: Composition-Safe Tool-Using Agents via Monotonic Capability Attenuation,

    X. Jiang, S_Yang, Z_Li, L_Liu, H_Yu, and Y_Liu, “ChainCaps: Composition-Safe Tool-Using Agents via Monotonic Capability Attenuation,”arXiv:2605.26542, 2026

    Pith/arXiv arXiv 2026

  24. [24]

    Agent Concretization: An Evolutionary Framework for Persistent Agent Personas in Latent Space,

    T. Liu, “Agent Concretization: An Evolutionary Framework for Persistent Agent Personas in Latent Space,” psi.run and Zenodo,

  25. [25]

    Agentproof: Static Verification of Agent Workflow Graphs,

    M. Xavier, V_M. A, M_Jolly, and M_Xavier, “Agentproof: Static Verification of Agent Workflow Graphs,”arXiv:2603.20356, 2026. doi:10.48550/arXiv.2603.20356

    doi:10.48550/arxiv.2603.20356 2026

  26. [26]

    Harvesting Unexpectedness: A Double-Threshold Filter for AI-Generated Discoveries,

    T. Liu, “Harvesting Unexpectedness: A Double-Threshold Filter for AI-Generated Discoveries,” psi.run, 2026. doi:10.5281/zenodo.20776925

    work page doi:10.5281/zenodo.20776925 2026

  27. [27]

    doi:10.5281/zenodo.20681708

    work page doi:10.5281/zenodo.20681708

  28. [28]

    Agent Concretization: Informational Boundaries and Per- sistent Agent IP ,

    T. Liu, “Agent Concretization: Informational Boundaries and Per- sistent Agent IP ,” psi.run, 2026. doi:10.5281/zenodo.20741399

    work page doi:10.5281/zenodo.20741399 2026

  29. [29]

    Schema Accommodation via Algorithmic Compaction: Boundary-Preserving Skill Patches for Persistent LLM Agents,

    T. Liu, “Schema Accommodation via Algorithmic Compaction: Boundary-Preserving Skill Patches for Persistent LLM Agents,” published research paper, 2026

    2026

  30. [30]

    Lamarckian Scars: Inheritable Runtime Con- straints for Persistent LLM Agents,

    T. Liu, “Lamarckian Scars: Inheritable Runtime Con- straints for Persistent LLM Agents,” psi.run, 2026. doi:10.5281/zenodo.20842693

    work page doi:10.5281/zenodo.20842693 2026

  31. [31]

    Heterogeneous Agent Cohorts for Safe Open-Ended Exploration with Runtime Constraint Memory

    T. Liu, “Heterogeneous Agent Cohorts for Safe Open-Ended Ex- ploration with Runtime Constraint Memory,”arXiv:2607.11226 [cs.AI], 2026. doi:10.48550/arXiv.2607.11226

    work page internal anchor Pith review Pith/arXiv arXiv doi:10.48550/arxiv.2607.11226 2026

  32. [32]

    Trade Secrets,

    World Intellectual Property Organization, “Trade Secrets,” WIPO guidance

  33. [33]

    Article 55 — Non-prejudicial disclo- sures,

    European Patent Office, “Article 55 — Non-prejudicial disclo- sures,”European Patent Convention, 2020 edition

    2020

  34. [34]

    Provisional Applica- tion for Patent,

    United States Patent and Trademark Office, “Provisional Applica- tion for Patent,” USPTO guidance

  35. [35]

    SPDX Specification,

    SPDX Project, “SPDX Specification,” Version 3.0.1

  36. [36]

    Data protection explained,

    European Commission, “Data protection explained,” EC GDPR guidance

  37. [37]

    McCallister, T_Grance, and K_Scarfone,Guide to Protecting the Confidentiality of Personally Identifiable Information (PII), NIST SP 800-122, 2010

    E. McCallister, T_Grance, and K_Scarfone,Guide to Protecting the Confidentiality of Personally Identifiable Information (PII), NIST SP 800-122, 2010

    2010

  38. [38]

    Guardrails AI Documentation,

    Guardrails AI, “Guardrails AI Documentation,” structured-data generation and validation

  39. [39]

    CycloneDX Bill of Materials Specification (ECMA-424)

    OWASP Foundation, “CycloneDX Bill of Materials Specification (ECMA-424).”

  40. [40]

    NeMo Guardrails: Guardrail Types,

    NVIDIA, “NeMo Guardrails: Guardrail Types,” documentation

  41. [42]

    Compromised PyTorch-nightly depen- dency chain between December 25th and December 30th, 2022,

    PyTorch Foundation, “Compromised PyTorch-nightly depen- dency chain between December 25th and December 30th, 2022,” PyTorch Blog, Dec. 31, 2022

    2022

  42. [43]

    EchoLeak: The First Real-World Zero- Click Prompt Injection Exploit in a Production LLM System,

    P . Reddy and A. S. Gujral, “EchoLeak: The First Real-World Zero- Click Prompt Injection Exploit in a Production LLM System,” arXiv:2509.10540, 2025. doi:10.48550/arXiv.2509.10540

    Pith/arXiv arXiv doi:10.48550/arxiv.2509.10540 2025

  43. [2026]

    doi:10.5281/zenodo.20775072

    work page doi:10.5281/zenodo.20775072