USENIX ATC '24 Call for Artifacts


A scientific paper consists of a constellation of artifacts that extend beyond the document itself: software, hardware, evaluation data and documentation, raw survey results, mechanized proofs, models, test suites, benchmarks, and so on. In some cases, the quality of these artifacts is as important as that of the document itself. Last year, 63% of accepted USENIX ATC papers participated in the artifact evaluation process. Based on last year's success, USENIX ATC '24 will continue to run an optional artifact evaluation process combined with OSDI '24.

The artifact evaluation process will consider the availability and functionality of artifacts associated with their corresponding papers, along with the reproducibility of the paper's key results and claims with these artifacts. Artifact evaluation is single-blind. Artifacts will be held in confidence by the evaluation committee.

See the Submitting an Artifact section for details on the submission process.

Questions about the process can be directed to

Important Dates

  • Notification for paper authors: Tuesday, April 30, 2024
  • Artifact submission deadline: Sunday, May 12, 2024, AoE
  • Kick-the-tires response period: Wednesday, May 15–Wednesday, May 22, 2024
  • Artifact decisions announced: Friday, May 31, 2024
  • USENIX ATC final papers deadline: Thursday, June 6, 2024

Note: For an artifact to be considered, at least one contact author for the submission must be reachable via email and respond to questions in a timely manner during the kick-the-tires period.

Artifact Evaluation Committee Co-Chairs

Jianyu Jiang, Huawei Technologies Co.
Ji Qi, Institute of Software, Chinese Academy of Sciences
Cesar A. Stuardo, ByteDance

Artifact Evaluation Committee

