Deliverables

• Project Plan (5%)

• Final Report AND Code, also defended in viva (95%)

Deadlines

Deadlines for both deliverables are published on the Important dates page.

Academic Integrity Declaration

All students must submit an Academic Integrity Declaration 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. For further information refer to Academic Integrity and Misconduct.

We strongly advise all students to familiarise themselves well in advance with the IRP module-specific academic integrity rules and expectations. This includes the complete ban on the use of generative AI tools in preparing written reports.

Written Reports

As part of the Independent Research Project (IRP), students are required to submit two written reports:

• Project Plan

• Final Report

Both reports are mandatory and must be submitted in order to successfully complete the IRP. Submission is not optional, and failure to submit either report will result in an incomplete assessment of the module.

Title page

The first page of the project plan and the final report must include the following information:

1. University (“Imperial College London”),

2. Department (“Department of Earth Science and Engineering”),

3. MSc course (e.g. “MSc in Applied Computational Science and Engineering”),

4. Project Title,

5. Student’s full name (no initials or nicknames),

6. GitHub IRP repository (e.g. “ada-lovelace-academy/irp-mm123”)

7. Supervisors (in addition to the main and second supervisor, give credit to everybody who provided significant support or guidance - see the tip below),

8. Submission month and year (e.g. “August 2025”).

Example Word and LaTeX title page templates are provided in the template repository. These templates are provided as guidance - you are free to design your own title page, provided that all required information is included and clearly presented.

Tip

Your title should be concise, specific, and descriptive — clearly indicating the focus of your project. It may differ from the original title approved at the start of the IRP, and you are allowed to refine or update it between the project plan and the final report.

Tip

You are welcome to include additional individuals on the title page as supervisors if you wish to acknowledge their support or contribution to your learning. These individuals do not need to be officially listed in the IRP records, and you do not need prior approval from the IRP Team to include them. This is particularly important to ensure that everyone who supported your work — such as PhD students or postdocs — is given the credit they deserve.

Formatting

You are free to format your project plan and final report in a style of your choosing. However, we strongly recommend that you follow the Style Guide published by the British Dyslexia Association.

This guide promotes inclusive and accessible document design, helping ensure that your work is easy to read and navigate for all audiences — including examiners, moderators, and peers with visual impairments or learning differences. Key principles include using clear fonts, sufficient line spacing, meaningful headings, left-aligned text, and avoiding dense blocks of text or excessive italics and underlining.

Similarly, to ensure your figures are accessible to all readers, use high-contrast colour schemes, large and legible text, and clear legends. Avoid relying solely on colour to convey meaning — use patterns, textures, labels, or symbols where appropriate. For more guidance, see

• Dos and Don’ts on Designing for Accessibility – GOV.UK

• Data Visualizations, Charts, and Graphs – Digital Accessibility by Harvard.

Length and file size limits

The written reports for the IRP must adhere to the following limits:

written report	word limit	figure + table limit	max PDF file size
Project plan	1,500	5	4 MB
Final report	5,000	10	8 MB

Reports that are shorter than the stated limits will not be penalised. A small (max. 5%) tolerance is allowed to account for variation between word-counting tools. The following elements are excluded from the word count or “figure + table” limits:

• Title page

• Acknowledgements, including the AI Acknowledgements section

• Table of contents

• List of figures / tables / symbols / abbreviations

• Section/subsection titles

• Text within figures or tables (e.g. axis labels, legends, annotations)

• Captions for figures and tables

• Footnotes

• Equations and formulae (including inline ones)

• References section (i.e. the list of references at the end of the report)

• Appendices

Code snippets, algorithms, and pseudocode have different counting rules depending on their presentation:

• When included inline in your text (e.g., “The function divergence_m() computes the divergence of the normalised magnetisation field…”), they count toward the word limit.

• When formatted as separate figures with captions (e.g., “Figure 3: Python implementation of the Monte Carlo optimisation algorithm”), they count toward the “figure + table” limit instead

In-text citations are included in the word count as they form part of the main text. Examples:

• Harvard format: “(Smith, 2020)” = 2 words

• Numbered format: “[15]” = 1 word

Warning

