This is a practical, opinionated guide for sanity-checking the writing quality, structure, and presentation of papers—especially for conference and journal submissions. While some items are subjective, the goal is to provide concrete reminders and highlight common pitfalls. It is a living document and will continue to be updated based on feedback.

1. Title
   • 1.1 Title is ≤ 15 words. Avoid generic phrasing (e.g., “A Novel Framework...,” which conveys little information) and overly narrow focus (which may reduce the paper’s audience)—aim for concise but informative and descriptive.
   • 1.2 Title clearly reflects both the problem (or context) and the solution, and includes at least one technical keyword (e.g., jailbreak, OOD detection, graph learning).
   • 1.3 Title generally avoids abbreviations.
2. Abstract
   • 2.1 Abstract includes at the following key components:
     • Problem/task definition: Clarify the need for the research
     • Proposed method or idea: Outline the methods or strategies used.
     • Data: Describe the nature of the data used for validating the proposed strategies.
     • Main results: Summarize the main findings
     • Broader implications/significance: Explain how these findings impact the field.
   • 2.2 Abstract avoids undefined abbreviations and vague descriptors (e.g., “important,” “novel,” “state-of-the-art” without context).
   • 2.3 Bonus: Abstract includes at least one concrete, quantitative result or insight to make the work stand out. For instance, “the model achieves up to 93.5% enhancement in the system’s reliability and also decreases the feeder’s peak demand by about 17% for a one-year planning horizon”.
3. Introduction
   • 3.1 The main problem or task is clearly defined within the first two paragraphs.
   • 3.2 Motivation includes either (a) real-world use cases or (b) citations to prior work—ideally both.
   • 3.3 The introduction ends with a brief overview of the proposed method and its name.
   • 3.4 Contributions are explicitly itemized (e.g., “(1) first framework for ..., (2) new dataset for ..., (3) extensive evaluation on ...”). Check out this post for tips to clearly communicate the novelty of your work.
   • 3.5 Each contribution is specific and verifiable—avoid vague claims such as “we provide insights” or “we improve understanding.”
   • 3.6 Bonus: Include a compelling figure on the first page—e.g., comparison to prior work, performance highlight, or visual explanation of the core idea.
   • 3.7 Check out this post for more guidelines on writing this section.
4. Related Work
   • 4.1 All cited works are connected to your method, baseline, or task.
   • 4.2 At least one baseline from the top-3 most cited recent papers on the topic is mentioned.
   • 4.3 Related work should not be less than 15 references, and should not exceed 1.5 pages (unless review or survey-style paper).
   • 4.4 You may use LLMs (like ChatGPT) for searching the related work, but double triple check each of the paper -- do not trust LLMs!!!!
   • 4.5 Bonus: Use related work section to introduce baseline algorithms -- show a table for your proposal better than the existing ones.
   • 4.6 Check out this post for more guidelines on writing this section.
5. Method
   • 5.1 All symbols are defined before use.
   • 5.2 Each equation is referenced with inline explanation (e.g., “Eq. (3) defines the loss over…”). If an equation is never referenced, consider making it inline to save space.
   • 5.3 All modules or components of the method are illustrated or described in text or figures.
   • 5.4 Each subsection ideally aligns with parts of the overview figure. Add a short summary paragraph before diving into subsections.
   • 5.5 If it will improve the readability and comprehension of the paper, include an overview figure and pseudo code in the main text.
   • 5.6 The method is reproducible without referring to the appendix or external code—reviewers and readers should understand everything from the main text.
   • 5.7 Bonus: Can anything be removed from this section without reducing clarity? Do not hesitate to cut: more math ≠ better paper.
6. Experimentation/Validation
   • 6.1 At least 3 baseline methods are compared. Are they state-of-the-art? Justify why these baselines are chosen.
   • 6.2 Standard deviation or confidence intervals are reported where appropriate.
   • 6.3 Hardware environment, software libraries, and hyperparameter settings are described.
   • 6.4 Negative results (if any) are explained, not omitted—failure cases are valuable.
   • 6.5 Evaluation metrics are clearly defined and justified.
   • 6.6 All figures and tables are referenced in the main text.
   • 6.7 Beyond showing numbers and saying “we perform well,” at least one deeper insight or analysis is provided (e.g., why it works, where it fails).
   • 6.8 Bonus: Think about how easy others can reproduce your work. If you have any "dirty tricks" -- remove them please.
