Call for Submissions

We invite submissions of papers in two categories:

• Full research papers (up to 10+2 pages): these papers describe empirical or theoretical research results, e.g., based on a controlled experiment, questionnaire survey, case study, or mathematical modeling, or introduce a novel design contribution, e.g., a conceptual framework or tool-supported approach. Design contributions presented in full research papers must be appropriately evaluated. Secondary studies, replication studies, and negative results are also welcome. A full research paper is up to 10 pages, plus a maximum of 2 pages for references.
• Short papers (up to 5+1 pages): these papers do not describe full empirical studies but should be seen as research-oriented position or new idea papers that are worth discussing with the community. For example, a short paper might identify and describe important challenges or present visionary new solution ideas (no evaluation required). Preliminary research results are also appropriate for a short paper. A short paper is up to 5 pages, plus a maximum of 1 page for references.

Each paper submission will undergo a double-anonymous review process with three independent reviews and a virtual PC discussion. Acceptance criteria include novelty, academic and industrial relevance for SE4AI, rigor, verifiability & transparency, and presentation. The accepted full and short papers will be published in the ICSE Companion proceedings, and at least one author needs to register for CAIN’26 to present the paper in person.

If a paper is rejected as a full paper because the reviewers consider that the research is in the early stages or lacking evaluation, the paper will be reevaluated as a short paper. If accepted as a short paper, authors can choose to accept or decline to resubmit as a short paper. Rejected papers may also be considered for the poster track – this will depend on the quantity of papers received and the agreement of the authors.

Scope and Topics of Interest

The area of interest for CAIN is Software Engineering for AI-Enabled Systems, i.e., systems that contain at least one AI component. An AI component is a software component that uses at least one AI technique to provide (parts of) its functionality, such as ML models, generative AI like large language models (LLMs), reinforcement learning, symbolic AI, AI planning, evolutionary algorithms, etc. CAIN focuses on a system and/or life cycle perspective. Relevant topics therefore include, but are not limited to:

• Requirements engineering for AI-enabled systems, e.g., elicitation, specification, or management, and the relationship of requirements to AI/ML model development.
• Data management for AI-enabled systems to ensure relevance and efficiency related to stakeholder goals.
• System and software architecture for AI-enabled systems, e.g., architecture modeling, architectural tactics, architecture/design patterns, or reference architectures.
• Integration of AI and software development activities into the AI engineering life cycle, e.g., continuous integration and deployment, operation and monitoring, and system and software evolution.
• Assurance and management of system quality attributes and their relationship to AI/ML properties, including runtime properties such as performance efficiency, safety, security, and reliability; and life cycle properties such as reusability, maintainability, evolvability, and observability.
• Collaboration, organizational, and management practices for the successful engineering of AI-enabled systems.
• Building effective infrastructures to support the development and operation of AI-enabled systems and components.
• Software engineering methods and tools for next-gen AI-enabled systems, e.g., systems that integrate foundation models or AI agents.

Note on Scope: Submissions that report predominantly on data science or AI/ML algorithms without any or only minor connection to software engineering for AI-enabled systems will be desk-rejected. There are many venues for data science and AI/ML papers, where authors would get much more valuable and relevant feedback. More details on the scope are available here.

Submission Form

Research papers should be submitted to HotCrp. The submission deadline is firm, no extensions.

All submissions must adhere to the following requirements:

• Page limit is 10 pages plus 2 additional pages of references for full papers and 5 pages plus 1 additional page of references for short papers.
• Submissions must be unpublished original work and should not be under review or submitted elsewhere while being under consideration.
• By submitting to CAIN, authors acknowledge that they are aware of and agree to be bound by the ACM Policy and Procedures on Plagiarism and IEEE Plagiarism FAQ. The authors also acknowledge that they conform to the authorship policy of the ACM and the authorship policy of the IEEE.
• Paper review will employ a double-anonymous review process. Thus, no submission may reveal its authors’ identities. The authors must make every effort to honor the double-anonymous review process. In particular:
  • Authors’ names must be omitted from the submitted paper.
  • All references to the authors’ prior work should be in the third person.
  • Linked artifact repositories need to be anonymized.
  • While we allow the posting of preprints on arXiv or similar sites, authors are encouraged to change the title of their submission to make the accidental discovery by reviewers less likely. During the review period, authors must not publicly use the submission title, e.g., by advertising the paper on social media.

Submissions must conform to the official ACM Primary Article Template, which can be obtained from the ACM Proceedings Template page. LaTeX users should use the sigconf option, as well as the review (to produce line numbers for easy reference by the reviewers) and anonymous (omitting author names) options. To that end, the following LaTeX code can be placed at the start of the LaTeX document: \documentclass[sigconf,review,anonymous]{acmart}

