Paper deep dive
HepScript: A Dual-Use DSL for Human-AI Collaborative Data Analysis Workflows in High-Energy Physics
Junkun Jiao, Tong Liu, Ke Li, Weimin Song, Yipu Liao, Bolun Zhang, Beijiang Liu, Chang-Zheng Yuan, Yue Sun
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 89%
Last extracted: 7/8/2026, 8:21:23 AM
Summary
The paper introduces HepScript, a dual-use Domain-Specific Language (DSL) designed to bridge human expertise and AI automation in High-Energy Physics (HEP) data analysis. Implemented for the BESIII experiment using Ruby, HepScript abstracts complex analysis logic into a constrained, intuitive syntax that translates high-level specifications into production-ready code for software stacks like BOSS and ROOT. Evaluations demonstrate that HepScript reduces human coding effort by 93% and enables Large Language Models to autonomously generate executable specifications with a 95% success rate, establishing a scalable framework for human-AI collaborative scientific workflows.
Entities (12)
Relation Signals (8)
HepScript → designedfor → High-Energy Physics
confidence 95% · HepScript serves as a shared formal interface, abstracting HEP analysis logic into a constrained syntax that is both intuitive for human experts and reliably generable by AI agents.
HepScript → reduces → human coding effort
confidence 94% · In our case studies, this abstraction reduces the required human-written code by 93%.
Large Language Models → generate → HepScript
confidence 93% · enabling AI agents to autonomously generate executable specifications for core analysis stages directly from published literature with a 95% success rate.
HepScript → usedin → BESIII
confidence 92% · First developed for the Beijing Spectrometer III (BESIII) experiment, HepScript hides the complexity of the underlying software stack, translating high-level analysis intent into low-level, production-ready code.
HepScript → implementedin → Ruby
confidence 91% · we selected Ruby for its exceptionally readable and flexible syntax, native support for fluent interfaces via method chaining, powerful meta-programming capabilities, and rich ecosystem.
HepScript → actsas → translation layer
confidence 89% · a formally specified DSL acts as an unambiguous translation layer between human expertise, AI automation, and production environment, rendering previously intractable automation problems solvable.
HepScript → generatescodefor → ROOT
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:The escalating data scale in High-Energy Physics (HEP) fuels a growing aspiration for higher analytical efficiency. While Large Language Models (LLMs) offer a path toward automation via agentic AI, they struggle with complex scientific workflows that require deep domain knowledge and are tightly coupled to experiment-specific codebases. To address this, we introduce a methodology centered on HepScript, a dual-use Domain-Specific Language (DSL) for HEP data analysis workflows. HepScript serves as a shared formal interface, abstracting HEP analysis logic into a constrained syntax that is both intuitive for human experts and reliably generable by AI agents. First developed for the Beijing Spectrometer III (BESIII) experiment, HepScript hides the complexity of the underlying software stack, translating high-level analysis intent into low-level, production-ready code. In our case studies, this abstraction reduces the required human-written code by 93\%. Crucially, HepScript's constrained grammar defines a tractable action space, enabling AI agents to autonomously generate executable specifications for core analysis stages directly from published literature with a 95\% success rate. Our work demonstrates a scalable pathway toward human-AI collaborative systems, where a formally specified DSL acts as an unambiguous translation layer between human expertise, AI automation, and production environment, rendering previously intractable automation problems solvable.
Tags
Links
- Source: https://arxiv.org/abs/2605.01423v1
- Canonical: https://arxiv.org/abs/2605.01423v1
Trouble viewing inline? Open PDF directly →
Full Text
66,595 characters extracted from source content.
Expand or collapse full text
HepScript: A Dual-Use DSL for Human-AI Collaborative Data Analysis Workflows in High-Energy Physics Junkun Jiao 1* Tong Liu 2* Ke Li 2,3† Weimin Song 1† Yipu Liao 2,3 Bolun Zhang 2 Beijiang Liu 2,3 Chang-Zheng Yuan 2,3 Yue Sun 2,3 1 Jilin University, Changchun, Jilin, China 2 Institute of High Energy Physics, CAS, Beijing, China 3 University of Chinese Academy of Sciences, Beijing, China jiaojk1118@mails.jlu.edu.cn, weiminsong@jlu.edu.cn like, liutong2016, liaoyp, zhangbolun, liubj, yuancz, yuesun@ihep.ac.cn Abstract The escalating data scale in High-Energy Physics (HEP) fuels a growing aspiration for higher analytical efficiency. While Large Language Models (LLMs) offer a path toward automation via agentic AI, they struggle with complex scientific workflows that require deep domain knowledge and are tightly coupled to experiment-specific codebases. To address this, we introduce a methodology centered on HepScript, a dual-use Domain-Specific Language (DSL) for HEP data analysis workflows. HepScript serves as a shared formal interface, abstracting HEP analysis logic into a constrained syntax that is both intuitive for human experts and reliably generable by AI agents. First developed for the Beijing Spectrometer I (BESIII) experiment, HepScript hides the complexity of the underlying software stack, translating high-level analysis intent into low-level, production-ready code. In our case studies, this abstraction reduces the required human-written code by 93%. Crucially, HepScript’s constrained grammar defines a tractable action space, enabling AI agents to autonomously generate executable specifications for core analysis stages directly from published literature with a 95% success rate. Our work demonstrates a scalable pathway toward human-AI collaborative systems, where a formally specified DSL acts as an unambiguous translation layer between human expertise, AI automation, and production environment, rendering previously intractable automation problems solvable. 1 Introduction Scientific discovery is undergoing a profound paradigm shift toward an AI-driven fifth paradigm [1], where AI is expected to transform from a mere tool to an autonomous research collaborator [2]. Recent advances in Large Language Models (LLMs) [3] make this prospect tangible for data-intensive disciplines like High-Energy Physics (HEP), where the petabytes to exabytes of raw data accumulated annually [4, 5] fuel a growing aspiration for higher analytical efficiency, making AI automation a promising and perhaps necessary strategy. However, for LLM-powered agents to be practically useful, they must move beyond simple task automation to comprehending, planning, and executing complete multi-step scientific workflows. This remains a fundamental challenge, as LLMs often struggle with long-horizon planning [6], lack the deep, tacit domain knowledge required to structure these * Equal contribution. † Corresponding author. Preprint. arXiv:2605.01423v1 [hep-ex] 2 May 2026 Workflow DesignWorkflow Automation Domain Expert AI Agent DSL SpecificationSoftware StackCompiler/TranslatorAnalysis Intention Measure the decay branching fraction of ... Figure 1: Dual-use DSL as a grounding mechanism. It provides an intuitive interface for human experts and a constrained action space for LLM agents. The formal grammar transforms open-ended code generation into a tractable sequence prediction task. A DSL processor (compiler/translator) then bridges the specification to production software stacks. workflows, and cannot reliably interact with production environments without strictly predefined interfaces. HEP data analysis provides an ideal yet demanding testbed for autonomous AI capabilities. The workflows are intricate—spanning data collection, selection, visualization, interpretation, and statisti- cal inference—and are tightly coupled to complex, experiment-specific software frameworks (e.g., BASF2 [7]). Because nearly all workflow procedures can be expressed as coding tasks, they are natu- rally well-suited for LLMs. However, our early exploration with the Beijing Spectrometer I (BESIII) experiment [8] identified three critical barriers to autonomous HEP analysis: (1) Formalizing Domain Knowledge: How can the extensive, often implicit rules of HEP analysis be embedded into a standard format usable by AI agents? (2) Integrating with Production Environment: How can we bridge the semantic gap between a high-level analysis goal (e.g., reconstruct a particle) and the low-level, framework-specific code required to execute it? (3) Constraining LLM Generation: How can we guide LLMs to generate logically coherent, multi-step workflows that are guaranteed to compile and execute in a production environment? To overcome these barriers, we propose a grounding methodology utilizing a Domain-Specific Language (DSL), as illustrated in Fig. 1. Our key insight is that a well-designed DSL can collapse the semantic gap between analysis intent and machine execution. By abstracting HEP data analysis logic into a constrained, high-level syntax, the DSL serves a dual purpose: it provides an intuitive interface for physicists, and it defines a tractable, bounded action space for an LLM agent. The DSL’s formal grammar acts as a guardrail, transforming an open-ended code generation problem into a constrained sequence prediction task that is far more amenable to few-shot learning. This approach simultaneously solves all three barriers: formalizing domain knowledge into the DSL’s grammar, integrating with the software framework via a DSL processor, and providing necessary, verifiable structures for LLM generation. Through this, it builds a formal model for HEP data analysis, shifting the automation bottleneck from how to conduct an analysis to what to specify. 1.1 Contributions In this paper, we introduce and validate a methodology for grounding autonomous agents in complex scientific workflows using a dual-use DSL. Our contributions are fourfold: 1.Core Insight: We demonstrate that a well-designed DSL can collapse the unbounded action space of framework-specific code, transforming open-ended LLM generation into a highly constrained, reliable sequence prediction task. 2.Concrete Instantiation: We present HepScript, a Ruby-embedded DSL co-designed with LLM assistance for the BESIII experiment, which abstracts the complex underlying software system into a formal, executable specification language. 2 3.Empirical Validation: Through systematic evaluations, we show that HepScript reduces human coding effort by 93% and enables LLMs to autonomously generate correct, executable specifications for core analysis stages with a 95% success rate after agentic retries. 4.Generalizable Methodology: We provide a documented methodology—covering DSL design, implementation details, generation strategies, evaluation setups, and a proposed self- evolutionary mechanism—that can be adapted to other scientific domains where framework- heavy workflows currently preclude automation. 1.2 Related Works Recent studies [9–12] have explored automating HEP workflows. Ref. [9] combines a relatively fixed workflow manager with a code-generating agent. Ref. [10] formalizes individual workflow phases as schema-validated tools that consume run cards and output JSONL data, with agent orchestration in a human-supervised loop. Ref. [11] employs an LLM as a “graduate student" supervised by human physicists to execute a fixed analysis, lacking a generalizable agentic framework. Building on that direction, Ref. [12] introduces more domain-specific rules and tools but delegates the oversight tasks to specialized AI agents. While these prior efforts offer promising architectures, none defines a formal, unified representation of a complete workflow that is simultaneously human-friendly, AI- generable, and software-integrated. Our work on HepScript explores whether a DSL could fill this role. HepScript is not a replacement for these agentic systems; rather, it can be integrated into them as a shared action space, an intermediate language, or a validation layer. In the HEP community, early DSLs targeted specific functionalities such as database querying or simple data processing. To our knowledge, only the recently emerged ADL [13], b2luigi [14], and FLARE [15] have the potential to capture complete analysis pipelines. However, b2luigi and FLARE are Python libraries focused primarily on workflow orchestration, while ADL is designed to decouple physics logic from framework technicalities to facilitate accessibility, analysis (re)interpretation, and preservation. Critically, these tools are not intermediate representations explicitly built for human-agent collaboration. HepScript is a preliminary attempt to explore this direction within the BESIII context and can be encapsulated as a tool or “skill" [16] for multi-agent systems. 2 Design and Evolution of HepScript 2.1 Code Generation Architecture HepScript is designed around a code-generation architecture to balance minimal development effort against maximal abstraction utility. A typical BESIII data analysis workflow involves two distinct software suites: the BESIII Offline Software System (BOSS) [17] for simulation, reconstruction, and basic data selection, and ROOT [18] for subsequent high-level data selection, statistical inference, and visualization. The inherent complexity of BOSS and the flexibility of ROOT make creating a single compiled or interpreted language spanning both software suites impractical. Therefore, we adopt a code generation architecture. HepScript does not execute the workflow directly. Instead, it serves as a high-level specification language. A dedicated processor reads the HepScript file and generates the required analysis code snippets for different workflow procedures. These snippets are then orchestrated and executed—either manually or by an automated agent—in the correct sequence. This approach decouples HepScript from the runtime environments of BOSS and ROOT, enabling code generation in multiple target languages (such as C++ for BOSS algorithms and ROOT scripts, Bash for job configuration, or Python for scientific libraries) depending on the analysis phase. Furthermore, the intermediate DSL processor facilitates autonomous error recovery by providing detailed diagnostic feedback and correction suggestions during agentic retries. Finally, this design ensures full traceability for human analysts. Experts can inspect and modify the generated code, trace problems back to the original HepScript specification, and intervene as necessary. This dual transparency is essential for building reliable human-AI collaborative systems, acting as a safeguard against the probabilistic nature of LLM-generated components. Given this architecture, we implemented HepScript as an embedded DSL within a general-purpose host language. This leverages the host’s existing syntax and parser, accelerating development com- pared to creating an external DSL with dedicated parsing tools (e.g., Yacc/Bison) and facilitating LLM generation. To ensure dual-use capability, HepScript adheres to three core constraints: (C1) 3 Readability: The syntax must be declarative and intuitive, shielding users from framework com- plexities to ensure human adoption and reliable LLM generation. (C2) Modularity: HepScript must provide discrete, reusable blocks corresponding to BESIII analysis stages, enabling workflow composition and task decomposition. (C3) Host Language Suitability: The host language must support syntactic flexibility and meta-programming for an elegant DSL capable of complex code generation. After evaluating potential hosts (e.g., Python, Ruby, Lisp, Smalltalk) against these constraints, we selected Ruby for its exceptionally readable and flexible syntax, native support for fluent interfaces via method chaining, powerful meta-programming capabilities, and rich ecosystem. 2.2 LLM-assisted HepScript Design To ensure HepScript addresses real-world analysis needs, we grounded its design in actual BESIII physics publications. We began with a curated corpus of 20 published BESIII papers describing analyses with simple and linear workflows. For each paper, we prompted an LLM with the full text and explicit instructions to: (1) extract the complete data analysis workflow, and (2) formalize it as structured, Ruby-embedded DSL pseudo-code that captures the analysis logic in a declarative style. The initial DSL outputs were manually analyzed to identify frequent semantic patterns (e.g., “select photon", “particle identification"). This informed an iterative, human-in-the-loop refinement process. We continuously reviewed the LLM’s proposed syntax, generalized recurring patterns into core DSL constructs, and refined the prompt based on observed shortcomings. This cycle converged on an optimized DSL grammar that provides an intuitive, fluent interface for expressing analysis logic. The final HepScript’s structure is synthesized to adhere to the five stages of a typical BESIII analysis: 1. Dataset Preparation: Declaring the real data and simulated Monte Carlo (MC) samples. 2. Base Selection: Applying basic data selection criteria to separate candidate signal events from background events. 3. Advanced Selection: Purifying the candidate signal sample via optimized, analysis-specific selection criteria to suppress background pollution. 4. Visualization: Presenting and interpreting the data, such as generating comparative figures of invariant mass distributions between simulated samples and real data. 5. Statistical Analysis: Perform statistical analyses, such as fitting distributions and computing significances for physical measurements. The first two stages generate code for the BOSS, while the latter three target ROOT. An example of the resulting HepScript’s grammar is provided in the Appendix A. Through this process, we have successfully distilled the domain model of BESIII data analysis and instantiated it into the HepScript representation. 3 Implementation To realize the code-generation architecture described in Sec. 2, we built a DSL processor that translates HepScript specifications into target analysis code. The processor adopts a hybrid generation strategy with three approaches, selected based on the nature of the target code: • Templated Generation: For target code with extensive static structure and few dynamic variables (e.g., selecting charged tracks in base selection), we use template files containing placeholder keys (e.g., key). The processor substitutes these placeholders with analysis- specific values extracted from the HepScript specification. This method supports iterative substitution, where the substituted value may contain other placeholders, enabling the handling of complex, nested code structures. •Translator-Based Generation: For target code with highly flexible or semantically com- plex syntax that is ill-suited to rigid templates, we implement specialized Ruby translator classes. These parsers process the HepScript content and apply custom logic to generate the corresponding target code, offering precise structural control. 4 HepScript Specification Analysis Code Execute Feedback Error Message Refine Input Under Development: Automatically Extend HepScript's Syntax Refine Syntax Deterministic Parsers Dataset Manager Decay Chain Parser Package Manager Selection Parser LLM-assisted Translators Match Particles With Kinematic Properties Decay final states Code snippet for selection Code snippet for storage BOSS job configuration Shell Script Generator BOSS Algorithm Generator ROOT Script Generator ROOT Config (YAML) Parser Other Script Generator Kinematic info Script Template Selection Agent ROOT script snippet Orchestrator HepScript Processor Decay Logic Inference Agent Figure 2: Overview of the HepScript-grounded data analysis workflow for BESIII. The HepScript specification serves as a unified interface, specifying all instructions required to complete the analysis. A dedicated processor generates and orchestrates code snippets for multiple target systems: BOSS (dataset preparation and base selection), ROOT (advanced selection, visualization, and statistical analysis), and auxiliary scripts (e.g., Linux Shell, Python). The generated code is executed within corresponding data processing stacks. Upon failure, the outputs (processor errors and system logs) are fed to a diagnostic agent, which either refines the HepScript specification or invokes the auto- evolution system to extend HepScript’s syntax. Human experts can supervise and intervene at any stage, enabling rapid prototyping and debugging within a human-AI collaborative system. •LLM-Assisted Generation: We employ LLMs in two scenarios, where translation logic is dynamic and deeply analysis-dependent: 1. Cascade Decay Logic: When storing physical variables (e.g., invariant masses) after base selection, the correct mapping between final-state particles and intermediate resonances can be ambiguous. For example, a decay chain containing multiple photons requires identifying which pairs originate from휋 0 or휂meson decays. We prompt an LLM to determine the optimal particle combination based on expert-provided logic (e.g., minimizing(푀 (훾 푖 훾 푗 )−푚 휋 0 ) 2 + (푀 (훾 푘 훾 푙 )−푚 휂 ) 2 , where the subscripts푖,푗,푘, and푙 denote different photons,푀 (훾)is the invariant mass of two-photon combination, and 푚 휋 0 (푚 휂 )is the nominal mass of휋 0 (휂)). The LLM outputs well-commented source code for variable storage (see Appendix B). 2.ROOT Script Generation: ROOT-based tasks are highly domain-specific. However, because ROOT is open-source, the underlying logic of individual tasks is relatively concise. We instruct LLMs to generate the required ROOT scripts from formalized YAML inputs and curated exemplars. These three approaches are integrated within a syntax-directed translation framework. HepScript grammar functions map directly to corresponding Ruby classes and methods within the processor. The final system allows a HepScript specification to be executed directly from the command line, automatically generating the complete suite of required analysis code for BOSS and ROOT. The resulting workflow is illustrated in Fig. 2. 5 4 Generating HepScript: In-context Learning A core claim of this work is that HepScript’s constrained syntax makes it generable by LLMs. However, generating any DSL requires effective strategies for guiding the LLM, especially when embedding specialized domain knowledge. While fine-tuning (FT) is a viable option, it is expensive, difficult to optimize, and hard to adapt to a rapidly evolving DSL. Furthermore, recent studies reveal that optimized Retrieval-Augmented Generation (RAG) can achieve comparable or better syntactic correctness than FT [19]. Therefore, we initially focused on in-context learning via RAG. However, we found that the standard RAG paradigm, which retrieves examples based on the semantic similarity of natural language queries, is insufficient for our domain. 4.1 Limits of Semantic Similarity Retrieval for HEP Workflows Standard RAG systems embed a user’s query and retrieve the most semantically similar examples from a database. While effective for many tasks, HEP analysis is exquisitely sensitive to the details of the selection criteria and analysis-dependent statistical methods. An analysis involving two photons plus a low-energy transition photon in the final states is physically distinct from one involving only two photons, even if their natural language descriptions are close. Using retrieved examples based purely on linguistic similarity leads to incorrect selection criteria, flawed particle combinations, or invalid fit strategies, corrupting the measurement. The core problem is that semantic similarity in natural language does not align with the formal structural similarity that governs physical correctness. The "distance" between two analyses is defined by the topology of the particle decay chain (e.g., the number and types of final-state particles, intermediate resonances), not the words used to describe them. Developing a structure-aware retriever for physical isomorphisms remains an open and challenging problem. 4.2 A Baseline: Comprehensive Single-Shot Grounding In the absence of a structure-aware retriever, we established a strong baseline by providing the LLM with exhaustive grounding information in a single, long-context prompt (typically 30-40k tokens). This approach, while not scalable indefinitely, demonstrates the feasibility of the approach within the current context window and provides an upper bound on performance when all necessary syntax information is available. Our grounding package consists of two components: A Comprehensive Workflow Example: We provide a complete HepScript specification for a canonical BESIII analysis, demonstrating the intended use of all core language constructs in an end-to-end workflow. A Complete Grammar Reference (in YARD): We include YARD-formatted documentation for the public HepScript APIs (see Appendix C). This serves as a formal grammar specification, detailing every function, its parameters, return values, and usage examples. The LLM is instructed to study the comprehensive example and consult the YARD documentation as an authoritative reference during generation. This transforms the generation task from open-ended synthesis to a constrained, reference-driven translation task. As our evaluation (Sec. 5) shows, a well-designed DSL and comprehensive documentation enable reliable code generation even with a single-shot, ultra-long prompt. The full prompt is shown in Appendix D. 5 Evaluation We evaluate HepScript along two dimensions aligned with its dual-use design: (1) as a human-facing abstraction, assessed by its ability to faithfully represent workflows and reduce coding effort; and (2) as an AI-facing interface, assessed by how well LLMs can generate correct HepScript specifications from domain literature. 5.1 Experimental Setup We selected the first fifty BESIII papers from arXiv (from 2009 to the evaluation date), sorted by publication date. Each paper was categorized by research methodology using DeepSeek-V3 [20]; we excluded papers relying on methods beyond HepScript’s current expressiveness (e.g., deep learning). Such papers constitute a small fraction of the corpus. After filtering, 45 papers remained. For each, 6 Table 1: Comparison of success rates (SR) for human-written versus LLM-generated HepScript specifications (BOSS code only). For each LLM, 푁 푆 is the number of successful packages and 푁 퐹 is the number of failed packages. “One Retry SR” and “Three Retry SR” denote success rates after one and three agentic iterations with error message feedback, respectively. HepScriptLLM푁 푆 푁 퐹 SR (%)One Retry SR (%)Three Retries SR (%) Human-written (63 Packages) Deepseek-V362196.9± 2.198.5± 1.5- Deepseek-R156787.7± 4.098.5± 1.5- gpt-4o62196.9± 2.198.5± 1.5- GLM-4.762196.9± 2.198.5± 1.5- Qwen3-Max60393.8± 3.098.5± 1.5- LLM-generated (72 Packages) Deepseek-R1343847.3± 5.887.8± 3.894.6± 2.6 GLM-4.7314143.2± 5.790.5± 3.495.9± 2.3 one domain expert wrote the corresponding HepScript specification, and a second expert verified it to establish our ground truth. We define three evaluation metrics for HepScript specifications: (i) Syntax correctness: The HepScript processor accepts the specifications without errors; (i) Logical correctness: the described workflow is physically meaningful and adheres to the intended analysis, as verified by an expert; (i) Compilation (execution) success: the generated code compiles (runs) successfully in its respective environment, producing expected outputs. A specification is considered overall successful only if it satisfies all three metrics. The evaluation uses five LLMs: DeepSeek-V3, DeepSeek-R1 [21], GPT-4o [22], GLM-4.7 [23], and Qwen3-Max [24]. Among these, DeepSeek-R1 and GLM-4.7 are advanced reasoning models. 5.2 Evaluating HepScript Processor We split this evaluation into three parts: BOSS code generation, ROOT code generation, and HepScript generation within an agentic loop. BOSS Code Generation: The processor’s core translation engine (templates + translators) is deterministic. To verify its correctness, we ran all human-written HepScript specifications through the processor with the LLM-assisted component (see Sec. 3) disabled, yielding 63 algorithm packages (a HepScript specification may produce multiple packages). In all cases, the generated BOSS code compiled without errors, confirming that the processor’s core logic is sound. ROOT Code Generation: Because preparing test-ready datasets for BESIII requires substantial computational resources, we limited the ROOT scripts execution evaluation to two representative analyses:퐽/휓 → 훾휋 + 휋 − 휂 ′ and휓 ′ → 휋 + 휋 − 퐽/휓(→ 훾푝 ̄푝). For each, we wrote a HepScript specification and executed the full analysis pipeline, from dataset preparation to reproducing the original paper’s figures. HepScript Generation (Agentic Loop): Given the full text of a paper, we used reasoning models to generate HepScript specifications following the method in Sec. 4. To evaluate this capability at scale, we used the 45-paper corpus, focusing on dataset preparation and base-selection stages (most code-intensive portions). Executing these specifications yielded 72 algorithm packages. 5.3 Evaluation Results BOSS Code Generation: For the variable storage sub-task, we enabled the LLM-assisted component to compare different LLMs. Table 1 reports the success rates and standard errors, assuming binomial distribution with a uniform prior following a Bayesian inference approach [25]. All models achieved high initial success rates except DeepSeek-R1 (87.7%), whose failures stemmed from four timeout errors due to excessive "overthinking" and three variable name mismatches (common failure across LLMs). Critically, after one agentic retry with error feedback, all models achieved a near-perfect success rate (98.5%), demonstrating the effectiveness of our LLM-assisted translation strategy. 7 ) 2 (GeV/c p -2m p M 0.00 0.05 0.10 0.15 0.20 0.25 0.30 ) 2 Events/(0.005GeV/c 0 10 20 30 40 50 60 70 ) 2 (GeV/c p -2m p M 0.00 0.05 0.10 0.15 0.20 0.25 0.30 ) 2 Events/(0.005GeV/c 0 10 20 30 40 50 60 70 1.41.61.822.22.42.62.83 ) 2 (GeV/c 'η - π + π M 0 100 200 300 400 500 ) 2 Events / (0.008 GeV/c 1.91.9522.052.12.15 ) 2 (GeV/c p M 0 10 20 30 40 50 60 ) 2 Events / (0.003 GeV/c Figure 3: Comparison of original and reproduced figures. Top panels: original figures from BESIII publications: (left)퐽/휓 → 훾휋 + 휋 − 휂 ′ [26] and (right)휓 ′ → 휋 + 휋 − 퐽/휓(→ 훾푝 ̄푝)[27]. Bottom panels: reproduced figures. In the right column, the dashed and solid curves denote the fitted background function and the fit result, respectively. Note that these reproduced figures serve strictly to validate the automated pipeline and should not be interpreted as official physics results. HepScript Generation: As shown in Table 1, 47.3% (43.2%) of specifications generated by Deepseek-R1 (GLM-4.7) succeeded on the first attempt. Failures primarily arise from (1) incor- rect usage of HepScript’s syntax (76%) such as calling undefined methods or passing an incorrect number of arguments, and (2) physics misinterpretations (24%), such as omitting a kinematic fit that constrains the final state to the center-of-mass energy, or referring to particles that have not yet been reconstructed. After a single agentic retry with error feedback, the success rates jumped to 87.8% (90.5%). After three iterations, the success rates are about 95% for both LLMs. The remaining failures involved multiple errors that require many more retries. These results prove that a well-designed DSL, paired with an iterative agentic loop, enables highly reliable automation—a promising outcome for human-AI collaborative systems. ROOT Code Generation: In both case studies, the generated ROOT scripts execute without error and reproduce figures matching the original papers, as shown in Fig. 3. While the sample size is limited, the successful execution suggests that LLMs can effectively translate HepScript tasks into analysis-ready ROOT code. We emphasize that these reproduced figures serve strictly as a technical validation of the automated pipeline and should not be interpreted as official physics results. Reduction in Coding Effort: Across the two case studies, HepScript reduced the volume of analysis code (measured by character count, excluding comments and blank lines) written by humans by an average of 93%. This reduction comes primarily from eliminating boilerplate BOSS code and repetitive ROOT plotting routines. For human experts, this translates to faster prototyping and fewer low-level errors; for AI agents, it defines a dramatically smaller action space. 5.4 Limitations of the Evaluation Benchmark Scope. Our corpus of 45 papers, while representative of typical BESIII measurements, does not cover the full diversity of HEP workflows. Notably absent are complex analyses such as cross-section measurements and amplitude analyses, which may require additional language 8 constructs. This reveals a critical need for the community: a structured benchmark for HEP analysis workflows. Analysis Logic Evaluation. Assessing the logical correctness of LLM-generated HepScript specifica- tions requires an expert review process, which is neither scalable nor objective. However, this manual evaluation remains unavoidable, as it demands deep HEP knowledge that cannot yet be automated. Computational Cost. Full execution-based evaluation, particularly for ROOT scripts, requires preparing large datasets and running computationally intensive simulations. This limits our ROOT evaluation to two case studies. Developing lightweight surrogate metrics that correlate with execution correctness, or creating small-scale "toy" datasets that preserve the essential structure of analyses while reducing computational demands, would enable broader validation. 6 Discussion and Future Work 6.1 Expressiveness vs. Abstraction A fundamental challenge in designing a dual-use DSL is balancing expressiveness against LLM- generability. Higher abstraction simplifies LLM generation, but necessarily reduces fine-grained control over the workflow; lower abstraction preserves flexibility but increases the risk of LLM hallucination. Finding the optimal balance requires iterative refinements guided by real-world analysis requirements. The current HepScript covers a subset of BESIII analysis types but lacks constructs for systematic uncertainty estimation, a critical component of any physics result. Future work will expand HepScript’s expressiveness to support more sophisticated analyses including systematic uncertainty estimation. We will further explore a self-evolutionary mechanism that autonomously extends HepScript’s grammar. The mechanism would ingest domain papers and identify coverage gaps from practical usage, as depicted in Fig. 2. Initially, human experts would validate and integrate the proposed syntax extensions, with the system moving toward full automation as it matures. 6.2 Toward Structure-Aware Retrieval for LLM Generation Our current approach of HepScript generation (a comprehensive example and YARD syntax reference) is not a scalable long-term solution as HepScript grows. This work therefore identifies a clear research agenda: the development of structure-aware retrieval mechanisms that operate on the formal topology of particle physics processes rather than semantic text similarity. We believe that developing structure- aware embeddings or domain-specific retrieval algorithms for scientific workflows is a crucial next step for any multi-agent system for scientific discovery, and is our top priority. 6.3 Development of an Agentic Memory Mechanism Each HepScript specification formalizes a complete BESIII analysis pipeline, collectively forming a highly structured knowledge database. Viewed through the lens of harness engineering, this repository extends beyond a static reference to become a dynamic memory module for future multi- agent systems [28]. We envision a self-reinforcing cognitive loop where memory, skills, and protocols continuously interact [29]. Specifically, the database would supply structural evidence and successful execution trajectories, allowing agents to distill stored experience into reusable analytical procedures (skills) for new workflows. These skills would then transition from abstract reasoning into governed action via HepScript’s constrained grammar and the processor’s validation loop, which act as strict protocols providing typed interfaces and boundary checks that ensure safe, verified execution. Finally, closing the loop through result assimilation, successfully executed analyses would be normalized by the protocol layer and written back into memory as new, unified specifications. As this self-reinforcing cycle accelerates, the expanding memory repository would unlock frontier possibilities for machine learning on the workflows themselves—such as training models to predict effective selection criteria for specific particle final states, or to autonomously route protocol strategies based on historical success rates. 9 7 Conclusion This paper demonstrates that DSL-grounded abstraction is a powerful strategy for automating intricate, framework-bound scientific workflows, using high-energy physics data analysis as a rigorous testbed. We show that a carefully designed DSL collapses the action space and acts as a shared representation layer that bridges human expertise, AI automation, and production environments. Ultimately, it shifts the fundamental problem of automation from how to execute an analysis to what to specify. We instantiated this approach with HepScript, a Ruby-embedded DSL for the BESIII experiment. The evaluation shows that HepScript reduces manual coding effort by 93% and, more critically, enables AI agents to autonomously generate valid specifications from published literature with a 95% success rate after agentic retries. These results validate the potential of a dual-use DSL in human-AI collaborative systems, where agents propose workflows and humans—or specialized diagnostic agents—provide corrective feedback. Looking forward, this work lays the foundation for a self-evolutionary system that could autonomously abstract DSL grammar from domain literature, implement new language constructs, generate DSL specifications for real-world analyses, and iteratively refine the syntax based on deployment feedback. Such a system would close the loop, enabling the DSL and its associated agents to continuously improve alongside the domain. While developed and evaluated within the BESIII experiment, the principles of this methodology are readily extensible to other HEP experiments, such as Belle I [30] or LHCb [31], as well as other data-intensive scientific domains. We hope this work inspires such efforts. Acknowledgments and Disclosure of Funding This project is supported by the Strategic Priority Research Program of Chinese Academy of Sciences under Grant XDA0480600; Program of Science and Technology Development Plan of Jilin Province of China under Contract No. 20230101021JC. The authors declare no competing interests. We would like to thank the BESIII Collaboration for their support on test datasets and softwares; the IHEP computing center for their support on computing resources; Yu-Zhe Shi (from School of Advanced Manufacturing and Robotics, PKU), Kun He and Ming-Chen Liu (from School of Computer Science and Technology, HUST) for their innovative, pioneering works on automatical DSL design, which inspires us to develop HepScript; Jie Liu, Liang-Yi Kang, and Shuai Wang (from Institute of Software, CAS) for the helpful discussions. References [1] H. Wang, T. Fu, Y. Du, et al., Nature 620, 47 (2023). [2] Y. Ioannidis, Commun. ACM 67, 5 (2024). [3] G. Mai, W. Huang, J. Sun, et al., ACM Trans. Spatial Algorithms Syst. 10, 1 (2024). [4] A. Weltman et al., Publ. Astron. Soc. Austral. 37, e002 (2020). [5]O. Brüning and L. Rossi, eds., The High Luminosity Large Hadron Collider (World Scientific, Mar. 2024). [6] S. Kambhampati, K. Valmeekam, L. Guan, et al., arXiv:2402.01817 (2024). [7] T. Kuhr, C. Pulvermacher, M. Ritter, et al., Comput. Softw. Big Sci. 3, 1 (2019). [8] M. Ablikim, Z. An, J. Bai, et al., Nucl. Instrum. Meth. A 614, 345 (2010). [9] E. Gendreau-Distler, J. Ho, D. Kim, et al., arXiv:2512.07785 (2025). [10] T. Menzo, A. Roman, S. Gleyzer, et al., arXiv:2512.15867 (2025). [11] A. Badea, Y. Chen, M. Maggi, et al., arXiv:2603.05735 (2026). [12] E. A. Moreno, S. Bright-Thonney, A. Novak, et al., arXiv:2603.20179 (2026). [13] H. B. Prosper, S. Sekmen, and G. Unel, arXiv:2203.09886 (2022). [14] A. Heidelbach, M. Eliachevitch, N. Braun, et al., belle2/b2luigi: v1.2.2 (2025). [15] C. Cooper Harris and A. Desai, Comput. Phys. Commun. 322, 110062 (2026). [16] Anthropic, Equipping agents for the real world with agent skills. Anthropic Engineering Blog (2025). [17] J. Zou, W. Li, Q. Ma, et al., Eur. Phys. J. C 84, 937 (2024). 10 [18] I. Antcheva, M. Ballintijn, B. Bellenot, et al., Comput. Phys. Commun. 180, 2499 (2009). [19] N. Bassamzadeh and C. Methani, arXiv:2407.02742 (2024). [20] DeepSeek-AI, arXiv:2412.19437 (2024). [21] DeepSeek-AI, Nature 645, 633 (2025). [22] OpenAI, arXiv:2410.21276 (2024). [23] Zhupu-AI, arXiv:2508.06471 (2025). [24] A. Yang et al., arXiv:2505.09388 (2025). [25] P. D.Hoff, A first course in Bayesian statistical methods (Springer New York, Sept. 2009). [26] M. Ablikim et al. (BESIII), Phys. Rev. Lett. 106, 072002 (2011). [27] M. Ablikim et al. (BESIII), Chin. Phys. C 34, 421 (2010). [28] K. Li, B. Liu, B. Mellado, et al., Front. Phys. 21, 096401 (2026). [29] C. Zhou, H. Chai, W. Chen, et al., arXiv:2604.08224 (2026). [30] E. Kou, P. Urquijo, W. Altmannshofer, et al., PTEP 2020, 029201 (2020). [31] A. A. Alves Jr. et al. (LHCb), JINST 3, S08005 (2008). 11 Technical appendices and supplementary material A HepScript Example ### Dat aset Pr epar at i on ( BOSS) ### Dat as et Manager. l oad_r eal _dat a(' c onf i g/ BES3_dat as et . md') Dat as et Manager. l oad_i nc l us i v e_mc (' c onf i g/ BES3_i nc MC_s ampl e. md') ps i p_dat a = Dat as et Manager. r eal _dat a. f i nd(" 709_3686") ps i p_i nc MC = Dat as et Manager. i nc l us i v e_mc . f i nd(" 709_3686") dec ay _c ar d_f or _s i gnal = <<~DECAYCARD Dec ay ps i ( 2S) 1. 0000 Lambda0 ant i - Si gma0 omega PHSP; Enddec ay Dec ay ant i - Si gma0 1. 0000 gamma ant i - Lambda0 PHSP; Enddec ay Dec ay omega 1. 000 pi + pi - pi 0 OMEGA_DALI TZ; Enddec ay Dec ay Lambda0 1. 0 p+ pi - Hy pWK; Enddec ay Dec ay ant i - Lambda0 1. 00 ant i - p- pi + Hy pWK; Enddec ay Dec ay pi 0 1. 00 gamma gamma PHSP; Enddec ay End DECAYCARD ex MC_s i gnal = Dat as et Manager. c r eat e_ex c l us i v e_mc |conf i g| conf i g. s ampl e_name = " my _s i gnal _ex c l us i v e_mc " conf i g. r el at ed_dat as et = ps i p_dat a conf i g. ev ent s = 100000 conf i g. dec ay _c ar d = dec ay _c ar d_f or _s i gnal conf i g. c r os s _s ec t i on = : def aul t ### Base Sel ect i on ( BOSS) ### al g_name = " LSomega" my _Al gor i t hm = Al gor i t hm. new( al g_name) my _Al gor i t hm. s et _header ( ["# al g_nameAl g/# al g_name. h"] ) # set t he header f i l e of t he al gor i t hm. . s et _c ons t ant ( " ECMS"=> [: doubl e, 3. 686] ) ev ent _s el ec t i on=Sel ec t i on. new ev ent _s el ec t i on. s el ec t _t r ac k # some r equi r ement s f or char ged t r ack sel ect i on c os _t het a 0. 93 Vz 100. 0 Vr 10. 0 nChr p " >=3" nChr n " >=3" nNet " ==0" . s el ec t _phot on # some r equi r ement s f or phot on sel ect i on t dc _emc _s t ar t 0 t dc _emc _end 14 angl e_t o_t r ac k 10. 0 ener gy Thr es hol d_b 0. 025 ener gy Thr es hol d_e 0. 050 nGam " >=3" . pi d( has _l ept on = f al s e) # r equi r ement s f or PI D ( par t i cl e i dent i f i cat i on) sel ect i on pr ob_c ut 0. 001 i dent i f y : pr ot on, " f r om_k aon_and_pi on" npr p " >=1" npr m " >=1" . r emov e( [: pr p <= : c hr gp, : pr m <= : c hr gn] ) . s el ec t _i s ol at ed_phot on angl e_t o_pr m_t r ac k 20. 0 nGam " >=3" . k al man_k i nemat i c _f i t ( [: gamma, : gamma] ) # r econst r uct speci f i c i nt er medi at e st at es i nv ar i ant _mas s _of (: gamma,: gamma) . c ons t r ai n_t o_nomi nal _mas s _of (: pi 0) c hi 2_c ut 25 npi 0 " >=1" . as s i gn( : c hr gp => : pi p, : c hr gn => : pi m ) # assume t he posi t i ve char ged t r acks as pi p wi t hout PI D. Si mi l ar l y, negat i ve char ged t r acks as pi m. . s ec ondar y _v er t ex _f i t ( [: pr p, : pi m] ) # per f or m a secondar y ver t ex f i t f or t he pr p and pi m par t i cl es bui l d_v i r t ual _par t i c l e(: Lambda) . by _mi ni mi z i ng_mas s _di f f er enc e # r econst r uct t he Lambda bar yon r emov e_us ed_par t i c l e_f r om_c andi dat e_l i s t . s ec ondar y _v er t ex _f i t ( [: pr m, : pi p] ) bui l d_v i r t ual _par t i c l e(: Lambda_bar) . by _mi ni mi z i ng_mas s _di f f er enc e r emov e_us ed_par t i c l e_f r om_c andi dat e_l i s t . k i nemat i c _f i t ( # per f or m a ki nemat i c f i t wi t h mul t i pl e hypot heses [: Lambda, : Lambda_bar, : gamma, : pi 0, : pi p, : pi m] ) nomi nal # nomi nal ki nemat i c f i t , use moment um of par t i cl es f r om t hi s f i t . v er t ex _f i t ( [4, 5] ) # per f or m a ver t ex f i t t o ensur e t hat t he pi p and pi m ar e f r om omega ar e f r om common ver t ex. c ons t r ai n_f our _moment um # const r ai n sum of t he par t i ci pat ed par t i cl es' f our - moment um t o t he CMS syst em. . k i nemat i c _f i t ( [: Lambda, : Lambda_bar, : gamma, : gamma, : pi 0, : pi p, : pi m] ) # per f or m an addi t i onal ki nemat i c f i t wi t h t he one mor e phot on c ons t r ai n_f our _moment um v er t ex _f i t ( [5, 6] ) my _Al gor i t hm. wi t h_dec ay _c ar d( dec ay _c ar d_f or _s i gnal ) . appl y ( ev ent _s el ec t i on) r oot _f i l es = my _Al gor i t hm. ex ec ut e_on( [ ps i p_dat a, ps i p_i nc MC, ex MC_s i gnal ] ) # execut e t he al gor i t hm on dat aset s t o obt ai n r oot f i l es ### Fur t her sel ect i on ( ROOT) ### r oot _ana = Root Anal y s i s. new( r oot _f i l es ) # appl y f ur t her sel ect i on cut s r oot _ana. def i ne_v ar i abl e : Rec _pi pi, ex pr es s i on: " ( P4_pi p_omega+P4_pi m_omega) . Rec . m( ) " # use exi st i ng var i abl es t o cal cul at e new var i abl es. . def i ne_c ut : v et o_J ps i _dec ay, " abs ( Rec _pi pi - 3. 097) >0. 005" . def i ne_c ut : Lambda_mas s _wi ndow, " abs ( m_l ambda- 1. 1157) <0. 01" # al ways i n uni t of GeV . def i ne_c ut : Lambda_bar _mas s _wi ndow, " abs ( m_l ambda_bar - 1. 1157) <0. 01" . def i ne_c ut : pi 0_mas s _wi ndow, " abs ( m_pi 0- 0. 134) <0. 007" . def i ne_c ut : Si gma_bar 0_mas s _wi ndow, " abs ( m_s i gma_bar 0- 1. 1926) <0. 008" . def i ne_c ut : Lambda_dec ay _l engt h, " l engt h_Lambda>0. " . def i ne_c ut : Lambda_bar _dec ay _l engt h, " l engt h_Lambda_bar >0. " . def i ne_r ange : omega_f i t _r ange, v ar i abl e: : momega, r ange: [0. 65, 0. 95] # def i ne a f i t r ange f or l at er use i n t he anal ysi s. . def i ne_c ut : omega_f i t _r ange, wi t h_r ange(: omega_f i t _r ange)# use pr edef i ned r ange obj ect t o cr eat e var i abl e cut . . def i ne_r ange : omega_s i deband_r ange, v ar i abl e: : momega, l ef t _r ange: [0. 630, 0. 694] , r i ght _r ange: [0. 886, 0. 95] ### Vi sual i z at i on ( ROOT) ### # dr aw di st r i but i ons of var i abl es r oot _ana. f r om( [ ps i p_dat a, ps i p_i nc MC, ex MC_s i gnal ] ) . c r eat e_hi s t ogr am : momega_di s t r i but i on, v ar i abl e: : momega, hi s t _c onf i g: name: " m_omega", x mi n: 0. 65, x max : 0. 95, nbi ns : 100, t i t l e: ni l, x _ax i s _t i t l e: " m_ #omega ( GeV/ #i t c 2 ) ", y _ax i s _t i t l e: " Ev ent s / ( GeV/ #i t c 2 ) ", c ol or _s c heme: : aut o ### St at i st i cal Anal ysi s ( ROOT) ### # bui l d f i t model ( si g + bkg) r oot _ana. def i ne_f i t : omega_s i gnal _y i el d_f i t, f i t _c onf i g: des c : " ex t r ac t s i gnal y i el d i n t he momega di s t r i but i on", t y pe: : ex t ended_unbi nned_l i k el i hood, f i t _r ange: : omega_f i t _r ange, v ar i abl e: : momega, s i gnal : f unc t i on: : Doubl e_Gaus s i an, par amet er s : mean1: i ni t i al _v al ue: 0. 782, mi n: 0. 75, max : 0. 81, f r e: t r ue , s i gma1: i ni t i al _v al ue: 0. 0008, mi n: 0. 001, max : 0. 02, f r e: t r ue , mean2: i ni t i al _v al ue: 0. 818, mi n: 0. 78, max : 0. 85, f r e: t r ue , s i gma2: i ni t i al _v al ue: 0. 008, mi n: 0. 001, max : 0. 02 ,f r e: t r ue , , bac k gr ound: f unc t i on: : RooPol y nomi al, par amet er s : p0: i ni t i al _v al ue: 10, mi n: -100 , max : 100 , f r e: t r ue , p1: i ni t i al _v al ue: -5, mi n: -100, max : 100, f r e: t r ue # per f or m t he f i t t o t he psi p_dat a dat aset and ext r act t he si gnal yi el d f i t _r es ul t = r oot _ana. f i t (: omega_s i gnal _y i el d_f i t, t o: : ps i p_dat a) s i gnal _y i el d = f i t _r es ul t . get _c ont r i but i on_of (: s i gnal) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 Figure 4: Example of HepScript’s grammar. The involved decay process is 휓(3686)→ Λ ̄ Σ 0 휔. 12 ### Dat aset Pr epar at i on ( BOSS) ### Dat as et Manager. l oad_r eal _dat a(' c onf i g/ BES3_dat as et . md') Dat as et Manager. l oad_i nc l us i v e_mc (' c onf i g/ BES3_i nc MC_s ampl e. md') ps i p_dat a = Dat as et Manager. r eal _dat a. f i nd(" 709_3686") ps i p_i nc MC = Dat as et Manager. i nc l us i v e_mc . f i nd(" 709_3686") dec ay _c ar d_f or _s i gnal = <<~DECAYCARD Dec ay ps i ( 2S) 1. 0000 Lambda0 ant i - Si gma0 omega PHSP; Enddec ay Dec ay ant i - Si gma0 1. 0000 gamma ant i - Lambda0 PHSP; Enddec ay Dec ay omega 1. 000 pi + pi - pi 0 OMEGA_DALI TZ; Enddec ay Dec ay Lambda0 1. 0 p+ pi - Hy pWK; Enddec ay Dec ay ant i - Lambda0 1. 00 ant i - p- pi + Hy pWK; Enddec ay Dec ay pi 0 1. 00 gamma gamma PHSP; Enddec ay End DECAYCARD ex MC_s i gnal = Dat as et Manager. c r eat e_ex c l us i v e_mc |conf i g| conf i g. s ampl e_name = " my _s i gnal _ex c l us i v e_mc " conf i g. r el at ed_dat as et = ps i p_dat a conf i g. ev ent s = 100000 conf i g. dec ay _c ar d = dec ay _c ar d_f or _s i gnal conf i g. c r os s _s ec t i on = : def aul t ### Base Sel ect i on ( BOSS) ### al g_name = " LSomega" my _Al gor i t hm = Al gor i t hm. new( al g_name) my _Al gor i t hm. s et _header ( ["# al g_nameAl g/# al g_name. h"] ) # set t he header f i l e of t he al gor i t hm. . s et _c ons t ant ( " ECMS"=> [: doubl e, 3. 686] ) ev ent _s el ec t i on=Sel ec t i on. new ev ent _s el ec t i on. s el ec t _t r ac k # some r equi r ement s f or char ged t r ack sel ect i on c os _t het a 0. 93 Vz 100. 0 Vr 10. 0 nChr p " >=3" nChr n " >=3" nNet " ==0" . s el ec t _phot on # some r equi r ement s f or phot on sel ect i on t dc _emc _s t ar t 0 t dc _emc _end 14 angl e_t o_t r ac k 10. 0 ener gy Thr es hol d_b 0. 025 ener gy Thr es hol d_e 0. 050 nGam " >=3" . pi d( has _l ept on = f al s e) # r equi r ement s f or PI D ( par t i cl e i dent i f i cat i on) sel ect i on pr ob_c ut 0. 001 i dent i f y : pr ot on, " f r om_k aon_and_pi on" npr p " >=1" npr m " >=1" . r emov e( [: pr p <= : c hr gp, : pr m <= : c hr gn] ) . s el ec t _i s ol at ed_phot on angl e_t o_pr m_t r ac k 20. 0 nGam " >=3" . k al man_k i nemat i c _f i t ( [: gamma, : gamma] ) # r econst r uct speci f i c i nt er medi at e st at es i nv ar i ant _mas s _of (: gamma,: gamma) . c ons t r ai n_t o_nomi nal _mas s _of (: pi 0) c hi 2_c ut 25 npi 0 " >=1" . as s i gn( : c hr gp => : pi p, : c hr gn => : pi m ) # assume t he posi t i ve char ged t r acks as pi p wi t hou PI D. Si mi l ar l y, negat i ve char ged t r acks as pi m. . s ec ondar y _v er t ex _f i t ( [: pr p, : pi m] ) # per f or m a secondar y ver t ex f i t f or t he pr p and pi m par t i cl es bui l d_v i r t ual _par t i c l e(: Lambda) . by _mi ni mi z i ng_mas s _di f f er enc e # r econst r uct t he Lambda bar yon r emov e_us ed_par t i c l e_f r om_c andi dat e_l i s t . s ec ondar y _v er t ex _f i t ( [: pr m, : pi p] ) bui l d_v i r t ual _par t i c l e(: Lambda_bar) . by _mi ni mi z i ng_mas s _di f f er enc e r emov e_us ed_par t i c l e_f r om_c andi dat e_l i s t . k i nemat i c _f i t ( # per f or m a ki nemat i c f i t wi t h mul t i pl e hypot heses [: Lambda, : Lambda_bar, : gamma, : pi 0, : pi p, : pi m] ) nomi nal # nomi nal ki nemat i c f i t , use moment um of par t i cl es f r om t hi s f i t . v er t ex _f i t ( [4, 5] ) # per f or m a ver t ex f i t t o ensur e t hat t he pi p and pi m ar e f r om omega ar e f r om common ver t ex. c ons t r ai n_f our _moment um # const r ai n sum of t he par t i ci pat ed par t i cl es' f our - moment um t o t he CMS syst em. . k i nemat i c _f i t ( [: Lambda, : Lambda_bar, : gamma, : gamma, : pi 0, : pi p, : pi m] ) # per f or m an addi t i onal ki nemat i c f i t wi t h t he one mor e phot on c ons t r ai n_f our _moment um v er t ex _f i t ( [5, 6] ) my _Al gor i t hm. wi t h_dec ay _c ar d( dec ay _c ar d_f or _s i gnal ) . appl y ( ev ent _s el ec t i on) r oot _f i l es = my _Al gor i t hm. ex ec ut e_on( [ ps i p_dat a, ps i p_i nc MC, ex MC_s i gnal ] ) # execut e t he al gor i t hm on dat aset s t o obt ai n r oot f i l es ### Fur t her sel ect i on ( ROOT) ### r oot _ana = Root Anal y s i s. new( r oot _f i l es ) # appl y f ur t her sel ect i on cut s r oot _ana. def i ne_v ar i abl e : Rec _pi pi, ex pr es s i on: " ( P4_pi p_omega+P4_pi m_omega) . Rec . m( ) " # use exi st i ng var i abl es t o cal cul at e new var i abl es. . def i ne_c ut : v et o_J ps i _dec ay, " abs ( Rec _pi pi - 3. 097) >0. 005" . def i ne_c ut : Lambda_mas s _wi ndow, " abs ( m_l ambda- 1. 1157) <0. 01" # al ways i n uni t of GeV . def i ne_c ut : Lambda_bar _mas s _wi ndow, " abs ( m_l ambda_bar - 1. 1157) <0. 01" . def i ne_c ut : pi 0_mas s _wi ndow, " abs ( m_pi 0- 0. 134) <0. 007" . def i ne_c ut : Si gma_bar 0_mas s _wi ndow, " abs ( m_s i gma_bar 0- 1. 1926) <0. 008" . def i ne_c ut : Lambda_dec ay _l engt h, " l engt h_Lambda>0. " . def i ne_c ut : Lambda_bar _dec ay _l engt h, " l engt h_Lambda_bar >0. " . def i ne_r ange : omega_f i t _r ange, v ar i abl e: : momega, r ange: [0. 65, 0. 95] # def i ne a f i t r ange f or l at er use i n t he anal ysi s. . def i ne_c ut : omega_f i t _r ange, wi t h_r ange(: omega_f i t _r ange)# use pr edef i ned r ange obj ect t o cr eat e var i abl e cut . . def i ne_r ange : omega_s i deband_r ange, v ar i abl e: : momega, l ef t _r ange: [0. 630, 0. 694] , r i ght _r ange: [0. 886, 0. 95] ### Vi sual i z at i on ( ROOT) ### # dr aw di st r i but i ons of var i abl es r oot _ana. f r om( [ ps i p_dat a, ps i p_i nc MC, ex MC_s i gnal ] ) . c r eat e_hi s t ogr am : momega_di s t r i but i on, v ar i abl e: : momega, hi s t _c onf i g: name: " m_omega", x mi n: 0. 65, x max : 0. 95, nbi ns : 100, t i t l e: ni l, x _ax i s _t i t l e: " m_ #omega ( GeV/ #i t c 2 ) ", y _ax i s _t i t l e: " Ev ent s / ( GeV/ #i t c 2 ) ", c ol or _s c heme: : aut o ### St at i st i cal Anal ysi s ( ROOT) ### # bui l d f i t model ( si g + bkg) r oot _ana. def i ne_f i t : omega_s i gnal _y i el d_f i t, f i t _c onf i g: des c : " ex t r ac t s i gnal y i el d i n t he momega di s t r i but i on", t y pe: : ex t ended_unbi nned_l i k el i hood, f i t _r ange: : omega_f i t _r ange, v ar i abl e: : momega, s i gnal : f unc t i on: : Doubl e_Gaus s i an, par amet er s : mean1: i ni t i al _v al ue: 0. 782, mi n: 0. 75, max : 0. 81, f r e: t r ue , s i gma1: i ni t i al _v al ue: 0. 0008, mi n: 0. 001, max : 0. 02, f r e: t r ue , mean2: i ni t i al _v al ue: 0. 818, mi n: 0. 78, max : 0. 85, f r e: t r ue , s i gma2: i ni t i al _v al ue: 0. 008, mi n: 0. 001, max : 0. 02 ,f r e: t r ue , , bac k gr ound: f unc t i on: : RooPol y nomi al, par amet er s : p0: i ni t i al _v al ue: 10, mi n: -100 , max : 100 , f r e: t r ue , p1: i ni t i al _v al ue: -5, mi n: -100, max : 100, f r e: t r ue # per f or m t he f i t t o t he psi p_dat a dat aset and ext r act t he si gnal yi el d f i t _r es ul t = r oot _ana. f i t (: omega_s i gnal _y i el d_f i t, t o: : ps i p_dat a) s i gnal _y i el d = f i t _r es ul t . get _c ont r i but i on_of (: s i gnal) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 Figure 4: Example of HepScript’s grammar (continued). 13 B Storing Variables for Kinematic Fit / / =====Reconst r uct i nt er medi at e par t i cl es ===== p_pi 0 = p_gamma_pi 0_1 + p_gamma_pi 0_2; / / pi 0 f r om t wo phot ons p_Si gmap = p_pr p + p_pi 0; / / Si gma+ f r om pr p + pi 0 p_c hi _c 1 = p_Lambda_bar + p_Si gmap + p_pi m; / / chi _c1 f r om Lambda_bar + Si gma+ + pi m p_ps i p = p_gamma_ps i p + p_c hi _c 1; / / psi p f r om gamma + chi _c1 / / Get CMS boost vect or f r om psi p Hep3Vec t or bet aLab = p_ps i p.boos t Vec t or( ) ; / / ===== St or e ki nemat i c var i abl es ===== / / 1. psi p m_mps i p = p_ps i p.m( ) ; m_P4_psi p[0] = p_ps i p.px( ) ; m_P4_psi p[1] = p_ps i p.py( ) ; m_P4_psi p[2] = p_ps i p.pz( ) ; m_P4_psi p[3] = p_ps i p.e( ) ; m_d3_ps i p = p_ps i p.r ho( ) ; HepLor ent z Vec t or p_ps i p_c ms = p_ps i p; p_ps i p_c ms .boos t( - bet aLab) ; m_c os _ps i p = p_ps i p_c ms .c os Thet a( ) ; / / 2. gamma_psi p m_mgamma_ps i p = p_gamma_psi p.m( ) ; m_P4_gamma_psi p[0] = p_gamma_ps i p.px( ) ; m_P4_gamma_psi p[1] = p_gamma_ps i p.py( ) ; m_P4_gamma_psi p[2] = p_gamma_ps i p.pz( ) ; m_P4_gamma_psi p[3] = p_gamma_ps i p.e( ) ; m_d3_gamma_ps i p = p_gamma_psi p.r ho( ) ; HepLor ent z Vec t or p_gamma_ps i p_c ms = p_gamma_ps i p; p_gamma_ps i p_c ms .boos t( - bet aLab) ; m_c os _gamma_ps i p = p_gamma_ps i p_c ms .c os Thet a( ) ; / / 3. r est ot her par t i cl es / / . . . ( be omi t t ed) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 Figure 5: LLM-generated BOSS code snippets for storing kinematic variables of particles. C HepScript Syntax Reference in YARD modul e Ev ent Cut # Cal c ul at es i nv ar i ant mas s of par t i c l e c ombi nat i on # @par am ar gs [ Ar r ay <Sy mbol >] Par t i c l e names f or mas s c al c ul at i on # @r et ur n [ Ev ent Cut ] s el f f or met hod c hai ni ng # @r ai s e [ Ar gument Er r or ] i f i nv al i d par t i c l e t y pes pr ov i ded # @ex ampl e Cal c ul at e pi p pi m i nv ar i ant mas s # i nv ar i ant _mas s _of ( : pi p, : pi m) def i nv ar i ant _mas s _of(* ar gs) end # Appl i es r ange c ut ( r equi r e a v ar i abl e t o s t ay bet ween t he l ower l i mi t and upper l i mi t ) # @par am mi n [ Fl oat ] Lower l i mi t v al ue # @par am max [ Fl oat ] Upper l i mi t v al ue # @r et ur n [ Ev ent Cut ] s el f f or met hod c hai ni ng # @not e f r equent l y us ed f or mas s wi ndow c ut s # @ex ampl e Sel ec t J / ps i mas s wi ndow, c ombi ni ng ep and em t r ac k s # i nv ar i ant _mas s _of ( : ep, : em) . bet ween( 3. 0, 3. 2) # GeV def bet ween(mi n, max) end end 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Figure 6: YARD format documentation for syntax reference. The presented method is for applying invariant mass range requirements. D Prompt for Generating HepScript Specification # Role: You are an expert in high energy physics (HEP) data analysis and software engineering , specialized at BESIII experiment and tasked with translating analysis workflows from BESIII published papers into structured Ruby DSL codes ." 14 # Task: Translate HEP Analysis Workflow to Ruby DSL You are given: - A High Energy Physics (HEP) paper describing an analysis at BESIII experiment. - A Ruby DSL (Domain -Specific Language) for expressing dataset preparation and event selection. - A comprehensive DSL example and a YARD -formatted DSL manual. Your objective is to translate **only the dataset preparation and event selection parts** of the analysis workflow from the paper into Ruby DSL code , using **only existing DSL capabilities **. Follow the rules and guidelines below strictly. --- ## 1. Scope & Endpoint ### Dataset Preparation - Write ** decay cards ** for each signal process as described in the paper. Also Write ** decay card** for background process , if the paper mentions or implies that this background is simulated in the analysis. These cards are used to generate exclusive Monte Carlo (MC) samples. - If a particle is reconstructed via multiple decay modes , create a separate decay card for each mode. - **Decay card format :** Follow EvtGen syntax and EvtGen particle names. Use ‘PHSP ‘ generator if the specific generator is uncertain . - **Top mother particle :** If the paper lacks the a top mother particle (e.g., electron and positron directly produces the signal final states without intermediate mesons like :Jpsi or :psi(2S), in some cross section measurements), use ‘psi (4260) ‘ as the top mother particle (BESIII convention for simulation) in the decay card. - ** Particle aliasing :** When a particle appears in multiple decay modes within the same card , define an alias to separate them (see example below). ‘ruby example_decay_card_with_alias = <<~DECAYCARD Alias another_phi phi Decay chi_c1 1.000 phi another_phi HELAMP 0 0 1 0 1 0 0 0 1 0 1 0 0 0; Enddecay Decay phi 1.000 K+ K- VSS; Enddecay Decay another_phi 1.000 pi+ pi- pi0 PHSP; Enddecay End DECAYCARD ‘ ### Event Selection - Include **all event selection steps occurring BEFORE or DURING the kinematic fit **. - After the kinematic fit ends , the energy and momentum of participating particles are automatically corrected. ** Exclude any cuts applied to quantities derived from kinematic -fit -corrected variables ** (directly or indirectly). 15 - If multiple kinematic fits exist , stop at the **final fit **. Any cuts after that are out of scope. - ** Kalman kinematic fit:** Do **not** end at a Kalman kinematic fit. Use it only when the paper explicitly mentions a fit to reconstruct intermediate particles like pi0 , eta , etc. (Kalman fit typically constrains to a nominal mass of a light meson , which is called "1-C" representing "one constraint on mass". Contrastively , the kinematic fit constrains the four -momentum of the final state system to the center -of-mass energy , which is called "4-C" representing "four constraints on energy -momentum ". The DSL provides a method to perform mass constraint on the final state system .) --- ## 2. Translation Guidelines - Map paper procedures **1:1** to DSL code whenever possible. - Maintain the original physics meaning for all expressed steps. - Add concise comments explaining the DSL code. --- ## 3. Translation Process 1. Extract analysis steps from the paper in sequence. 2. For each step , attempt to express it using ** current DSL capabilities **. 3. **If the current DSL cannot express a specific procedure or selection criterion , skip that step entirely ** (do not comment on the omission). 4. Continue with subsequent steps that **can** be expressed. --- ## 4. Multiple Signal Processes - If the paper defines multiple signal processes , define separate ‘ Algorithm ‘ instances when needed (such that these process have different final states and selection criteria). - Use existing DSL patterns for handling multiple datasets. --- ### Special Case: Shared Final States - If multiple processes share identical final states and selection criteria (e.g., chi_c0 , chi_c1 , chi_c2), you may create a ** single ** ‘Algorithm ‘ instance for all. The resulting algorithm will apply to all processes because they share final states and selection. - ‘with_decay_card ()‘ method is used to generate header files (.h) for an algorithm , defining kinematic variables for particles from the input decay card. One ‘Algorithm ‘ instance always requires one decay card. --- ## 5. Special DSL Rules (Error Prone) - Track/photon selection & PID: Functions starting with n (e.g., npip) take a logical expression as a parameter (e.g., ">=2"). - Particle Name Convention Outside Decay Cards: Decay cards use standard EvtGen names (e.g., e+), but Ruby variable names cannot contain special characters like + or -. Therefore , use the mapped symbols below for particle names referenced outside the decay card (e.g., in selection code): 16 | EvtGen Name |Ruby DSL Symbol| |----------------|------------| | e+ | :ep | | em | :em | | mu+ | :mup | | mu - | :mum | | pi+ | :pip | | pi - | :pim | | K+ | :kp | | K- | :km | | p+ | :prp | | anti -p- | :prm | | Lambda0 | :Lambda | | anti -Lambda0 | :Lambda_bar| | K_S0 | :K_S0 | | K_L0 | :K_L0 | | gamma | :gamma | | pi0 | :pi0 | | eta | :eta | | anti -n- | :n_bar | | eta ’ | :etap | | K*0 | :k_star | | K*+ | :k_starp | - For particles not listed , infer a legal Ruby symbol (e.g., replace special characters with underscores or descriptive names). --- ## 6. Particle List and Candidate Tracking During execution of the DSL , each particle type has a corresponding list that stores the indices of reconstructed candidates. If you reference a particle whose list has not yet been created , an error will occur. The following methods create or modify these lists. You must ensure that operations on a particle type only happen after its list has been properly initialized. ### List Creation and Modification Methods - Calling ‘select_track ()‘ method: creating charged track lists , including positively charged tracks (named ‘iChrgp ‘) and negatively charged tracks (named ‘iChrgn ‘). The indices of selected tracks are stored in these lists. - Calling ‘select_photon ()‘ method: Creating a photon list containing all good photons in the event. Indices are stored in a list typically named ‘nGood ‘. - Calling ‘pid()/identify ()‘ method: Creating typed track lists for specific particle hypotheses. There are three possible track types at BESIII experiment that can be distinguished using ‘ identify () ‘: pion (‘:pip ‘, ‘:pim ‘), kaon (‘:kp‘, ‘:km ‘), proton (‘:prp ‘, ‘:prm ‘). Example" ‘identify :pip "from_kaon"‘ creates a list named ‘ index_pip ‘ storing indices of tracks identified as ‘:pip ‘. - Calling ‘pid(has_lepton = true)‘ method: Creating a list of leptons (electrons and muons) in the event. ** electron and muon cannot be distinguished using ‘identify () ‘**. Instead , you can simply use ‘pid(has_lepton = true)‘ to automatically identify leptons. You can also use ‘pid(has_lepton = true)/identify ()‘ to identify leptons along with pion , kaon , and proton at the same time. - Calling ‘assign ()‘ method: Changing the type of a track list by copying indices from one list to another. 17 Example: ‘assign (: chrgp => :pip , :chrgn => :pim)‘ copies indices from ‘iChrgp ‘ to ‘index_pip ‘ and from ‘iChrgn ‘ to ‘index_pim ‘. If the target lists do not exist , they are created; if they already exist , duplicates are ignored. - Calling ‘remove ()‘ method: Opposite of assign (). It removes particles from the list. Example , ‘remove ([: prp <= :chrgp ,:prm <= :chrgn])‘ removes proton indices from ‘iChrgp ‘ and anti -proton indices from ‘iChrgn ‘. - Calling ‘remove_used_particle_from_candidate_list ()‘ method: Used only inside a ‘secondary_vertex_fit ‘ block. It removes indices of particles that have been used in the fit from their respective typed lists , ensuring they are not reused - Intermediate particle reconstruction methods: Methods such as ‘ build_virtual_particle ()‘ and ‘kalman_kinematic_fit ‘ (with mass constraint) create new lists for the reconstructed intermediate particles (e.g., pi0 , eta). These lists are populated with the indices of successfully reconstructed candidates. ### Important Note - The special lists that combines electron and muon in total are ‘ index_lp ‘ and ‘index_lm ‘, which can be created **only** by calling ‘pid(has_lepton = true)‘. - Always track which particle lists are available at each stage of your translation. If a step in the paper requires using a particle whose list has not yet been created (e.g., because the reconstruction of that particle occurs later), you must either restructure the order (if allowed) or skip that step as per the translation rules. The DSL follows a logical flow: first select tracks/photons , then perform particle identification , then build intermediate particles , and finally apply kinematic fits. --- ## 7. Output Format - Provide only the DSL code translation in a ** single ** Ruby code block. - Do **not** include any explanatory text outside the code block. --- ## 8. Validation Checks (Before Output) - No post -kinematic fit cuts are included. - Physics meaning is maintained for expressed steps. - No DSL extensions are proposed or implemented. - Skipped steps are omitted entirely (no comments). - Only existing DSL patterns are used. - Particle names outside decay cards follow the convention above. - Particle list dependencies are respected (i.e., no use of a particle before its list is created). --- # DSL Code Structure Example Below is the comprehensive DSL example: example # DSL Manual This is the manual of the DSL in YARD format , please read the event selection part carefully , learn the DSL grammar , and handle its usage before generating the DSL code. Content of the DSL manual: DSL_manual 18 # Paper to be Translated Now , read the following paper content and generate the corresponding DSL code. When you ’re uncertain , refer to the DSL manual and the DSL example. Content of the paper: paper_content 19