The word count limits are strict, and students must ensure their reports stay within the stated maximum. A small tolerance (up to 5%) is allowed only to account for minor discrepancies between word-counting tools — the tolerance does not extend the official word limit. You should aim to stay clearly within the limit.

The figure and table limit refers to the combined total number of standalone figures and tables allowed in the main body of the report (n_figures + n_tables <= limit). Multiple sub-figures or sub-tables grouped under one caption (e.g., Figure 2a–d) count as one figure.

Appendices are not included in the word count or the figure/table limits. However, they should be used sparingly and appropriately, not as a way to bypass length limits. The primary purpose of appendices is to provide supplementary material — such as extended results, detailed derivations, or code snippets — that supports the main text but is not essential to follow the core arguments or findings. Examiners are not required to read appendices.

Similarly, tables and figures must not be seen as a way to circumvent the word limit. They should be used to present data or results that are essential to understanding the main text, not as a means to add extra text content without counting toward the word limit.

Counting Words in LaTeX with texcount

LaTeX files include a lot of markup, so using a regular word counter can give misleading results. texcount is a command-line tool designed to accurately count words in LaTeX documents.

It provides a detailed breakdown by section and separates main text, captions, headers, footnotes, and more. The abstract is sometimes not included in the total word count given by texcount, depending on the document class used, so ensure you understand if it is or not.

To count words with section-by-section detail:

texcount -sub=section your-report.tex

This gives a clear picture of how words are distributed across the document. For further details, refer to one of many tutorials available online.

Overleaf has a built-in word counter, which is usually good enough for general use. But if you need more control or transparency, texcount is a reliable alternative.

Report structure

IRP topics come from a wide range of fields — physics, computer science, environmental science, finance, and more. Each of these communities has its own way of writing up and disseminating research. We strongly suggest that you structure your final report like a journal article in the field you’re working in. This is also why we have set clear word and figure/table limits — they reflect the kind of constraints researchers typically work within when publishing their work.

We recognise that, regardless of the structure or guidelines we could adopt, some students and supervisors may prefer different ones based on disciplinary conventions or personal preferences. For this reason, we have chosen not to impose a rigid structure or provide a fixed template for the final report, allowing flexibility for students to adapt their writing to the conventions of the field.

Therefore, some of the best examples of how to write and organise your final report can be found in published journal articles related to your topic. If you’re not sure which journals are most relevant, ask your main supervisor — they will be able to point you in the right direction. Below, you can find some examples of previous IRP written reports, which can serve as inspiration for your own work.

What to include?

Here, instead of imposing a specific set of sections/subsections, we provide the following guidance on what content your report should include.

• Abstract. A concise summary (approximately less than 200 words) of the project’s purpose, methodology, key results, and conclusions. The abstract should enable readers to quickly grasp the contributions and scope of your work.

• Problem Description: Clearly define the research question or commercial/engineering challenge. Be specific and ambitious, but avoid overpromising.

  • Significance: Explain why your work matters. What potential contribution does it make to the field? Could it have broader impact or practical applications?

  • Review of Existing Work: Provide a critical overview of relevant literature or existing solutions. Describe the current state of the art, key findings, and limitations. Explain how your work builds on or differs from what has been done before. What is the originality or novelty of your work?

  • Objectives: Outline clear, specific, and measurable objectives that guided your work.

• Methodology: Describe and justify the method(s). Why these methods were chosen? Are there alternative approaches you considered? Discuss any limitations of your chosen methodology and demonstrate critical thinking in evaluating your choices.

• (Project Plan only) Future Plan: Provide a realistic project timeline, outlining key phases, milestones, and estimated deadlines. Avoid overpromising. If applicable, include any preliminary results or insights that support the feasibility and potential success of your project. Identify any potential risks or challenges that may arise during the project and outline strategies to mitigate them.

• (Final Report only) Results: Present the key outcomes of your project, with appropriate figures and tables. Clearly explain and interpret what the results show. Don’t just present the data — analyse it. What do the results mean in the context of your research question or problem? How do they compare to existing work? Are there any unexpected findings? Don’t let the reader draw conclusions on their own — guide them through your analysis.