Accepted papers will be published in the ICSE 2026 Co-located Event Proceedings and included in the IEEE and ACM Digital Libraries. Authors of accepted papers are required to register and present their accepted paper at the conference for the paper to be included in the proceedings and the Digital Libraries.

The official publication date is the date the proceedings are made available in the ACM or IEEE Digital Libraries. This date may be up to two weeks prior to the first day of ICSE 2026. The official publication date affects the deadline for any patent filings related to published work. Purchase of additional pages in the proceedings is not allowed.

Authors of rejected full papers may receive an acceptance as a short paper if the PC chairs and reviewers agree that it better meets the criteria for short papers. In this case, authors may decide to accept or reject the invitation if they would rather submit as a full paper to a different venue.

Similarly, authors of rejected full and short papers relevant to the field of AI engineering may be invited to publish their papers in a different CAIN track, such as the Posters track. In this case, authors may decide to accept or reject the invitation.

Open Science Policy

CAIN encourages authors of research papers to follow the principles of transparency, reproducibility, and replicability. The guiding principle is that all major research results should be accessible to the public, and, if possible, empirical studies should be reproducible. In particular, the conference supports the adoption of open data and open-source principles and strongly encourages authors to disclose their (anonymized and curated) data and study artifacts. Note that sharing is expected to be the default, and non-sharing needs to be justified. We acknowledge that there are valid reasons why sharing is not possible, practical, or desirable, e.g., privacy restrictions or non-disclosure agreements. We also recognize that full reproducibility or replicability is usually not feasible in qualitative research and that, similar to industrial studies, qualitative studies often face challenges in sharing research data.

Note that artifact repositories also need to be anonymized for review. Final artifact repositories of accepted submissions should be submitted to an institutional or open platform committed to long-term archiving, which ideally also creates a DOI for the repository, e.g., Zenodo or Figshare. Source code contributions like reusable tools may also be suitably shared on, e.g., GitHub. In that case, we recommend using https://anonymous.4open.science for the anonymous initial submission and, on acceptance, archiving the respective version via Zenodo (see this guide).

Important: ACM Open Access and APCs

All ICSE 2026 papers, including those from co-located events, will be subject to ACM’s Article Processing Charges (APCs) under the open access model. Authors without an institutional agreement such as ACM Open will have to pay the APC when they submit the camera-ready version. This is $250 for ACM members and $350 for non-members, only one charge per paper, irrespective of the number of authors. Please note that short papers are still subject to APCs. Further information is available here.

DISCLAIMER: These review instructions are heavily inspired by similar instructions for conferences like ICSE, ICSA, and ECSA.

CAIN’s goal is to facilitate an inclusive and transparent review process. To this end, we outline the quality criteria for reviews in this document, which makes it important for both authors and reviewers.

1. What We Expect of CAIN Reviewers

In general, we encourage our reviewers to be open, positive, and professional. Beyond that, we have additional expectations for their work.

• Take responsibility: We invited you as a PC member because of your expertise. Therefore, we expect you to take full responsibility for your reviews. Reviewers may solicit help from others acting as sub-reviewers or use the reviews as an opportunity to train their PhD students. However, reviewers should rewrite the review in their own words and adjust the scores accordingly. The final opinions in a submitted review should be those of the PC member, not those of a sub-reviewer.

• Participate in the bidding: Reviewers should pay attention to the bidding process to select papers that are close to their area of expertise. This will make it easier to assign reviewers with sufficient expertise in the topic and used research methods.

• Ensure review quality: We ask PC members to submit thorough and balanced reviews that justify their verdict well. High-quality reviews do not have to be several pages long, but it’s unlikely that a few sentences will constitute a high-quality review.

• See the positive: Please also describe what you liked about a paper. Pointing out deficiencies is important, but mentioning the good parts will ensure a nuanced perspective on the paper. Additionally, remember that perfect papers do not exist. There is always something that can be improved. Your job is to identify the papers that are good enough to be published.

• Describe what is missing: Even if you think that a paper does not meet the standards required for acceptance, we encourage you to highlight what you think would be necessary to make it acceptable, while acknowledging that conference submissions are subject to page limits (authors cannot include everything).

• Take a stand: Reviewers should try to be decisive. Please argue for either acceptance or rejection (no borderline rating can be chosen). In both cases, we ask you to justify your verdict in your review comments. If the decision is less clear for you, you can use a “weak accept” or “weak reject”.

• Report ethical issues: PC members should inform the PC co-chairs immediately if they detect evidence related to plagiarism, concurrent submissions, unethical GenAI usage, exposure of private participant data, co-reviewers demanding unreasonable citations of their work, etc.