Tejaswi Agarwal, Uber Technologies, Inc.
André Augusto, INESC-ID and Instituto Superior Técnico, University of Lisbon
Ayush Bhardwaj, Akamai Technologies
Shreesha Gopalakrishna Bhat, University of Illinois at Urbana–Champaign
Rahul Bothra, University of Illinois at Urbana–Champaign
Ramya Bygari, University of Illinois at Urbana–Champaign
Hongzheng Chen, Cornell University
Junda Chen, University of California, San Diego
Zelei Cheng, Northwestern University
Georgia Christofidi, IMDEA Software Institute
Weihao Cui, Shanghai Jiao Tong University
Federico De Marchi, Max Planck Institute for Informatics
Xianzhong Ding, Lawrence Berkeley National Laboratory
Huibing Dong, University of Minnesota
Jiangfei Duan, The Chinese University of Hong Kong (CUHK)
Aoyang Fang, The Chinese University of Hong Kong, Shenzhen (CUHK-Shenzhen)
Dhruv Garg, Georgia Institute of Technology
Jinnan Guo, Imperial College London
Ziyi Guo, Northwestern University
Muhammad Haseeb, New York University
Jiatai He, Institute of Software, Chinese Academy of Sciences
Kiran Shashi Hombal, University of Illinois at Urbana–Champaign
Guanzhou Hu, University of Wisconsin—Madison
Jiyu Hu, University of Illinois at Urbana–Champaign
Jinghan Huang, University of Illinois at Urbana–Champaign
Yibo Huang, The University of Texas at Austin
Yu Huang, Seagate Technology
Peter Ince, Monash University
Abdullah Al Raqibul Islam, University of North Carolina at Charlotte
Dae R. Jeong, Korea Advanced Institute of Science and Technology (KAIST)
Houxiang Ji, University of Illinois at Urbana–Champaign
Chenhao Jiang, University of Toronto, Vector Institute
Zhihan Jiang, The Chinese University of Hong Kong (CUHK)
Zu-Ming Jiang, ETH Zurich
Saisha Kamat, University of North Carolina at Charlotte
Fadhil Kurnia, University of Massachusetts Amherst
Suyeon Lee, Georgia Institute of Technology
Yiming Lei, Max Planck Institute for Informatics
Mingyu Li, Institute of Software, Chinese Academy of Sciences
Ruidan Li, University of Chicago
Xiang Li, Purdue University
Xupeng Li, Columbia University
Zhouyu Li, North Carolina State University
Han-Ting Liang, University of Illinois at Urbana–Champaign
Changyuan Lin, University of British Columbia
Juyi Lin, King Abdullah University of Science and Technology (KAUST)
Chang Liu, Institute of Software, Chinese Academy of Sciences
Jing Liu, University of California, Irvine
Shi Liu, University of California, Los Angeles
Zeyan Liu, University of Kansas
Moritz Lumme, Dresden University of Technology
Haoran Ma, University of California, Los Angeles
Seonjin Na, Georgia Institute of Technology
João Oliveira, INESC-ID and Instituto Superior Técnico, University of Lisbon
Matteo Olivi, Georgia Institute of Technology
Qinglin Pan, Institute of Software, Chinese Academy of Sciences
Ziyue Pan, Zhejiang University
Santosh Pandey, Rutgers University
Yihan Pang, University of Illinois at Urbana–Champaign
Konstantinos Papaioannou, IMDEA Software Institute
Michael Paper, Imperial College London
Sibendu Paul, Amazon
Pedro Henrique Penna, Microsoft Research
Sandeep Polisetty, University of Massachusetts Amherst
Stratos Psomadakis, National Technical University of Athens
Shangshu Qian, Purdue University
Feiran (Alex) Qin, North Carolina State University
Yuxin Qiu, University of California, Riverside
Boris Radovic, King Abdullah University of Science and Technology (KAUST)
Abu Bakar Siddiqur Rahman, University of Nebraska Omaha
Murali Ramanujam, Princeton University
Vishal Rao, Georgia Institute of Technology
Rajarshi Saha, Stanford University
Amit Samanta, University of Utah
Anirudh Sarma, Georgia Institute of Technology
Sagar Bharadwaj Kalasibail Seetharam, Carnegie Mellon University
Dongjoo Seo, University of California, Irvine
Aditya Shah, Google
Ted Shaowang, University of Chicago
Tanvi Sharma, Purdue University
Hamza Sheikh, University of Utah
Xiaoxiang Shi, Shanghai Jiao Tong University
Vladyslav Shumanskyy, King Abdullah University of Science and Technology (KAUST)
Salvatore Signorello, Telefonica Research
Sudheesh Singanamalla, Netflix
Ray Sinurat, University of Chicago
Qiang Su, The Chinese University of Hong Kong (CUHK)
Ammar Tahir, University of Illinois at Urbana–Champaign
Xin Tan, The Chinese University of Hong Kong (CUHK)
Syed Salauddin Mohammad Tariq, University of Michigan-Dearborn
Boyuan Tian, University of Illinois at Urbana–Champaign
Diman Zad Tootaghaj, Hewlett Packard Enterprise Labs
Sahil Tyagi, Indiana University Bloomington
Diogo Vaz, INESC-ID and Instituto Superior Técnico, University of Lisbon
Jiankun Wang, University of Illinois at Urbana–Champaign
Wenlong Wang, University of Minnesota
Yichuan Wang, Shanghai Jiao Tong University
Gao Wei, Nanyang Technological University
Yihua Wei, The University of Iowa
Shaojie Xiang, Cornell University
Haocheng Xu, University of California, Irvine
Sujay Yadalam, University of Wisconsin—Madison
Mengwei Yang, University of California, Irvine
Mingxuan Yang, Imperial College London
Yingao Elaine Yao, University of British Columbia
Chenhao Ye, University of Wisconsin—Madison
Jinsun Yoo, Georgia Institute of Technology
Boxi Yu, The Chinese University of Hong Kong, Shenzhen (CUHK-Shenzhen)
Shan Yu, University of California, Los Angeles
Zheng Yu, Northwestern University
Wahid Uz Zaman, The Pennsylvania State University
Jian Zhang, Rutgers University
Jingyao Zhang, University of California, Riverside
Shunkang Zhang, The Hong Kong University of Science and Technology
Wenhui Zhang, ByteDance
Xiangqun Zhang, Syracuse University
Yazhuo Zhang, Emory University
Ruilin Zhao, Institute of Software, Chinese Academy of Sciences
Xinying Zheng, University of Illinois at Urbana–Champaign
Shawn Zhong, University of Wisconsin—Madison
Tianle Zhong, University of Virginia
Yinmin Zhong, Peking University
Yangjie Zhou, Tencent
Henry Zhu, University of Illinois at Urbana–Champaign
Weidong Zhu, University of Florida
Zeying Zhu, University of Maryland, College Park
Yonghao Zhuang, Carnegie Mellon University

Benefits and Goals

The dissemination of artifacts benefits our science and engineering as a whole. Their availability encourages replicability and reproducibility and enables authors to build on top of each others' work. It can also help more unambiguously resolve questions about cases not considered by the original authors. It also confers direct and indirect benefits to the authors themselves.

The goal of artifact evaluation is to incentivize authors to invest in their broader scientific community by producing artifacts that illustrate their claims, enable others to validate those claims, and accelerate future scientific progress by providing a platform for others to start from. A paper with artifacts that have passed the artifact evaluation process is recognized in two ways: first by badges that appear on the paper's first page, and second by an appendix that details the artifacts.

Eventually, the assessment of a paper's accompanying artifacts may guide the decision-making about papers: that is, the Artifact Evaluation Committee (AEC) would inform and advise the Program Committee (PC). For now, artifact evaluation will begin only after paper acceptance decisions have already been made. Artifact evaluation is optional, although we hope all papers will participate.