• (Final Report only) Discussion and Conclusions: Discuss the implications of your results. What were the most challenging aspects of the project? What worked well and what did not? Analyse the strengths and limitations of your solution, and suggest possible next steps. Be formal and analytical — quantify your statements where possible and ensure that all conclusions are directly supported by your results. If relevant, briefly describe any planned future work related to your project.

While both the project plan and final report should include key components such as the abstract, problem description, and methodology, they are not expected to be equally detailed. The project plan is submitted early in the IRP timeline, often before you have fully reviewed the literature, explored all methodology options, or obtained meaningful preliminary results. Project plan also has a much stricter word limit, which naturally constrains the level of detail. As such, the project plan should be seen as a snapshot of your early thinking — a structured outline of your ideas and proposed direction (future plan). Importantly, the project plan is not a fixed promise. As you progress through your project, your ideas will evolve, and your approach to the problem may change based on new insights or challenges. You are encouraged to adapt and refine your plan as needed, and making thoughtful modifications after submission is both acceptable and expected. Over time, your understanding is expected to grow and evolve, and the final report will reflect a more developed, informed, and critically assessed account of your work.

Framing Perspective

When approaching the project plan, it can be helpful to think of it as a research proposal. Your goal is to convince your reader - whether a supervisor, examiner, or imagined funder - that the problem you intend to tackle is important, meaningful, and has the potential for impact. You also need to demonstrate that your proposed methodology is appropriate and achievable within the three-month IRP timeline. This is exactly what researchers do all the time when they apply for funding from government agencies or other funding bodies — they argue for the significance of their problem, explain how they intend to solve it, and justify why the work is worth investing in. In this sense, the project plan is about making a compelling case for why the project should go ahead, based on its relevance and feasibility.

The final report, by contrast, takes on the character of a research paper. At this stage, your task is to report your findings to the community and beyond. You want to convince your readers that your conclusions are well supported by evidence, that your methodology was sound, and that your analysis was thoughtful and rigorous. A good final report, like a good research paper, should clearly communicate what was done, why it matters, and what was learned — in a way that gives others confidence to cite your work, build on your results, or apply your insights in practice. It should demonstrate critical engagement with the problem, clarity of thought, and transparency in how results were obtained and interpreted.

Citation style

We do not impose a specific citation style, as different fields follow different conventions - for example, IEEE is common in engineering and computer science, APA in the social sciences, and Harvard in biology, education, and other fields. You are free to use any recognised academic referencing system, as long as it is applied consistently and correctly throughout your report. As with report structure, you are encouraged to look at published journal articles in your field to understand the typical citation practices. For further guidance on how to cite sources correctly, please refer to the Imperial College London Library’s referencing guide.

Past Examples of Written Reports

Important: The examples provided below are from previous years, during which some IRP rules (e.g. on formatting, length, or use of generative AI tools) may have differed from the current guidance. These reports are shared for inspiration only - not all of them achieved distinction-level marks, and some include elements that did not meet the past requirements or would not meet today’s requirements. Identifying exceptions or inconsistencies in these examples does not override any of the current IRP rules. Always follow the latest official guidance outlined on the IRP website.

1. David Colomer Matachana - Deep learning for leopard individual identification: an adaptive angular margin approach (2024)

   • project plan

   • final report

2. Andrei Cristian-Danila - Convolution Revolution: Wiener Filters for Embedded Text Comparison (2024)

   • project plan

   • final report

3. Ardan Suphi - Using deep learning to predict water ice presence at the lunar poles (2024)

   • project plan

   • final report

4. Sarah Nesti - Enhancing higher education: Personalised learning with large language models (2024)

   • project plan

   • final report

5. Anna Carina Smith - Exploring land use effects on intraurban CO\(_{2}\) using machine learning algorithms for urban decarbonisation (2024)

   • project plan

   • final report

6. Hadrian Fung Nok Hei - Rapid modelling of ATES using machine learning (2024)

   • project plan

   • final report

Centre for Academic English (CfAE)

The Centre for Academic English (CfAE) provides a range of resources to help you improve your academic writing and presentation skills. CfAE offers IRP-tailored writing and presentation workshops - check the Important dates. You can also access the self-study learning blocks on Blackboard, covering key topics like planning, flow, cohesion, narrative, and STEMM communication or book a 1:1 session with a writing coach for personalised feedback.

