Call for Submissions

We invite submissions of papers in two categories:

• Full research papers (up to 10+2 pages): Full research 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 research (up to 5+2 pages): Short research papers are opportunities for research-oriented position papers or new idea papers worth discussing with the community, but perhaps not yet fully evaluated. 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 2 pages for references.

Each paper submission will undergo a double-anonymous review process with three independent reviews and a virtual PC discussion. Acceptance criteria include relevance to the CAIN scope, novelty, 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’27 to present the paper in person.

Full paper submissions that do not meet the program committee’s expectations may be reevaluated and accepted as short papers. If accepted as a short paper, authors can choose to accept or decline to publish as a short paper. Rejected papers may also be invited to the poster track.

Scope and Topics of Interest

The scope of CAIN is Software Engineering for AI-Enabled Systems, or AI Engineering for short, that is, the use and innovation of software engineering principles and techniques to build software systems that use one or more AI/ML models. CAIN papers often apply, expand, adapt, or invent software engineering principles to the engineering of AI-enabled systems. See the dedicated scope page for more details.

Relevant topics therefore include, but are not limited to:

• Engineering principles, architecture, and quality assurance for agentic software, especially beyond coding agents
• Requirements engineering for AI-enabled systems, e.g., elicitation, specification, or management, and the relationship of system, user, and model requirements.
• System-level security and safety engineering strategies for systems with AI components.
• 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.
• Quality assurance and management of system quality attributes and their relationships 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.

The first three topics of agentic software, requirements engineering, and security/safety are a particular focus of interest for CAIN 2027.

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

All 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 2 additional page of references for short papers.
• Submissions must be unpublished original work and must not be under review or submitted elsewhere while being under consideration. Contravention of this concurrent submission policy will be deemed a serious breach of scientific ethics, and appropriate action will be taken in all such cases.
• 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. This includes for example, the guidelines on using the Use of Artificial Intelligence.
• 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 (do not omit or anonymize the references themselves).
  • 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.

All submissions must conform to the IEEE conference proceedings template, specified in the IEEE Conference Proceedings Formatting Guidelines (title in 24pt font and full text in 10pt type, LaTeX users must use \documentclass[10pt,conference]{IEEEtran} without including the compsoc or compsocconf options). Note that the IEEE format is being used this year, whereas last year it was the ACM format.

Accepted papers will be published in the ICSE 2027 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 presentation may be in the format of a talk or a poster.

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 2027. 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, the authors may accept or decline 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).

Withdrawing a Paper

Authors can withdraw their paper at any moment until the final decision has been made, through the paper submission system. Resubmitting the paper to another venue before the final decision has been made without withdrawing from CAIN 2027 first is considered a violation of the concurrent submission policy, and will lead to automatic rejection from CAIN 2027 as well as any other venue adhering to this policy. Such violations may also be reported to appropriate organizations e.g. ACM and IEEE.

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. Look for reasons to accept a paper rather than primarily for reasons to reject. 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.

• Responsible/no AI use: Again, we invited you as a PC member because of your expertise and expect you to take full responsibility for your reviews. Delegating reviews to AI is unprofessional and not allowed. Uploading papers under review to a public generative AI platform that may train on the paper content is strictly forbidden, as this would be considered as a violation of confidentiality of the process. However, responsible use of private AI (or AI services with privacy guarantees), for example to help format the review or help explore specific questions about the paper or related work is acceptable – for example, see Murphy-Hill and Bird’s post on this. AI use must be disclosed in the review form. We will hold reviewers accountable for AI slop and hallucinations. Ultimately, we insist that the reviews must be your professional judgment.

• 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: Almost every paper has some flaws, even award winning accepted ones. Try to review papers with a positive attitude and give papers a fair chance. Balance positives with negatives and deliberate about what problems are acceptable or can be easily fixed (e.g., presentation weaknesses, limited generalization, missing related work) and what problems are so serious that the paper should not be published in its current form (e.g., unsound claims, methodological flaws, missing novelty over prior paper). There is no limit on the number of papers that can be accepted to CAIN and no need to rank papers relative to other papers. CAIN is a community event and strives to include all papers that make sound contributions valuable to the community.

• 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: If you have expertise on the topic, try to take a clear stance for or against the paper. Expertise could be on the topic (e.g., ML monitoring) or the research method (e.g., qualitative analysis of interview data) or both. You are on the PC because others want to know your expert judgment. “Weak accept” and “weak reject” are more commonly used for reviews with less confidence, often outside your area of expertise. Junior PC members may be experts on fewer papers, but they should still leverage their expertise where they are experts.

• 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.

• Engage in discussions: Discuss with other reviewers about the strength and the weaknesses of the paper. Read the other reviews and respond where you agree or disagree with their key points, as questions where answers might help move the discussion forward (by better understanding disagreements or reaching consensus). Engage with the other reviewers’ arguments rather than just restating your own. Try to respond quickly (same day or next day) and constructively.

• Argue your position but be open to changing your mind: You are on the PC because you have expertise. You have expertise and may see strengths and weaknesses that others with different backgrounds may not recognize. Even if the paper is not in your area of expertise, your opinion of how well the paper explains its contributions to an outsider is still valuable. If you think a paper makes a strong contribution and should be accepted (maybe despite some weaknesses), fight for it. If you think a paper is fundamentally flawed and should not be published in its current form, argue your position. Do not simply follow the majority or defer to more senior PC members. At the same time, listen to other reviewers and read the authors’ response (if available). Be open to change your mind if you see other convincing arguments or find mistakes in yours. Maybe others see strengths that you did not appreciate.

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,” “unexpected,” or “important” 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. Papers should explain novelty with respect to the state of the art clearly. 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 to CAIN scope: 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. Authors are expected to explain relevance during submission and as part of the paper. Submissions out of scope may be desk rejected.

• 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.

• Presentation: The extent to which the paper’s writing is clear and efficiently understandable, with well-organized descriptions and explanations.

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 and I will argue to reject it
  • Weak reject (2): the paper has some major weaknesses but also some merit; but I am not confident enough to argue for rejection and may be convinced by others
  • Weak accept (3): the paper has merits, but I am not confident enough to argue for acceptance and may be convinced by others
  • Accept (4): the paper has considerable merit and only very few, mostly minor weaknesses; I am ready to champion this paper
  • Award-quality paper (5): this is an award-quality paper with considerable potential to advance the field; it should definitely be accepted
• Expertise (not confidence):
  • X. I am an expert on this topic or research method (know the related work well)
  • Y. I am knowledgeable on this topic or research method.
  • Z. I am an informed outsider.

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

• Summary of strengths: 2-4 short bullet points of the paper’s main strengths (which are explained in more details in the comments section below)

• Summary of weaknesses: 2-4 short bullet points of the paper’s main weaknesses (which are explained in more details in the comments section below)

• Detailed comments: explain and justify your verdict and the provided strengths and weaknesses; 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. Ensure that your summary bullet points are a reflection of these comments.