7. Figures and Tables
   • 7.1 Each figure/table has a caption ≥ 2 lines that includes interpretation or context. Do not just place it without explanation—reviewers will get lost.
   • 7.2 Font size in all figures is ≥ 8pt and all labels are fully visible (not cropped).
   • 7.3 Plots use colors that remain distinguishable when printed in grayscale—some reviewers will print your paper.
   • 7.4 Each method mentioned in the results appears in either the legend or table column headers.
   • 7.5 Figures appear at the top of pages rather than mid-text or at the bottom (soft rule, but improves readability).
   • 7.6 Figures and tables are not redundant—each provides new or complementary information.
   • 7.7 It is better to create figures to be compatible in both color print and colorless print. For example, in the same figure, you may use two different colors to represent two different curves or represent two different bars/columns. However, it may lead to a problem when it is print colorlessly. Some solutions are available to address this issue, for example, add different markers for different curves.
   • Bonus: All figures are in lossless formats (e.g., PDF for vector graphics). Absolutely no low-resolution images allowed.
8. Structure and Formatting
   • 8.1 All LaTeX warnings and bad boxes have been resolved.
   • 8.2 Section headers follow the standard paper structure (e.g., Introduction, Method, Validation, etc.).
   • 8.3 All appendix sections are explicitly referenced in the main text (e.g., “Appendix B.2 shows…”).
   • 8.4 No orphan lines anywhere in the paper—avoid single-line section headers or short lines at the top/bottom of columns.
   • 8.5 No two figures or tables are placed consecutively without explanatory text between them.
9. References
   • 9.1 All references are in the correct format for the target venue.
   • 9.2 All datasets, toolkits, and models used are cited.
   • 9.3 At least one paper from the target venue (conference/journal) is cited.
   • 9.4 Self-citations ≤ 20% of total citations.
   • 9.5 BibTeX file has been deduplicated and spell-checked.
10. Citation Sanity Check (LLM-Generated Risk)
    • 10.1 All citations were manually verified to exist—title, authors, venue, and year match a real, published paper.
    • 10.2 No hallucinated references from LLM tools are included.
    • 10.3 If a citation was generated by ChatGPT, Copilot, or similar, be sure to cross-check on Google Scholar, Semantic Scholar, or other publisher sites.
11. Sanity Checks Before Submission
    • 11.1 PDF compiles in Overleaf/TeX with no errors or bad boxes.
    • 11.2 File name follows the submission guideline format (e.g., no underscores or author names if anonymized).
    • 11.3 No author-identifying information exists in metadata, supplementary files, or file names. Check your code repository and images too.
    • 11.4 The paper length complies with the page limit, including references and appendices (if counted).
    • 11.5 The paper has been read start-to-finish by someone not on the author list, without them needing to stop for clarification.
    • 11.6 All co-authors are listed and properly acknowledged—this is surprisingly often overlooked.
    • 11.7 Bonus: After submission, log in from a different device and OS (e.g., Mac, Windows) to verify that the uploaded version renders correctly.
12. General Tips
    • Put Yourself in the Position of the Reader. Convince yourself that you will actually read your own paper. If you don't like your paper, no one else will (especially a reviewer).
    • Write to Tell a Consistent Story. Do not write to fill up space, be coherent throughout (this is what people have done, this is what is missing, this is what we are doing, this is how we did it, these are the findings).
    • Title, Abstract, and Figures Sell the Paper. People do not have time to read papers, they will pick based on title, abstract , and by quick parsing.
    • All Contents Must Have a Purpose. If a graph or equation is not used or referred to, eliminate it.
    • Avoid Annoying Reviewers. Reviewers have an adversarial mindset (they are asked to find errors). Typos, inconsistencies, poor explanations, improper citations will get your paper rejected.
    • Bad Grammar is Bad Taste. Typos and incoherent sentences send a bad message about yourself.
    • Minimize Number of Acronyms and Jargon. The brain can only keep track of a handful of acronyms. Even if the reader knows about the topic, too much jargon makes things unintelligible.
    • Justify Assumptions and Main Results. If you write a theorem or graph explain why this is there. A collection of theorems and graphs do not tell a story.
    • Reputation is Everything. Papers and software are your ultimate products as a researcher (this is how you are measured). ****A bad paper of yours flying around google damages reputation.
    • Be Honest. It is common for writers to massage the text/results to "hide" details from the reader with the hope that a detail will go unnoticed. Someone will eventually find the flaw so don't do it.