Why generative AI is prohibited for grammar, spelling corrections, and translation

The fundamental issue with using generative AI for grammar and spelling assistance lies in the unpredictable nature of these tools’ responses, which depend entirely on how they are prompted. At one end of the spectrum, a student might ask an AI tool to identify specific misspelled words - functionally similar to a traditional spell checker. However, at the other end, a student may request that AI “improve/fix grammar and spelling”, which typically results in comprehensive text rewriting that restructures sentences, alters tone, introduces new phrasing, and may even modify the underlying arguments or emphasis. In such cases, the resulting text no longer reflects the original author’s voice, reasoning, or authentic expression of ideas.

Similarly, using generative AI for translation presents comparable concerns. While translation might appear to be a mechanical or neutral task, AI-generated translations often do far more than convert words between languages. They interpret meaning, reframe idiomatic expressions, and make stylistic and structural decisions. As a result, the final output is not simply a direct translation - it is a new composition shaped by the AI’s internal choices. The student’s original voice and thought process can be lost or distorted in translation, making the submitted text no longer a true reflection of their own work.

Students are expected to write their IRP reports in English. However, traditional online dictionaries may be used to look up individual words or expressions, particularly to clarify meaning or confirm usage. These tools support comprehension without fundamentally altering the student’s writing or expression, and are therefore acceptable.

In academia, when you submit work under your name, you are claiming intellectual ownership not only of the ideas but also of their expression and articulation. If an AI tool has substantially rewritten or reinterpreted your text - whether through “grammar correction” or translation - the words, flow, and argumentation may no longer be authentically yours. This distinction is crucial because IRP assessment evaluates not only what you think, but how you think and how you communicate those thoughts. At the end of the day, your name and not ChatGPT’s is on the title page of the written report as the author.

The challenge lies in the vast spectrum of possible AI interventions. Different prompts, AI models, versions, and even the same prompt at different times can yield dramatically different levels of text modification. To ensure fairness across all students and to avoid introducing subjective judgments about acceptable versus unacceptable use of AI tools, **we maintain a complete ban on any use of generative AI for textual modifications, including translation. Traditional tools such as built-in spell checkers, grammar checkers, or online dictionaries remain appropriate for identifying surface-level errors or seeking clarification without the risk of substantial text alteration.

It is important to remember that the IRP is not an assessment of English language proficiency. It focuses on evaluating specific learning outcomes, including your ability to “communicate your work clearly and defend it under critical questioning”. The examiners would rather read your original thoughts expressed in your own words — with occasional language mistakes — than polished language that may not truly reflect your thinking or authorship.

Submission

Both written reports must be submitted to your private IRP GitHub repository before the respective deadlines. Submissions must follow the specified filename conventions and GitHub Actions workflow must pass as outlined in the repository.

Modifications After Submission are Not Permitted

Once the deadline has passed, no changes are permitted to the submitted written reports in the deliverables/ directory. If you wish to continue working on your Project Plan (e.g., to expand or revise it for your Final Report), you must make a copy of the file elsewhere in your repository (outside the deliverables/ directory) and continue your updates there. The originally submitted version must remain unchanged after the deadline.

Code

The code required to fully reproduce all results, within reason, must be submitted to your IRP GitHub repository. Reproducibility is essential for ensuring that examiners and other researchers can verify your results and for demonstrating the integrity of your work. All code used to generate reported results, such as plots and tables, should be included.

You are free to organise your repository as you wish, as long as the pre-created files remain intact and it is clear where each component is, in what order scripts should be run, and how the results are generated. Do not submit this code in the deliverables/ directory. Follow best practices for sustainable and maintainable code, including appropriate documentation and clear naming. For more information, see GitHub repository.

If your project is external AND confidential, you do not need to submit your code to GitHub, but you must discuss in advance with both your supervisors how the code can be made available to your internal supervisor for assessment. For more details, refer to the NDAs and Other Documents.