• Update reviews where reasonable: Reviews can be updated at any time, and we encourage reviewers to read the submitted reviews of others and to potentially make adjustments even before the discussion period. If the discussion led to a decision that is inconsistent with the initial reviews and their scores, we ask you to update both to reflect the consensus reached during the discussion. For example, a rejected paper should not have mostly accept scores.

2. Review Criteria

Reviewers will evaluate each submission according to several criteria (see below). We ask reviewers to explicitly use these criteria in the review, e.g., to structure the detailed comments or by providing a brief summary for each criterion at the end of the detailed comments.

• Novelty: The extent to which the paper is original and positioned regarding the state-of-the-art. Note that novelty is not about providing “surprising” or “unexpected” results or the complexity of a proposed solution. Instead, it is about how the work advances the existing body of knowledge. If insufficient empirical evidence exists for a phenomenon, then providing this evidence is novel, even if the results are not surprising. If a paper lacks important references to prior work, we ask reviewers to provide suggestions. Reviewers are only allowed to suggest their own papers if they are very relevant to the topic at hand. Additionally, reviewers must always provide balanced suggestions that include the work of others (unless no other papers exist). Lastly, we also encourage replications, i.e., papers that confirm previous findings, e.g., in slightly different contexts. These papers need to discuss their findings in comparison to previous works.

• Relevance: The extent to which the paper fits the scope outlined in the Call for Papers and to which the paper’s contributions are important for AI engineering research, practice, and education / training. All submissions will be checked by the PC co-chairs for their general fit to the conference. While clear cases will be desk-rejected, papers with less obvious scope mismatches will be forwarded to peer review. If a reviewer believes that a paper is not relevant for CAIN, we ask for clear explanations. Additionally, authors should explicitly discuss the implications of their results or contributions for AI engineering research and/or practice and provide an interpretation of the meaning of the findings, especially if the paper reports empirical work.

• Rigor: The extent to which the paper’s claims and contributions are supported by the rigorous application of appropriate research methods, e.g., within an empirical study. For a theoretical or design contribution, this refers to its soundness, clarity, and depth. For a design contribution, this additionally refers to the level of thoroughness and completeness of the evaluation. Design contributions presented in full research papers must be appropriately evaluated. However, a short paper presenting innovative solution ideas does not require an extensive evaluation but should instead provide sound arguments and convincing future plans for the evaluation.

• Verifiability & Transparency: The extent to which the paper provides methodological details to understand how the authors arrived at their conclusions and shares study data and artifacts that support the independent verification or replication of the paper’s claimed contributions. Note that we only expect the sharing of data and artifacts that are practical and reasonable to share to support replication and reproducibility. For example, sensitive participant information, full interview transcripts, or proprietary source code of companies are not expected to be shared. In general, we want authors submitting to CAIN to be supportive of open science principles and to look for opportunities to share artifacts rather than treating it as an afterthought.

• Presentation: The extent to which the paper’s writing is clear and efficiently understandable, with well-organized descriptions and explanations, an appropriate style of scientific writing, adequate use of the English language, sound usage of references to support claims or the introduction of concepts, absence of major ambiguities, clearly readable figures and tables, and adherence to the provided formatting instructions. Remember that not all authors are native English speakers. Therefore, presentation alone should rarely be grounds for arguing for rejection. However, a paper that is in such a bad state that understanding is severely hindered should probably not be accepted.

3. Review Form

Reviewers will use the following form to structure their reviews:

• Overall merit: please provide an overall verdict for the paper using one of the following scores:

  • Reject (1): the paper has too many major weaknesses to be publishable in its current form
  • Weak reject (2): the paper has some major weaknesses but also some merit; while I argue for rejection, I can also see a case for acceptance
  • Weak accept (3): the paper has decent merit; it has some weaknesses, but many of them are only minor; while I argue for acceptance, I can also see a case for rejection
  • Accept (4): the paper has considerable merit and only very few, mostly minor weaknesses; I am ready to champion this paper
  • Strong accept (5): this is an award-quality paper with considerable potential to advance the field; it should definitely be accepted

• Paper summary: please briefly summarize your understanding of the paper’s content, ideally at least partially in your own words (~4–8 sentences)

• Strengths: a bullet point list of the paper’s main strengths; please try to provide at least some points, even if you argue for rejection

• Weaknesses: a bullet point list of the paper’s main weaknesses; make sure that you explain each point in the detailed comments

• Detailed comments: explain and justify your verdict and the provided strengths and weaknesses in more detail; if you argue for rejection, make sure to provide at least some constructive criticism for the authors to improve their submission; additionally, please ensure that you make explicit use of the review criteria (see above), e.g., by structuring your review via these criteria or by having a summary of them at the end.