Each paper sets up certain expectations and claims of its artifacts based on its content. The AEC will read the paper and then judge whether the artifacts match those criteria. Thus, the AEC's decision will be that the artifacts do or do not "conform to the expectations set by the paper." Ultimately, the AEC expects that high-quality artifacts will be:

  • consistent with the paper
  • as complete as possible
  • documented well
  • easy to reuse, facilitating further research


The AE process at USENIX ATC '24 is a continuation of the AE process at USENIX ATC '23 and was inspired by multiple other conferences, such as USENIX Security, SOSP, and several SIGPLAN conferences. See for the origins of the AE process, and for the previous AE processes held in systems.


Authors will be invited to submit their artifacts after their papers have been (conditionally) accepted for publication at USENIX ATC '24. See the artifact submission instructions and the guidelines for packaging artifacts later in this document for more instructions.

At artifact-submission time, a submitter will choose the criteria by which their artifacts will be evaluated. The criteria correspond to three separate badges that can be awarded to a paper. An artifact can meet the criteria of one, two, or all three of the following badges:

  • Artifacts Available: To earn this badge, the AEC must judge that the artifacts associated with the paper have been made available for retrieval, permanently and publicly. We encourage authors to use Zenodo, which is a publicly-funded long-term storage platform that also assigns a DOI for your artifact. Other valid hosting options include institutional repositories and third-party digital repositories (e.g., FigShare, Dryad, Software Heritage, GitHub, or GitLab—not personal webpages. Other than making the artifacts available, this badge does not mandate any further requirements on functionality, correctness, or documentation.
  • Artifacts Functional: To earn this badge, the AEC must judge that the artifacts conform to the expectations set by the paper in terms of functionality, usability, and relevance. In short, do the artifacts work and are they useful for producing outcomes associated with the paper? The AEC will consider three aspects of the artifacts in particular:
    1. Documentation: are the artifacts sufficiently documented to enable them to be exercised by readers of the paper?
    2. Completeness: do the submitted artifacts include all of the key components described in the paper?
    3. Exercisability: do the submitted artifacts include the scripts and data needed to run the experiments described in the paper, and can the software be successfully executed?
  • Results Reproduced: To earn this badge, the AEC must judge that they can use the submitted artifacts to obtain the main results presented in the paper. In short, is it possible for the AEC to independently repeat the experiments and obtain results that support the claims made by the paper? The goal of this effort is not to reproduce the results exactly, but instead to generate results independently within an allowed tolerance such that the main claims of the paper are validated.

After the artifact submission deadline, members of the AEC will download each artifact package, read the accepted paper, install the artifacts (where relevant), and finally evaluate the artifacts. AEC members may communicate with artifact authors—through HotCRP to maintain the evaluators' anonymity—to resolve minor issues and ask clarifying questions. Authors must respond to messages from the AEC in a timely manner for their artifacts to be effectively considered.

The AEC will complete its evaluation and notify authors of the outcomes. Authors can use the time between notification and the final paper deadline to incorporate feedback and artifact details into the final versions of their papers. This is intended to allow authors to include the feedback from the AEC, at their option.

When the AEC judges that an artifact meets the criteria for one or more of the badges listed above, those badges will appear on the final version of the associated paper. In addition, the authors of the paper will be encouraged to add an Artifact Appendix of up to two pages to their publication. The goal of the appendix is to describe and document the artifact in a standard format. The template for the appendix is available here.

Artifact Details

The AEC will try to accept any kind of digital artifact that authors wish to submit: software, data sets, survey results, test suites, mechanized proofs, etc. Paper proofs will not be accepted because the AEC lacks the time and often the expertise to carefully review paper proofs. Physical objects, e.g., computer hardware, cannot be accepted due to the difficulty of making the objects available to members of the AEC. If your artifact requires special hardware, consider if/how you can make it available to evaluators online.

The submission of an artifact does not give the AEC permission to make its content public. AEC members may not publicize any part of your artifact during or after completing evaluation, nor may they retain any part of it after evaluation. Thus, you are free to include models, data files, proprietary binaries, etc., in your artifact. Participating in artifact evaluation does not require you to later publish your artifacts (although it is encouraged).

Some artifacts may attempt to perform malicious or destructive operations by design. These cases should be boldly and explicitly flagged in detail in the README so the AEC can take appropriate precautions before installing and running these artifacts. Please contact if you believe that your artifacts fall into this category.

Review and Anonymity

Artifact evaluation is single blind. The identities of artifact authors will be known to members of the AEC, but authors will not know which members of the AEC have reviewed their artifacts.

To maintain the anonymity of artifact evaluators, the authors of artifacts should not embed any analytics or other tracking in the websites for their artifacts for the duration of the artifact-evaluation period. If you cannot control this, do not access this data. This is important to maintain the confidentiality of the evaluators. In cases where tracing is unavoidable, authors should notify the AEC chairs in advance so that AEC members can take adequate safeguards.

Submitting an Artifact

Artifact Submission

No registration is required for submitting artifact in ATC '24 artifact evaluation. You only need to submit the abstract and PDF of your accepted USENIX ATC '24 paper, as well as topics, conflicts, a stable URL of your artifacts (or an archive of your artifacts if a URL is not possible), and any "Comments for AEC" (e.g., special hardware requirement) for potential evaluators via the artifact submission site, by the artifact submission deadline. If your artifact is access-protected, provide the credentials needed to access it. Select the criteria/badges that the AEC should consider while evaluating your artifacts. You will not be able to change the URL, archive, or badge selections after the artifact submission deadline. Finally, for your artifact to be considered, check the "ready for review" box before the submission deadline.

The AEC recommends that you create a single web page at a stable URL that contains your artifact package. The AEC may contact you with questions about your artifacts if your submitted materials are unclear.

Review Process

The review process is structured in two phases:

  1. Kick-the-tires: During this phase, reviewers will check for any obvious problems that prevent the artifact from being fully reviewed. Such problems include invalid download links, broken virtual machine images, missing dependencies, or failures when applying the artifact to a "Hello world"-sized example. Authors can respond to issues and provide an updated version of their artifact during a kick-the-tires response period.
  2. Full evaluation: After the kick-the-tires phase, reviewers will fully evaluate the artifact.

Packaging Artifacts

The goal of the Artifact Evaluation Committee is to judge whether the artifacts that you submit conform to the expectations set by your paper in the context of the criteria associated with the badges you have selected. The effort that you put into packaging your artifacts has a direct impact on the committee's ability to make well-informed decisions. Please package your artifacts with care to make it as straightforward and easy as possible for the AEC to understand and evaluate their quality.

A complete artifact package must contain:

  • the accepted version of your USENIX ATC '24 paper
  • the artifact itself
  • README instructions

README instructions: Your artifact package must include an obvious "README" that describes your artifact and provides a road map for evaluation. The README must consist of two sections. A "Getting Started Instructions" section should help reviewers check the basic functionality of the artifact within a short time frame (e.g., within 30 minutes). Such instructions could, for example, be on how to build a system and apply it to a "Hello world"-sized example. The purpose of this section is to allow reviewers to detect obvious problems during the kick-the-tires phase (e.g., a broken virtual machine image). A "Detailed Instructions" section should provide suitable instructions and documentation to fully evaluate the artifact.

Artifact claims: Importantly, make your claims about your artifacts concrete. This is especially important if you think that these claims differ from the expectations set up by your paper. The AEC is still going to evaluate your artifacts relative to your paper, but your explanation can help to set expectations up front, especially in cases that might frustrate the evaluators without prior notice. For example, tell the AEC about difficulties they might encounter in using the artifact, or its maturity relative to the content of the paper.

Artifact format: Authors should consider one of the following methods to package the software components of their artifacts (although the AEC is open to other reasonable formats as well):

  • Source code: If your artifact has few dependencies and can be installed easily on several operating systems, you may submit source code and build scripts. However, if your artifact has a long list of dependencies, please use one of the other formats below.
  • Virtual machine/container: A virtual machine or Docker image containing the software application already set up with the right toolchain and intended runtime environment. For example:
    • For raw data, the VM would contain the data and the scripts used to analyze it.
    • For a mobile phone application, the VM would have a phone emulator installed.
    • For mechanized proofs, the VM would contain the right version of the relevant theorem prover. We recommend using a format that is easy for AEC members to work with, such as OVF or Docker images. An AWS EC2 instance is also possible.
  • Binary installer: Indicate exactly which platform and other run-time dependencies your artifact requires.
  • Live instance on the web: Ensure that it is available for the duration of the artifact evaluation process.
  • Internet-accessible hardware: If your artifact requires special hardware (e.g., SGX or another trusted execution environment), or if your artifact is actually a piece of hardware, please make sure that AEC members can somehow access the device. VPN-based access to the device might be an option.
  • Screencast: A detailed screencast of the tool along with the results, especially if one of the following special cases applies:
    • The artifact needs proprietary/commercial software or proprietary data that is not easily available or cannot be distributed to the committee.
    • The artifact requires significant computation resources (e.g., more than 24 hours of execution time to produce the results) or requires huge data sets.
    • The artifact requires specific hardware or software that is not generally available in a typical lab and where no access can be provided in a reasonable way.

As previously described, in all cases, artifacts must be provided in a manner that is appropriate for single-blind review by members of the AEC (i.e., anonymous reviewers).

Further Advice

There are several sources of good advice about preparing artifacts for evaluation. These two are particularly noteworthy:

If you have any questions about how best to package your artifact, contact