Only the code necessary to reproduce the results presented in your final report is expected to be submitted. We do not expect to see code drafts, non-functioning scripts, or irrelevant files in your main repository structure. That said, producing such code is a normal part of the development process, and you are expected to make regular commits throughout your project. Before the final deadline, you should tidy your repository by moving any “irrelevant” or exploratory code into a separate directory (e.g. dev/ or sandbox/) and include a note in your README clarifying that examiners do not need to review it.

Sharing data

Unless very small, data files should normally not be included directly in your repository. Depending on the licence of the raw dataset, you may instead provide links to the data in appropriate places (e.g. in a Jupyter notebook, the README, or documentation). If the licence does not allow you to share the raw data, do not copy it anywhere - you can assume that examiners will have access to it.

Intermediate data produced during your project (e.g. processed data, trained model weights, or cached results) do not need to be submitted. However, the code required to reproduce these intermediates from the raw data must be included.

If you choose to share intermediate data or model weights for convenience, you may upload them to OneDrive (or another suitable storage service) and provide links in your repository or report at the appropriate points. It is your responsibility to ensure your supervisors have access to these files.

Code extensions, patches, and pull requests

If your project extends the capabilities of or adds functionality to an existing codebase, you should think of your code as an extension or patch. You do not need to submit the original codebase - only the code you have developed. If it is absolutely necessary to include portions of the original codebase, ensure the license permits this and make it completely clear in your submitted code what constitutes your own work. Your repository should include all necessary information on how your extension can be installed or how the patch can be applied.

If the original codebase you are extending, improving, or fixing is open source and hosted on GitHub, we strongly encourage you to contribute to it via pull requests following established best practices. This approach provides clear documentation and a permanent record of your contributions. In your written reports and IRP repository, you can reference these pull requests via their GitHub URLs to showcase the code you developed. When pull requests provide a comprehensive record of your contributions, resubmitting the same code to your IRP repository is unnecessary, as the pull request history serves as sufficient evidence of your work on the original codebase.

Viva

The final report and code are examined through an oral examination (viva), which is a mandatory component of the Independent Research Project. All students are required to complete the viva. It provides an opportunity for both the student and the examiners to clarify aspects of the project that may not be fully explained or easily understood from the written report or code alone. In addition to this, the viva also plays a key role in safeguarding academic integrity by verifying that the work submitted was carried out by the student, except where appropriate acknowledgements have been made. The student is expected to demonstrate a deep, independent, and comprehensive understanding of the project. The final mark for the project will be determined by the examiners following the viva. For viva dates, see Important dates.

Each student is allocated a 30-minute viva slot. The exact date and time will be scheduled based on examiners availability and will normally be communicated several weeks in advance. Students are expected to be fully available during the entire week allocated for vivas. Except in cases of mitigating circumstances - such as illness or unforeseen emergencies - we are not able to accommodate individual scheduling requests or rearrangements by students. A viva cannot be scheduled outside of the viva week unless mitigating circumstances claim is approved. Students will be given the opportunity to indicate whether they prefer to attend their viva in person or remotely via MS Teams. In-person vivas are conducted at Imperial College London, South Kensington Campus, London SW7 2AZ. Please note that while we will try to honour in-person requests, if the examiners are not available to attend in person, the viva will be conducted remotely, regardless of the student’s preference. If the viva is conducted remotely, the student must ensure they are ready to join on time, with a stable and high-quality internet connection, and with their camera turned on for the entire duration of the viva. In addition, the student must be prepared to present their Imperial College London student ID or a valid government-issued identification document for verification at any point during the viva.

Additional atendees: Vivas for internal projects are open to the public. Anyone may attend and, with the moderator’s permission, may participate by asking questions during the questioning stage. In contrast, vivas for external projects are confidential by default. Attendance is limited to the student, supervisors, the appointed examiners, and any designated moderators. No other individuals may be present unless prior approval has been granted. If a student working on an external project wishes to invite additional attendees - such as friends or family - it is the student’s responsibility to obtain explicit approval from their main external supervisor well in advance of the viva. This is to ensure that any non-disclosure agreements (NDAs) or confidentiality obligations in place are not breached. It is also the student’s responsibility to communicate all relevant details - such as the time, location, or Microsoft Teams link - to any approved additional attendees. Recording of all vivas - whether audio, video, screen capture, or in any other form - is strictly prohibited for all participants.

