Academic Integrity and Misconduct

Academic integrity is essential to conducting research, earning a credible degree, and maintaining trust and reputation. Your work must be your own, properly attributed, and honestly reported. As postgraduate taught students working on your Independent Research Project (IRP), you are expected to demonstrate the highest standards of integrity, honesty, rigour, and accountability in every aspect of your work - including code development, written and oral dissemination, and all forms of communication with supervisors, staff, peers, external partners, and the wider public. Academic misconduct is taken very seriously and may lead to severe consequences, including failure of the module or termination of your degree programme. An academic misconduct investigation can be initiated at any time, even after graduation, if concerns about the authenticity or integrity of submitted work come to light.

In addition to the university-wide academic integrity and misconduct policies, such as

• Academic Misconduct Policy and Procedure

• Guidance on Academic Integrity in Examinations and Assessments,

we set the IRP-specific rules and expectations.

You are responsible for understanding and adhering to all of them. A lack of familiarity will not be accepted as a justification in cases of suspected academic misconduct. They are non-negotiable.

While you are encouraged to discuss these with your supervisors to better understand how to adhere to them in your projects, supervisors cannot override, modify, or make exceptions to these rules.

1. Academic Integrity Declaration

To establish rules and expectations around academic integrity for the Independent Research Project (IRP), all students are required to familiarise themselves with and submit an Academic Integrity Declaration:

• (Imperial login required) Academic Integrity Declaration

• (Publicly accessible) Academic Integrity Declaration

This online form must be submitted twice during the IRP: once with your Project Plan and once with your Final Report and Code. The form must be submitted before the deadline for each deliverable, and submission is mandatory. It serves as your formal confirmation that you understand and agree to follow the IRP-specific academic integrity rules. By submitting the form, you confirm that you have read, understood, and have abided or will abide by all rules outlined. A deliverable will not be accepted without the academic integrity declaration. In addition, failure to submit the form, make accurate disclosures, or comply with these rules and expectations may result in a formal academic misconduct investigation.

The declaration covers several critical areas, such as:

• An explicit prohibition on the use of generative AI tools in any aspect of the preparation of written reports - including drafting, rewriting, rephrasing, translating, correcting grammar or spelling, expanding content, or generating ideas or illustrations. The written reports must be entirely your own work, expressed in your own words and reasoning. By “written reports,” we mean the project plan and final report only, as described in Deliverables. It is the student’s responsibility to understand whether the tools they are using constitute generative AI or not. Some examples of generative AI tools include ChatGPT, GitHub Copilot, Bard, Claude, Gemini, Perplexity AI, YouDao AI, Deep Seek, Scribbr, Grammarly AI, etc., but this list is not exhaustive. Writing parts of your report in non-English language and then using a generative AI tool for translation counts as “rewriting” and violates the ban on using generative AI because the English text generated is not your own. The IRP is not a test of English proficiency - minor language mistakes are acceptable as it is most important that the words you submit are entirely your own.

• A commitment to fully disclose any use of generative AI tools at any stage of the IRP - including code development, debugging, testing, planning, optimisation, documentation, packaging, learning, or research. You must clearly identify each tool used and explicitly state which parts of your work were generated or influenced by it.

• A commitment that all submitted work reflects your personal knowledge, understanding, and technical skills. Any use of resources - including websites, open-source code, examples, published articles in scientific journals, news articles, pre-prints (e.g. in arXiv or institutional repositories), books, or AI-generated suggestions - must be properly cited.

• A strict ban on outsourcing any part of the IRP to third parties. All submitted work must be your own and must not have been previously submitted for assessment (no self-plagiarism). All submitted work must be developed during the official IRP period - between the designated start and end IRP dates. You may not recycle or repurpose work completed before the IRP began, even if it was originally fully created by you. However, preliminary work carried out before the official start date may be included only if the student had already been officially allocated to the project and the work was done with the explicit approval and under the supervision of the main supervisor. Work completed independently, for other purposes, prior to the project allocation confirmation, or without oversight by the main supervisor may not be reused.

• Acknowledgement that you must be able to defend your work in a viva or authenticity interview, which may require you to explain sections of your report or code without any notes or AI assistance.

