Citation Rules

1. To cite fellow students with whom you have worked, and whose contributions do not require a inline citation, use the following format:
   • [1] Worked With: Full Name 1, Full Name 2, etc.
   • This line should be the first line in your references list, and you can add names to it as needed.
   • It is sufficient to have a single line listing your general collaborators, even if you worked on different problems with different groups.
2. If a project is specifically structured as a group project, then members of the group do not need to be cited: they shall be considered authors and acknowledged where authorship is acknowledged (e.g., in the README.md or on the portfolio post).
3. The absence of a first reference stating who you worked with is a declaration that you did not work with anybody on the assignment.
4. If a student or group of students makes a contribution that requires an inline citation, those students should be listed on a separate line, using the format outlined in [1, Sec. Q], which looks like Author1, Author2, private communication, Abbrev Month, year
5. You may optionally provide a summary of the conversation under the citation in the citations.txt or refer to a separate file under transcripts/ with a description. The purpose of the summary is to provide additional context for what the conversation covered.

1. General citations are required for any outside source used
   • Include a short description regarding what the source was used for in the citations.txt
2. Inline citations are required whenever the influence of a specific outside source is attributable to specific code. Such situations include
   1. Verbatim copying of code
   2. Direct translation of code in another language (including pseudocode)
   3. Implementation of an algorithm as described in book or tutorial
   4. Code generated by an AI

1. Inline citations for code have extra requirements to ensure that it is clear where your work begins and another ends.

2. The following are the only acceptable formats for citing a portion of code inline.

   • For C++ or C:

   // BEGIN_CITATION [4, file.cpp:123-456]
   Code that was influenced by the citation here
   // END_CITATION
   

   • For Python or other languages where # is a comment:

   # BEGIN_CITATION [5]
   Code that was influenced by the citation here
   # END_CITATION
   

   • For xml and similar languages:

   <!-- BEGIN_CITATION [6] -->
   Code that was influenced by the citation here
   <!-- END_CITATION -->
   

   • Other languages, should use their comment character.
3. The start of the citation must say BEGIN_CITATION and is case-sensitive. It must be followed by a valid reference number in square brackets
4. The end of the citation must say END_CITATION and is case-sensitive.
5. When the inline citation references source code that is part of a bigger project, the inline citation must include the filename and line numbers (e.g., [4, file.cpp:123-126]).
   • The citation must indicate the file and lines that were used (e.g., [4, file.cpp:123-126]).
   • If the code was copied or adapted, the reader must be able to find the source of that code based solely on the information you provide.
6. If you look at a former solution to a problem (which is highly discouraged), it is the default assumption that there will be a direct link between what you looked at and what you are going to be coding, even if code is not copied directly.
   • The influence of that code (whether implicit or explicit) must be acknowledged with inline citations specifying specific files and line numbers.
   • The absence of specific inline citations is an assertion that there is not literal, functional, or architectural (outside of the assignment specifications) influence of that solution on your code.

• Comments are treated like other written text for the purpose of inline citations.
• It can be appropriate to provide inline citations in comments.
  • For example, if you read a blog post that said "Algorithm X is good at Y", it is appropriate to place a comment, as it helps the reader understand the theory behind the code.

If your AI tool directly edits code and makes git commits:

1. Commits that were primarily written by you with AI assistance should provide inline citations.
2. Commits where the code was primarily written by the AI have the following rules:
   • The AI is named as the author in the git commit log
   • Underneath the main citation line in citations.txt you should indicate which files were primarily written by AI and which by you as follows:
     • Files written by AI:, followed by an exhaustive list of filenames, one per line. Any file not in the list will be assumed to be written by you.
     • Files written by me:, followed by an exhaustive list of files written by you, one per line. Any file not in the list will be assumed to be written by AI.

   • Here is an example

     [4] Claude Code: Opus 5, Anthropic. Used On 5/5/2026. Transcript Available: transcripts/agent_export.txt
     - Files written by AI:
         - file1.py
         - file2.py
     - Files written by me
         - file3.py
         - file4.py
     

3. You can also add clarifying statements such as
   • Files written by AI and edited by me.

Some generative AI tools are built into editors (e.g., Copilot)

1. Basic code-completion tasks that do not introduce new logic into the system are exempt from citation.
   • Judgment is required here, but to be exempt, the generated code must not:
     1. Introduce any control-flow or branching statements.
     2. Implement any arithmetic or logical expressions.
     3. Call API functions that you have never heard of before.
     4. Introduce new variables or types that you would not have introduced yourself.
     5. Roughly, if the completion available would have been available in 2015, it is exempt.
2. Non-exempt code must be cited like any other AI generated code

1. It may be useful to include a transcript of your conversation with an AI chatbot, or otherwise document your interactions with AI.
   • Place the transcript under the transcripts/ directory or provide a persistent URL to the transcript.
   • Refer to them on the second line of citations.txt as
     • "[ Full | Edited | Summary ] [with AI] Transcript: <url | transcripts/filename>"
   • Full means the complete transcript, as exported from the AI tool (be careful, such transcripts can reveal personal information)
   • Edited means that you redacted, modified or curated the transcript in some manner
   • Summary means that you describe the overall purpose and content of the transcript, without directly providing content from the transcript.
   • It is appropriate to describe in citations.txt what editing you did.
2. AI may be used to help edit or summarize existing transcripts.
   • The usage must be disclosed by adding with AI, but no further citation is required.

1. During your AI usage, the AI may produce reference documents, graphics, or other references that you then go on to use
2. Such artifacts can be included under the transcripts/ directory or a persistent, publicly-accessible URL to them can be provided
3. It can also be appropriate to provide, in citations.txt a brief description of what the artifact is