Viva structure

While individual moderators and examiners may vary their approach slightly, we strongly recommend that each viva follows the structure outlined below to ensure fairness, clarity, and consistency:

1. Introduction and Setup (up to 2 minutes): The viva begins with brief introductions, if the student, examiners, or moderator have not previously met. The student is asked to confirm their name and to indicate that they are ready to proceed. Any necessary technical checks - such as audio, video, and screen sharing - should be completed at this stage. The student may also be asked to present their Imperial College London student ID or a valid government-issued identification document for verification.

2. Student Presentation (up to 10 minutes): The student delivers a short presentation summarising the key aspects of their project. The presentation must not exceed 10 minutes; if it runs over time, the moderator should intervene to ensure sufficient time is available for questions and discussion. While the presentation delivery itself is not formally marked or part of the marking criteria, it serves an important function by allowing students to present their work in formats not possible in written reports - such as through visuals, live demonstrations, or interactive elements - and to trigger meaningful discussion with examiners. Students may choose any presentation format they prefer: traditional slides, posters, live demos, or other approaches. However, the presentation must be delivered live by the student; pre-recorded presentations are not permitted. Students are expected to prepare their chosen presentation format in advance and should ensure they are aware of any technical limitations - for example, if their viva is held remotely or in-person - adapting their approach accordingly. Some guidance on presentation delivery is provided in the presentation workshop delivered by the Centre for Academic English.

3. Critical Questioning (approximately 12-15 minutes): Following the presentation, the student will be asked a range of questions covering any aspect of the project. These may range from general and open-ended questions to very specific and targeted, e.g. to a particular line of code or a sentence in their report. This stage helps examiners clarify key points and, importantly, establish that the student has a deep and thorough understanding of the work as required by the academic integrity rules and expectations. The tone is intended to be rigorous but constructive. Students must be prepared to demonstrate any part of their work - such as code, figures, documentation, or results. If materials are hosted online (e.g. GitHub, OneDrive), it is the student’s responsibility to ensure there are no access issues, such as VPN requirements, that could disrupt the viva. While students are permitted to bring copies of their written report or other reference materials, these may only be consulted with explicit permission from the moderator, granted on a per-question basis. The use of generative AI tools during the viva to assist with answering questions is strictly prohibited. The moderator leads and controls the questioning process, deciding who may ask questions, when questions are asked, when to move to the next question, and when the questioning phase is over.

4. Examiner Discussion and Provisional Mark (3-5 minutes): At the end of the viva, the student - and any other attendees - will be asked to leave the meeting. The examiners, supported by the moderator, will then hold a short discussion (typically 3-5 minutes) to review their provisional marks and agree on a final mark for the project. The discussion will take into account the student’s performance in the viva, including the clarity and depth of their responses. The moderator facilitates this process and makes the final decision of the student’s mark.

Important Notes:

• Further Authenticity Interview: The moderator and examiners may decide that additional questioning is required to establish the authenticity of the submitted work. Therefore, even after the viva, the student may be invited to an authenticity interview, designed to further verify that submitted work genuinely reflects the student’s own understanding, effort, and skills as required by the Academic Integrity rules and expectations (see Academic Integrity and Misconduct).

• All marks are provisional: Authenticity interviews can take place even after the viva and after the provisional marks have been released – the outcome of such interviews may result in changes to the provisional mark.

Examiners and Moderator

Each viva is attended by at least two examiners, who are responsible for assessing the IRP and contributing to the IRP mark. In addition, a moderator is present to oversee the viva, ensure consistency across different cases, and facilitate the viva. The moderator may be a separate person or may also serve as one of the two examiners. The IRP Team is not obligated to reveal the identity of the examiners to students in advance of the viva.

Moderators (also known as “supermarkers”) are appointed by the IRP Team based on their experience in assessing a wide range of projects and their ability to help maintain consistency and fairness across multiple projects. Their role is especially important in guiding the discussion, ensuring marking criteria are applied appropriately, and confirming the agreed mark. Individual marks from the examiners are taken as provisional, with the moderator deriving the overall mark. The moderator may ask individual examiners for further justification of their provisional marks to ensure appropriate application of the marking criteria.