• While you are expected to receive guidance, advice, and feedback from your supervisor throughout the IRP - including, in some cases, the initial project idea or methodology - the submission, including both the written reports and the code, must reflect your own voice, reasoning, implementation, and independent understanding of the work conducted. The IRP is a supervised learning experience, but your submission should clearly demonstrate what you did, how you approached the problem, and how you interpreted and analysed the outcomes. You may have received general feedback or editorial comments on drafts of your report or code, but no one (including your supervisor, peers, or collaborators) may directly edit, rewrite, or rephrase any part of the submitted work - including code, text, figures, tables, or any other content. All elements of the submission must be your own work.

• Where the core idea, method, or starting code base was suggested or provided by someone else — such as your supervisor, a peer, or an external collaborator — and forms a substantial part of your project, this should be appropriately acknowledged in your report, for example, in the Acknowledgements section or as footnotes in appropriate places to ensure full transparency of what exactly your contributions are. It must be unambiguous from the submission what parts of the work are your own. General advice, feedback, or broad suggestions from your supervisor do not normally require explicit attribution.

The first submission of the Academic Integrity Declaration form with your Project Plan confirms your compliance with academic integrity rules and expectations up to that point in your IRP. Should any circumstances change between your Project Plan submission and Final Report submission that affect your academic integrity declaration, these changes can and must be appropriately declared when you submit the form for the second time with your Final Report.

The same Academic Integrity Declaration form (submitted twice) is used for both the Project Plan and Final Report and Code submissions. This ensures that students become familiar with the academic integrity rules and expectations early in the IRP timeline, preventing any unexpected obligations or surprises when completing the Final Report submission. Having encountered the form early (at the Project Plan stage) allows students to better prepare and understand the expectations throughout the IRP and before they sign it for the second time with their Final Report and Code.

AI Acknowledgement Statement

If you used generative AI in your IRP, you must include an AI Acknowledgement Statement in your written reports (both in your project plan and final report). This statement is usually at the beginning of the report, it is not counted towards the word limit, and should include (for each tool used):

• The tool name and version (e.g. ChatGPT‑4o)

• The publisher or provider (e.g. OpenAI, Google)

• The URL of the service

• A brief (usually one-sentence) description of how the tool was used (e.g. “used to draft Python unit-test scaffolds”)

• A statement confirming that all the submitted work is your own, despite the assistance received from generative AI tools

Please remember that using AI tools to generate any part of your written report is not allowed.

An example AI Acknowledgement statement:

“I used OpenAI’s ChatGPT‑4o (https://chat.openai.com/) to assist with debugging Python code. This generative AI tool supported my learning process, but the submitted work is my own and it reflects my own understanding and effort as I declared by signing the Academic Integrity Declaration.”

2. Plagiarism

Plagiarism is the act of presenting work created by someone or something else — including content generated by an AI tool — as your own. It is considered a serious academic offence and is dealt with in accordance with the university policies on Examinations and Assessments including specific reference to plagiarism and its relationship to Examinations and academic integrity. Plagiarism is also addressed in the Honesty and Integrity area of the Student Code of Conduct.

All students must familiarise themselves with the Plagiarism Awareness guidance from the Library. In addition, you are required to complete the online Plagiarism Awareness course: Plagiarism Online Course for Master’s Students. Completion of this course is mandatory. If you have taken it previously, we strongly recommend that you revisit the material and refresh your understanding before starting your IRP. This course covers essential principles of citation, referencing, and academic honesty.

Plagiarism rules apply to all forms of content, not just text. This includes figures, tables, diagrams, code, data visualizations, and any other material that originates from external sources. All such content must be properly attributed and, where appropriate, permission obtained for reuse.

Even when properly quoted and cited, copying larger sections of text from other sources constitutes poor academic practice. Your written reports should predominantly consist of your own words, demonstrating your understanding and analysis. Direct quotations should be used sparingly and strategically - primarily when it is essential to preserve the exact formulation of someone else’s idea or when the specific wording carries particular significance to your argument. Full sentences, especially multiple sentences, are almost never in quotes. Instead, you should aim to paraphrase and synthesize information from external sources, integrating it into your own narrative and analysis.

Plagiarism detection tools often produce unreliable similarity scores that should not be interpreted as definitive measures of plagiarism. They frequently flag common phrases and standard technical terminology, such as “convolutional neural network we designed was…” or “in this work, we explore the influence of…”, that represent conventional scholarly language rather than copied content. Additionally, similarity percentages are heavily influenced by document length, with shorter reports often showing artificially inflated scores. Generative AI detection tools are similarly unreliable, often producing false positives and negatives. Due to these limitations, we assess potential academic misconduct, such as plagiarism or violations of the generative AI ban, through a careful review rather than relying on automated detection scores. Students do not have direct access to Turnitin or other plagiarism detection tools; when necessary, we submit written reports for checking.

Since the project plan is part of the same assignment as your final report, you can re-use text from your project plan as long as it is your intellectual property, without worrying about self-plagiarism.

3. Regular commits to IRP repositories

You are expected to stay actively engaged with your Independent Research Project (IRP) throughout the summer. Keeping your project version controlled with frequent, well‑described commits is not merely a good practice - it is a safeguard that could provide evidence of consistent engagement throughout your IRP. A detailed, time‑stamped history is the first line of defence if an examiner questions authorship. It also lets supervisors see problems early and offer targeted help.

• Frequency – commit and push after every meaningful chunk of progress (about once or twice each working day). This rhythm normally produces at least one substantive commit per week.

• Commit messages - each commit message must explain what changed and why. Brief, empty or token messages (e.g. “update”, “fix”, “add file”) undermine the record.

• No “mega‑commits” – delivering a single, end‑of‑project or end-of-month commit with many files and no development trail to demonstrate the evolution of your project is a red flag and may trigger an academic misconduct investigation.

• Branching – commits do not need to be made directly to the main branch. You may commit and push to any branch as appropriate for your workflow.

• Scope & confidentiality – version‑control everything you can: code, Jupyter notebooks, data processing scripts, LaTeX/Word drafts. For confidential work, covered by an NDA, discuss solutions with your IRP supervisors. If your work is not confidential or covered by NDA, it must be version controlled, committed and pushed to your IRP repository.

• Cloud-based work – if you work in a cloud service such as Google Colab, this does not replace the need for version control. You must regularly commit all relevant files (e.g. Jupyter notebooks, data processing scripts, outputs) to your IRP repository to maintain a clear project history.

• Commit pattern – splitting a larger part of the work into multiple chunks and committing them separately to artificially simulate a gradual development is not allowed. This tactic is easy to detect and will be interpreted as an attempt to mislead reviewers about how the project evolved over time. Such behaviour is considered suspicious and may trigger an academic misconduct investigation.

• Large files – large files such as raw or processed data files, simulation results, and high-resolution visualisation outputs should not be stored directly in the repository. These can be uploaded to your university-provided OneDrive, and a link to the relevant folder can be included in the repository README. However, all code required to generate these outputs must be included in the repository to preserve the reproducibility and transparency of your work.

• Written reports – the project plan and final report must be version controlled in the same way as everything else. If you are working in Overleaf or MS Word, you are expected to regularly download and commit the relevant files to your repository — for example, the .tex, .bib, and figure files for LaTeX, or the .docx file for Word, at least once per week.

• Reproducibility – your IRP must be fully reproducible. You are expected to make every reasonable effort to ensure that any result, figure, analysis, or output presented in your written report or during the viva can be independently reproduced. This means all necessary files — including code, scripts, configuration files, and any supporting resources — must be included in the repository. If any data or files are stored externally (e.g. in OneDrive due to size), clear links and usage instructions must be provided at relevant places.

We take academic misconduct very seriously. A well-documented version history can be important evidence in demonstrating that your work is genuinely your own. In the event of any allegation, such as the use of generative AI tools to generate large parts of your code or outsourcing your work (e.g. delegating your work to somebody or something else), a consistent and authentic commit history could help you demonstrate academic integrity.

We understand that there may be weeks when you cannot make progress due to technical challenges, illness, or taking time off. You do not need to notify us in those cases. We will not monitor your commits in real-time, but we may decide to review them at any point to understand how your work evolved, particularly if concerns of academic misconduct arise.

If you are working on a confidential external project, which is covered by an NDA, and cannot use the IRP repository due to confidentiality restrictions, we will rely on your host organisation’s oversight and expect them to flag any suspected cases for us to investigate. For any IRP, written reports must be version controlled and committed regularly to the IRP repo.

Manipulating Commit History

Modifying the commit history (including but not limited to squashing, force pushing, or altering previous commits) without clear justification and explicit approval from the module coordinator is strictly prohibited. The commit history serves as an important record of your project development and must remain intact to maintain academic integrity and allow proper assessment of your work progression.

If you believe that there are exceptional circumstances that require commit history modification, you must contact the module coordinator before making any changes and receive written approval.

4. Engaging with Supervisors and Documenting Meetings

Just as regular commits to your IRP repository help demonstrate consistent engagement with your project, regular interaction with your supervisor is key to making progress, completing your IRP on time, and maintaining academic integrity.

We expect students to attend all scheduled meetings with their supervisors and to participate actively in the discussions. If you are unwell or taking a planned break, that is understandable, but attendance at all meetings is expected under normal circumstances. You are expected to take an active role in every meeting. This includes discussing your progress since the last meeting, raising any questions or concerns, and outlining your plans for the next phase of your project. This applies equally to individual and group meetings. In group meetings, you should still contribute meaningfully and reflect on how the discussion relates to your work.

Meetings should be held in person whenever your supervisor is available. If an in-person meeting is not possible, for example if your supervisor is working remotely, online meetings must be conducted professionally, with your camera on. These meetings are a formal part of your academic engagement and should be treated accordingly. You are expected to attend all meetings with a stable internet connection. Technical constraints preventing you from using your camera must not become routine and will only be accepted in rare and exceptional circumstances — for example, during fieldwork or when collaborating with partners based in remote areas.

Our administrative team regularly contacts all supervisors to ask whether students attend meetings and engage as expected. If a supervisor reports repeated non-attendance or a lack of engagement, this may result in the matter being escalated and formally investigated.

Supervisory styles vary; some students may meet their supervisors more frequently than others. However, we recommend meeting your main supervisor at least once every two weeks.

logbook.md

After each meeting with any of your supervisors, you are expected to update your logbook.md file in your IRP repository. This should be committed and pushed shortly after the meeting to the main branch. Each logbook entry normally should include, for each meeting: (1) date, (2) who attended, (3) key points discussed, (4) feedback received, and (5) what you plan to do before the next meeting. There should be one entry per meeting in logbook.md. Please do not include anything personal or confidential that is not directly related to your IRP - such information should not be stored in the repository.

If your supervisor is unavailable for a meeting, you could still add a logbook entry as a personal reflection. Use this to summarise what you have worked on, outline any concerns or open questions, and set out your plan for the coming days. This is a good way to demonstrate ownership of your project and to build a clear, time-stamped record of how your thinking and progress have evolved. Also, writing things down, even informally, can often help you clarify your ideas.

While the primary purpose of the logbook is to document meetings with your supervisors, you are also encouraged to record relevant discussions with anyone who has inspired your project - this might include informal chats with peers, external collaborators, or even reflections from solo brainstorming sessions

We do not monitor your logbook during the IRP, but we may review it at any point to understand how your project evolved, particularly if any concerns arise. A clear and consistent meeting record, alongside your commit history, can help demonstrate that your work is your own and that you were actively engaged throughout the project.

An example of a logbook entry

Meeting (17 June 2025)

• Present: Susan Zhang (SZ, student), Marijan Beg (MB, main supervisor)

• Key points discussed:

  • Reviewed the current progress on implementing the numerical solver for the Landau-Lifshitz-Gilbert (LLG) equation with adaptive time-stepping.

  • MB provided clarification on the penalty term in the dynamics equation to preserve the norm of the field.

• Feedback received:

  • MB advised checking the stability of the time integration by running convergence tests with smaller time steps.

  • Supervisor suggested implementing a minimal test case (e.g., skyrmion, meron, or trivial texture) before applying to hopfions.

  • Emphasised the importance of attending the meetings regularly and how to use generative AI responsibly.

  • MB thinks I am not writing enough tests and should take advantage of GitHub Actions. He pointed me to a YouTube video tutorial about test driven development and a webpage about pytest fixtures.

• Work plan before next meeting:

  • Accept and address the first two points from the feedback – run convergence tests with varying time steps and run a minimal test case.

  • Run basic validation tests using known solutions.

  • Now that the penalty term in the LLG equation is clear, I will complete the Methods section in my final report draft.