Writing a clear BSc final report

1Introduction

This guide is mainly intended for students preparing a BSc final report within the Computational Heterogeneous Catalysis research group. It explains the role of the main report sections and gives practical guidance on how to shape the document into a clear, readable, and scientifically convincing piece of work. The focus is not only on what sections should be present, but also on what each section should achieve for the reader.

This is a long document. You can read it from beginning to end in one sitting; the expected reading time is shown at the top of the page. You can also use it as a reference guide while writing, returning to specific sections when you are working on your outline, figures, equations, references, or AI disclosure.

The document is shared publicly in the hope that it may also be useful to students in other research groups, both at TU/e and elsewhere. Use it as a starting point while planning and writing your report. It is not a replacement for project-specific instructions from your supervisor or programme, but it should help you make sensible writing choices, avoid common structural problems, and understand how the different parts of the report work together.

2Alignment with your supervisor

Before writing too much of the report, discuss expectations with your supervisor. A BSc final report is not only a document with standard scientific sections; it is also a project-specific account of your work. Different supervisors, projects, and programmes may have different expectations about emphasis, level of detail, formatting, deadlines, and what should or should not be included.

It is useful to align on these points early:

• When should a first outline or draft be handed in?
• How much time does your supervisor need to give feedback?
• Which sections does your supervisor want to see in the first draft?
• Are there project-specific topics that must be discussed?
• Are there topics, raw data, failed attempts, or technical details that should be left out or moved to an appendix?
• How detailed should the theory and methods sections be?
• What format, length, or assessment criteria apply to the report?
• How should feedback be handled after the first draft?

Do not wait until the final week to discover that your supervisor expected a different structure or a different level of detail. A short alignment meeting, together with a one-page outline, can prevent a lot of rewriting later. It also helps both student and supervisor agree on what a successful report should accomplish.

3Sections of a BSc final report

3.1Title

The title should be specific, compact, and informative. It should identify the main system, method, question, or outcome of the project without trying to summarize every detail. Avoid vague titles such as "BSc final project" or "A computational study". A good title helps the reader understand the report before opening the abstract.

3.2Abstract

The abstract is a short standalone summary of the full report. It should state the context, the central research question or aim, the most important methods, the main findings, and the principal conclusion. Keep it factual and concise. Do not introduce references, unexplained abbreviations, or details that are not important for the overall message.

A useful abstract often answers four questions:

• What was investigated?
• Why was it investigated?
• How was it investigated?
• What was found and concluded?

3.3Introduction

The introduction explains the scientific context and motivation. It should guide the reader from the broader field toward the specific question of your project. A strong introduction does not merely list background facts; it builds a rationale for the work.

A useful way to think about the introduction is as a funnel. Start broad, with the larger scientific or technological field in which the project sits. Then gradually narrow the focus: introduce the specific topic, summarize the relevant literature, identify what is still unclear or missing, and finally arrive at the aim or research question of your own project. By the end of the introduction, the reader should understand not only what you studied, but why this specific study is a logical and worthwhile next step.

Typical ingredients are:

• The broader scientific or technological context
• The specific system, phenomenon, or problem studied
• What is already known from literature
• What is unclear, missing, debated, or worth testing
• The aim or research question of the project
• A brief statement of the approach used in the report

The end of the introduction should make it clear what the report is trying to accomplish.

3.4Theory and Methods

This section explains the concepts, models, equations, computational methods, experimental methods, or analysis procedures needed to understand and reproduce the work. Depending on the project, theory and methods may be one combined section or two separate sections.

The theory part should introduce only the background needed for the report. Avoid turning it into a textbook chapter. The methods part should be concrete enough that another student or researcher can understand what was done, which assumptions were made, and which settings or parameters matter.

Useful method details can include:

• Software, codes, instruments, or datasets used
• Model systems, geometries, initial structures, or samples
• Computational settings or experimental conditions
• Definitions of calculated quantities
• Data processing and analysis steps
• Important assumptions and limitations

3.5Results and Discussion

The results and discussion section is the core of the report. It should present the findings and explain what they mean. In many BSc reports, combining results and discussion works well because each result can immediately be interpreted in context.

Do not simply place figures in sequence and describe what is visible. Each subsection should have a point. Start from the question being addressed, present the relevant evidence, interpret it, and connect it to the broader aim of the project.

For each important result, consider:

• What does the figure, table, or calculation show?
• Is the result reliable, expected, surprising, or uncertain?
• How does it compare with theory, previous work, or your hypothesis?
• What does it imply for the research question?
• What are the limitations of the result?

Figures and tables should be numbered, captioned, and discussed in the text. A reader should understand why each figure is included.

3.6Conclusion

The conclusion summarizes the main findings and answers the research question as directly as possible. It should not introduce new results, new literature, or new arguments. A good conclusion is specific: it states what was learned, under which assumptions, and with what level of confidence.

Avoid simply repeating the abstract. The conclusion can be slightly more reflective because the reader has now seen the evidence.

3.7Outlook

The outlook describes logical next steps. It can mention improvements, follow-up calculations or experiments, open questions, or extensions of the project. Keep it realistic and connected to the limitations or findings of the report.

An outlook is strongest when it follows naturally from the work:

• Which uncertainty should be reduced?
• Which method could be improved?
• Which system or condition should be studied next?
• Which result deserves deeper investigation?

3.8References

The references section lists the sources cited in the report. Every reference in the list should be cited in the text, and every in-text citation should appear in the reference list. References should be complete, consistent, and formatted according to the style agreed with your supervisor or programme.

Use references to support factual claims, methods, background context, and comparisons with previous work. Do not use references as decoration. If a statement depends on prior work, cite the source close to that statement.

3.9AI Disclosure

Every BSc final report should include an AI disclosure section. This section should be present even if no AI tools were used. If you did not use AI, state this explicitly in one short sentence, for example: "No AI tools were used in the preparation of this report."

If AI tools were used while preparing the report, include a clear and detailed disclosure according to the rules of the course, department, or university. The disclosure should explain which tools were used, for which tasks they were used, and how their output was checked.

At minimum, include:

• Which AI tools were used. Be specific: name the tool, the provider, the model, and, when possible, the version or date of use. For example, do not only write "ChatGPT was used"; write which model was used.
• For which tasks AI was used. Students often find this difficult to formulate, so be concrete. Possible examples include rewriting text, checking grammar, improving structure, brainstorming an outline, creating figure captions, creating or debugging scripts, analyzing data, finding research papers, summarizing background literature, generating plotting code, or checking whether an explanation is understandable.
• A small number of representative prompts. This is good practice. It makes the AI use more transparent and more reproducible, and it shows how the tool was instructed. Prompt engineering is a real part of working with AI tools, so examples of prompts can help the reader understand what kind of assistance was requested.

The disclosure does not need to include every single interaction, but it should give an honest and representative picture of how AI contributed to the work. If AI was used differently in different parts of the project, separate these uses clearly.

The student remains responsible for the accuracy, originality, interpretation, references, and final wording of the report. AI-generated text, citations, equations, code, and claims must be checked carefully before they are used.

4Order in which sections can best be written

The order in which the sections appear in the final report is usually not the best order in which to write them. A final report should read from broad context to specific findings and conclusions, but the writing process often works better if you start from the parts closest to the work you actually performed.

Before writing full sections, it is good practice to make a rough outline of the report. Write down which sections and subsections you expect to include, which figures or tables may belong in each part, and where the main scientific message is likely to appear. Discuss this outline with your supervisor early. This helps align expectations about structure, emphasis, level of detail, and deadlines before too much text has been written.

1. Theory and Methods. Start with the theory and methods section. This section is closest to what you did during the project and is often the easiest to write in a factual way. Writing it first forces you to clarify the technical foundation of the project: which methods were used, which assumptions were made, which settings or models matter, and which concepts the reader needs in order to understand the results.
2. Results and Discussion. Next, write the results and discussion. This is the scientific core of the report. Build this section around your figures, tables, calculations, observations, or measurements. For each result, ask what it shows, why it matters, how reliable it is, and how it connects to the research question. This section will often change while you write it. That is normal. As the results become organized, the central message of the report becomes clearer.
3. Conclusion. Once the results and discussion are in place, write the conclusion. At this stage, you know what the report can honestly claim. The conclusion should answer the research question as directly as possible and summarize the main findings without introducing new material. Writing the conclusion at this point helps you identify the actual message of the report before you polish the introduction and abstract.
4. Introduction. Write the introduction after you understand the conclusion. This may feel counterintuitive, but it usually leads to a much stronger introduction. Once you know where the report ends, you can shape the introduction as a funnel: start from the broader context, narrow down to the specific problem, identify the relevant gap or motivation, and end with the aim of the project. An introduction written too early is often too broad, too vague, or disconnected from the final results.
5. Outlook. Write the outlook after the conclusion. The outlook should follow naturally from the limitations, uncertainties, and open questions that became clear during the project. It should not be a random wish list. Good outlook points are realistic next steps that build directly on the work in the report.
6. Abstract. Write the abstract near the end. The abstract summarizes the complete report, so it should only be written once the main story is clear. If you write it too early, it often becomes generic. If you write it near the end, it can become a precise summary of the actual report.
7. Title. Choose or refine the title late in the process. The best title reflects the real emphasis of the finished report. Early titles are often too broad because the final message of the project is not yet clear.
8. References. Build the reference list throughout the writing process, but check and clean it at the end. Every source cited in the text should appear in the reference list, and every item in the reference list should be cited in the text. The final check is important because references often change while the introduction, methods, and discussion are revised.
9. AI Disclosure. Add the AI disclosure at the end, but do not forget it. Every report should include this section. If no AI tools were used, state that clearly. If AI tools were used, briefly describe how they were used and make sure the disclosure follows the relevant course, programme, or university rules.

In short: start with what you did, then explain what it means, and only then frame the story around it. The final report should read from context to conclusion, but the writing process works best from evidence outward.

5Scope and level of detail

One of the hardest parts of writing a BSc report is choosing the right level of detail. Students often move between two extremes. Either they explain too little because the supervisor already knows the project, or they explain too much because they try to prove that they studied everything. A good report avoids both problems.

Write for an informed reader who was not involved in the project. This reader may understand the general field, but does not know your exact choices, files, settings, failed attempts, or interpretation. Explain enough for such a reader to follow the scientific story and assess the work.

In the main text, include material that is needed to understand:

• The research question and motivation
• The methods, models, assumptions, or experimental setup
• The main results and how they were obtained
• The interpretation and limitations of the results
• The evidence behind the conclusions

Avoid adding background material only because it is interesting. Avoid long textbook-style explanations unless they directly help the reader understand your project. If a derivation, validation plot, long table, or technical detail is useful but interrupts the story, it may belong in an appendix instead of the main text.

When in doubt, ask your supervisor what level of detail is expected. Different fields and supervisors have different norms. Some projects require detailed computational settings, while others require more emphasis on experimental uncertainty, synthesis conditions, derivations, or data analysis.

6Writing style and paragraph structure

Clear writing is not decoration. It is part of scientific communication. A reader should not have to work hard to find the point of a paragraph or the connection between two sections.

A useful paragraph usually has one main idea. Start with a sentence that tells the reader what the paragraph is about, then provide the explanation, evidence, or consequence. Avoid paragraphs that combine background, methods, results, and interpretation all at once. If a paragraph becomes very long, it probably contains more than one idea.

Good report writing is direct and specific:

• Prefer concrete statements over vague claims.
• Avoid overclaiming beyond what the results support.
• Use technical terms consistently.
• Use signposting sentences when moving from one part of the argument to another.
• Remove sentences that do not help the reader understand the project.
• Keep the subject of a sentence clear, especially when discussing mechanisms, models, or calculations.

Be careful with words such as "clearly", "obviously", "significant", "optimal", and "proves". These words can be useful, but they often hide missing evidence. If a result is significant, explain in what sense. If something is optimal, state the criterion. If something is clear, make sure the reader can see why.

Before submitting, read a few paragraphs aloud or slowly on screen. Ask: what is the point of this paragraph, and does every sentence support that point? This simple check catches many weak transitions, vague claims, and overloaded paragraphs.

7Figures

Figures often carry the main scientific evidence. A good figure is not just a picture of your data; it is a carefully designed argument. It should help the reader see the result, understand the conditions under which it was obtained, and connect it to the claim you make in the text.

Assume that many readers will look at the figures before reading the full surrounding text. This does not mean that the text is unimportant, but it does mean that figures and captions need to work hard. A reader should be able to understand the essential message of a figure without hunting through several paragraphs for basic information.

7.1What good figures look like

Good figures are clear, honest, and purposeful. Before including a figure, ask what role it plays in the report. Does it support a conclusion? Compare two cases? Show a trend? Demonstrate convergence? Reveal a structure, mechanism, spectrum, distribution, or error? If the figure does not serve a clear purpose, consider removing it or moving it to supporting material if that is allowed.

A strong figure usually has:

• A clear message. The reader should be able to tell what the figure is meant to show.
• Readable labels. Axis labels, legends, tick labels, annotations, and panel labels should remain readable at the size used in the report.
• Units and quantities. Axes and color bars should include physical quantities and units where relevant.
• Appropriate scales. Linear, logarithmic, normalized, or relative scales should be chosen deliberately and explained when needed.
• Visible data. Lines, markers, error bars, spectra, structures, or images should be visually distinct and not hidden by clutter.
• Consistent styling. Similar quantities should be plotted in similar ways across the report.
• Informative captions. The caption should explain what is shown, the key conditions or parameters, and the main takeaway.
• A link to the text. The text should refer to the figure and explain why it matters.

7.2Captions matter

Captions are often read during scanning. Treat them as part of the scientific explanation, not as an afterthought. A good caption should make the figure understandable and useful.

For many figures, a caption should include:

• What is shown
• Which system, sample, model, molecule, material, dataset, or calculation is used
• The relevant conditions, parameters, or settings
• The meaning of colors, symbols, lines, panels, or annotations
• The main observation or conclusion, if this is not obvious
• The source or adaptation note if the figure is reused or modified from another source

Avoid captions that merely repeat the axis labels, such as "Energy as a function of time." A better caption explains what the reader should learn from the figure.

7.3Common mistakes and how to avoid them

Many weak figures fail for predictable reasons. Check for these before submitting:

• Text is too small. Increase font sizes and export the figure at the final report size. A figure that looks readable on your screen may become unreadable in the PDF.
• Axes are missing labels or units. Always label plotted quantities and include units where applicable.
• The legend is unclear. Use meaningful labels, not file names or internal variable names. Avoid legends that overlap with data.
• Too much is plotted at once. Split the figure into panels, simplify the comparison, or move secondary data elsewhere.
• Colors are hard to distinguish. Use colorblind-friendly palettes and do not rely on color alone when line styles, markers, or labels can help.
• The scale hides the message. Choose axis limits and scales that show the relevant behavior without exaggerating or hiding important features.
• The figure is not discussed. Every important figure should be referenced in the text and connected to the argument.
• The caption is too vague. State enough context that the figure can be understood during scanning.
• Figures are inconsistent. Use consistent fonts, line widths, colors, notation, and units across related figures.
• Image quality is poor. Export plots as vector graphics when possible, or use sufficiently high-resolution raster images for photographs, microscopy, rendered structures, or heat maps.
• Uncertainty is hidden. If uncertainty, variation, convergence, or numerical error matters, show it or discuss it.
• Decorative effects distract. Avoid unnecessary 3D effects, heavy shadows, excessive grid lines, and visual styling that does not improve understanding.

7.4A final figure check

Before submission, print the report or view the PDF at the size at which it will likely be read. Then check each figure quickly:

• Can the figure be understood in less than a minute?
• Is the main message visible without zooming in?
• Are all labels, legends, and units readable?
• Does the caption explain enough context?
• Is the figure discussed in the text?
• Does the figure support a specific claim in the report?
• Are reused or adapted figures properly cited?

If a figure fails this check, improve it before polishing the surrounding paragraph. In many reports, a better figure will improve the report more than another half-page of explanation.

8Tables

Tables are useful when the reader needs exact values, comparisons across several cases, or a compact overview of settings, parameters, or results. Use a table when precise numbers matter. Use a figure when the trend, pattern, distribution, or comparison is more important than the exact value.

A good table should be readable without forcing the reader to decode raw output. It should have a clear caption, meaningful column headings, units, consistent notation, and sensible rounding. In many scientific styles, a table caption is placed above the table, in contrast to a figure caption, which is usually placed below the figure. Do not copy a table directly from a spreadsheet or program output without polishing it.

Common table mistakes include:

• Too many digits. Do not report more significant figures than the method supports. Excess digits make the table harder to read and suggest false precision.
• Missing units. Units should appear in column headings or in the caption, not scattered through the body of the table.
• Unclear column names. Avoid internal variable names, file names, or abbreviations that only make sense to you.
• Inconsistent rounding. Comparable values should usually use the same number of decimal places.
• Too much data. If a table is too large for the main text, summarize the important values and move the full table to an appendix if needed.
• No connection to the text. Important tables should be introduced and interpreted in the report, not simply placed between paragraphs.

Before submitting, check whether each table has a clear purpose. The reader should know what comparison the table enables and which values matter most.

9Numbers, units, and significant figures

Numerical values should be reported with care. A number in a report is not just copied output; it is a scientific statement. The reader should understand what quantity is reported, which units are used, how precise the value is, and whether the number supports the conclusion being drawn.

Use units consistently. Write units in table headings, axis labels, captions, and text wherever they are needed to interpret a value. Be careful when converting units, normalizing data, or comparing values from different sources. If a quantity is dimensionless, make that clear when ambiguity is possible.

Do not report more digits than are meaningful. Computer programs often print many decimal places, but this does not mean all of them are scientifically justified. Excess digits suggest false precision and make tables and text harder to read. Choose a sensible number of significant figures based on the method, uncertainty, and purpose of the value.

When uncertainty matters, show it or discuss it. Depending on the project, this could mean error bars, standard deviations, confidence intervals, convergence thresholds, experimental uncertainty, numerical precision, or a qualitative statement about reliability. A result without any discussion of uncertainty can look more certain than it really is.

Common mistakes include:

• Copying raw numerical output directly into the report
• Reporting too many decimal places
• Mixing units or unit conventions without explanation
• Comparing values with different levels of precision as if they were equally certain
• Omitting uncertainty when it affects the interpretation
• Using percentages, normalized values, or relative changes without explaining the reference value

Before submitting, check every important number. Ask whether the unit is clear, the number of digits is sensible, and the reader can understand what the value means.

10Equations

Equations can make a report more precise, but only when they are used carefully. A good equation should help the reader understand a model, definition, method, assumption, or result. It should not be included only because it looks scientific. If an equation appears in the report, the reader should understand why it is there and how it is used.

For formatting physical quantities, units, and symbols, use established conventions. A good starting point is the IUPAC Green Book, Quantities, Units and Symbols in Physical Chemistry , and IUPAC's guidance on italic and roman fonts for symbols in scientific text . The most important rule for most student reports is simple: variables and physical quantities are written in italic, while labels, words, chemical identifiers, and units are written upright.

For example, in an equation, a variable such as time \(t\), temperature \(T\), pressure \(p\), or concentration \(c\) should be italic. A label that identifies a species, method, state, or condition should normally be upright. This distinction matters because italic symbols represent quantities that can take values, while upright labels identify what the quantity refers to.

Common formatting mistakes include:

• Writing labels in italic. A label such as "cat", "ref", "gas", "max", or a chemical species name is usually not a variable and should not be treated as one.
• Writing variables upright. Actual variables and physical quantities should be italic.
• Mixing units into equations incorrectly. Units should be upright and should not be treated as variables.
• Using differential operators incorrectly. The differential operator \(\mathrm{d}\) in expressions such as \(\mathrm{d}x\) or \(\mathrm{d}E/\mathrm{d}x\) should be upright, not italic, because it is an operator rather than a variable. Use the partial derivative symbol, for example \(\partial E/\partial x\), when the quantity depends on multiple variables and only one is varied. Do not mix ordinary and partial derivatives unless the distinction is intentional.
• Using computer-style scientific notation in text. Output such as 1.3E-5 or 1.3e-5 may be acceptable in raw data files or scripts, but it looks unfinished in a report. In polished text, write this as scientific notation, for example \(1.3 \times 10^{-5}\), with units included where relevant.
• Using inconsistent symbols. Do not use \(E\) for energy in one section and \(U\) for the same quantity elsewhere unless the distinction is intentional and explained.
• Using the same symbol for different quantities. Avoid reusing the same symbol for unrelated quantities unless the context is completely clear.
• Leaving symbols undefined. Every variable in an equation should be defined when it first appears.
• Introducing equations without context. Explain what the equation represents before or after showing it.
• Referring to equations vaguely. Number important equations and refer to them explicitly when needed.

Always define the variables in an equation. A reader should not have to guess what a symbol means, which units are used, or whether a subscript is a variable index or a label. A short sentence after the equation is often enough:

"Here, \(E\) is the total energy, \(E_\mathrm{ref}\) is the reference energy, and \(n\) is the number of adsorbed molecules."

In this example, \(E\) and \(n\) are variables, while the subscript \(\mathrm{ref}\) is a label and should be upright. If a subscript is itself a variable or index, it should be italic. This small typographic distinction can prevent ambiguity.

For reports with many symbols, a list of variables or symbols near the start of the document can be helpful. Such a list may include the symbol, meaning, unit, and perhaps the first equation where it appears. However, this is not equally common in every field or every type of BSc report. Ask your supervisor whether a variables list is expected, useful, or unnecessary for your project.

Before submitting, check each equation:

• Is the equation needed for the report?
• Is every symbol defined?
• Are variables italic and labels upright?
• Are units correct and written upright?
• Is the notation consistent with the rest of the report?
• Is the equation introduced or explained in the text?
• Is the equation used later, or is it only decorative?

A well-written equation should reduce confusion. If an equation makes the report harder to follow, either explain it better, simplify the notation, or remove it.

11Citing sources and managing references

References are not decoration. They show where ideas, methods, data, figures, definitions, and factual claims come from. They allow the reader to check your sources, they give credit to the people whose work you build on, and they help distinguish your own contribution from existing knowledge.

At minimum, a reference should contain enough information for the reader to find the source unambiguously. For a journal article, this usually means authors, title, journal, year, volume, pages or article number, and DOI. For a book, include authors or editors, title, edition if relevant, publisher, year, and DOI or ISBN if available. For a website, include the author or organization, page title, URL, and access date. A minimal reference is not necessarily a short reference; it is a reference that contains all information needed to identify the source reliably.

Referencing is closely connected to academic integrity. If you use an idea, result, figure, method, or formulation from someone else without making that clear, this can become plagiarism. Plagiarism is about presenting someone else's intellectual work as if it were your own. Copyright is related but different: it concerns the legal right to copy, distribute, or adapt protected material. A figure can be properly cited but still not be legal to reproduce without permission. Conversely, a source may be legally reusable but still needs citation if it influenced your work. In a scientific report, you should care about both: give credit and respect usage rights.

In practice, cite sources close to the statement they support. Do not collect references only at the end of a paragraph if several different claims rely on different sources. Avoid citing sources you have not read yourself. If you rely on a review article, cite the review for the review's synthesis, but cite the original paper when you discuss a specific original result or method. Use a consistent citation style throughout the report.

Reference managers can save a lot of time and prevent many mistakes. They help store papers, generate bibliographies, insert citations, and keep formatting consistent. Free options include Zotero and Mendeley . If you write in LaTeX, BibTeX or BibLaTeX files are especially useful because they let you manage references as structured entries and generate the bibliography automatically. Even if you use Word or another editor, using a reference manager is usually better than manually typing and retyping reference lists.

Before submitting the report, do a final reference check:

• Is every in-text citation present in the reference list?
• Is every item in the reference list cited in the text?
• Are DOIs, journal names, years, and page numbers correct?
• Are figure sources and adapted figures clearly indicated?
• Is the citation style consistent?
• Are web sources stable, relevant, and provided with an access date?

12Data, code, and reproducibility

A report should make the work understandable, but it should also make the work traceable. This is especially important for projects involving calculations, scripts, simulations, data processing, or automated analysis. A reader does not necessarily need every raw file in the main text, but they should be able to understand what data and code were used and how the results were produced.

This is part of open science and research data management. Open science does not simply mean putting files online. It means making research as transparent, reusable, and verifiable as is appropriate for the project. Research data management is the practical side of this: deciding what data exist, where they are stored, how they are documented, who can access them, how long they should be kept, and under which conditions they can be shared.

Include enough information to make the workflow reproducible at the level expected for the project. Useful details may include:

• Software names and versions
• Input files, model systems, structures, datasets, or experimental data sources
• Important parameters, thresholds, convergence criteria, or settings
• Scripts or notebooks used for analysis and plotting
• Random seeds or initialization choices if they affect the result
• Data processing steps, filtering criteria, and unit conversions
• Where the relevant files are stored, if this is appropriate and allowed

Do not rely on file names that only make sense on your own computer. Names such as final2_new_reallyfinal.py or plot_test.xlsx do not help a reader or a future version of yourself. Use clear names, keep related files together, and make sure the report describes the actual workflow used to generate the final results.

Research data and code are often stored differently. Data are usually preserved in a research data repository or institutional storage system, with metadata, a persistent identifier such as a DOI when appropriate, and clear access conditions. Code is often developed in a version-control system such as Git, because code changes over time and benefits from commit history, issues, branches, and release tags. For publication or archiving, a stable release of code can also be deposited in a repository, but day-to-day code development and long-term data preservation are not the same task.

Repositories such as Zenodo and 4TU.ResearchData can be useful for publishing or archiving research outputs and datasets. Zenodo is a general-purpose open research repository, while 4TU.ResearchData is especially relevant for technical and scientific research data. These repositories can help make datasets citable and findable, but they are not a substitute for good documentation. A dataset without clear filenames, metadata, units, scripts, or explanation may be technically available but still difficult to reuse.

Always align with your supervisor on accepted standards for the research group. Some data may belong to a larger project, may not be ready for public release, may contain confidential information, or may need to be stored in a specific institutional system. Ask where the final data, scripts, notebooks, input files, and figures should be stored, what should be shared publicly, and what should remain internal.

If code or data are shared in a repository, archive, appendix, or group folder, mention this clearly. If data cannot be shared because it is confidential, unpublished, very large, or restricted, explain what can be shared and what cannot. Discuss expectations with your supervisor, especially when the project belongs to a larger research effort.

13Appendices and supplementary material

Appendices are useful for material that supports the report but would interrupt the main story. They are not a place to hide essential results. The main text should contain the information needed to understand and assess the project. Appendices should contain additional detail for readers who want to inspect the work more deeply.

Good appendix material may include:

• Longer derivations
• Additional validation or convergence tests
• Extended tables
• Extra figures that support but do not drive the main argument
• Detailed computational settings or experimental protocols
• Additional spectra, structures, fits, or raw comparisons
• Code snippets or file inventories, if appropriate

Refer to appendices from the main text when they are relevant. Do not assume the reader will search through them without guidance. For example, write that additional convergence tests are shown in Appendix A, or that the full set of fitted parameters is given in Appendix B.

Ask your supervisor whether appendices or supplementary files are expected. Some programmes have strict rules about what counts toward page limits or assessment, and different fields have different habits.

14Revision and feedback workflow

A good report usually emerges through revision, not through one perfect writing pass. Plan time for feedback and rewriting. A supervisor can give much better feedback on a clear outline, a polished figure set, or a readable draft than on a last-minute document filled with unresolved notes.

A useful workflow is:

1. Discuss a rough outline and expected sections.
2. Prepare the main figures, tables, and results.
3. Write methods and results while the work is still fresh.
4. Send a focused partial draft if your supervisor agrees.
5. Revise the structure before polishing sentences.
6. Send a full draft with enough time for meaningful feedback.
7. Apply feedback carefully and check the final document yourself.

When asking for feedback, make the request easy to answer. Tell your supervisor what kind of feedback you need: structure, scientific interpretation, missing references, figure quality, or language. Do not ask for detailed feedback on a draft that you have not proofread yourself. Basic spelling, broken references, missing captions, and unfinished placeholders distract from the scientific feedback you actually need.

When receiving feedback, separate major comments from small edits. First address structure, missing analysis, incorrect claims, unclear figures, and weak conclusions. Then handle wording, formatting, and small consistency issues. Do not accept every suggested wording blindly; make sure the revised text still says what you mean.

15What makes a good report

A good report is not only correct; it is also easy to read, easy to navigate, and easy to assess. This matters more than many students realize. Supervisors and assessors typically do not read every written word with equal attention from beginning to end. They often scan through the report first: they look at the structure, read the abstract and conclusion, inspect the figures, check whether the methods are clear, and then zoom in on the parts that matter most for judging the work.

Use this knowledge. A report that helps a busy academic understand and assess your work is a stronger report. Clear structure, informative section titles, polished figures, and strong captions are not cosmetic details. They help the reader find what they are looking for and form an accurate impression of the quality of the work. Academics are busy, and if you help them do a good job in reviewing and assessing your report, they will usually reward that effort, either consciously or subconsciously.

This does not mean the report should be superficial. A cursory first glance is often how a reviewer or supervisor orients themselves before reading selected parts in more detail. Your report should still be thorough where thoroughness is needed: in the methods, in the interpretation of results, in the discussion of limitations, and in the support for your conclusions. At the same time, avoid writing a textbook-level treatise unless your supervisor explicitly asked for one. Excessive background material or unnecessary derivations can become lost effort if they do not help the reader assess your project.

Before submitting, check whether a reader can quickly see the following:

• What the project is about. The title, abstract, introduction, and conclusion should make the topic, motivation, and main outcome clear without forcing the reader to reconstruct the story.
• Why the work matters. The introduction should explain the broader context, the specific problem, and the reason this project was worth doing.
• What was actually done. The theory and methods should give enough information for the reader to understand the approach, assumptions, settings, materials, calculations, or experiments.
• What the main results are. The results should not be hidden in long paragraphs. Important findings should be visible through clear figures, tables, subsection titles, and direct topic sentences.
• Whether the figures can stand on their own. Each important figure should be polished, readable, and accompanied by a caption that explains what is shown, what conditions or parameters were used, and what conclusion the reader should take from it.
• How the results are interpreted. A good report does not only show results; it explains what they mean, how reliable they are, what limitations apply, and how they connect to the research question.
• What can and cannot be concluded. The conclusion should be honest, specific, and limited to claims supported by the work in the report.
• Where information can be found. A clear structure with meaningful section and subsection titles helps scanning readers navigate the report efficiently.
• Which work is yours and which work comes from others. References, figure credits, reused methods, and AI assistance should be transparent.
• Whether the report has been cared for. Consistent formatting, correct references, readable figures, clean captions, and careful language all signal that the student took the work seriously.

A useful test is to imagine that your supervisor has only ten minutes before a meeting. Can they understand the main message by reading the abstract and conclusion, scanning the headings, and looking at the figures and captions? If not, the report probably needs clearer structure, stronger captions, or a more direct scientific storyline.

16On the use of AI

AI tools are new, powerful, and still changing rapidly. Students should learn to use them well, because they can be genuinely helpful in scientific work. At the same time, AI tools are not authorities. They can produce fluent text that is wrong, invent references, miss important nuance, misunderstand your project, or make your writing sound more confident than the evidence allows. The best use of AI is therefore not to replace your own thinking, but to improve the quality of your thinking, writing, and checking.

Treat AI as an assistant, not as an author. You remain responsible for the report: the scientific claims, the interpretation, the references, the code, the figures, the calculations, and the final wording. If something in the report is wrong, "the AI suggested it" is not a valid excuse.

16.1Choosing an AI tool

Not all AI tools are the same. Some models are better at writing, some are better at coding, some are better at mathematical reasoning, and some are better at working with long documents. Some tools are free, while others require a paid subscription or are provided through the university. At TU/e, students may have access to institutionally supported tools such as Copilot. When such tools are available, they are often a sensible first choice, especially when university rules, data protection, or access conditions matter.

Students should explore different tools and learn which ones work well for their own workflow. This does not mean blindly chasing the newest model. It means comparing tools carefully: does the output help you think more clearly, does it preserve scientific meaning, does it handle technical details reliably, and can you verify what it produced?

Also remember that prompts are not perfectly portable. A prompt that works well for one model may work poorly for another. Different models may need different amounts of context, different levels of explicit instruction, or different follow-up questions. If you change tools, test your prompts again. Do not assume that the same prompt produces equivalent quality, style, or reliability across models.

16.2Good ways to use AI

AI can be especially useful when it helps you move from vague thoughts to clearer work. Examples include:

• Planning and structure. Ask AI to help create a report outline, identify missing sections, suggest a logical order for arguments, or check whether a section has a clear purpose.
• Improving explanations. Ask whether a paragraph is understandable for the intended reader, whether a transition is clear, or whether a technical explanation contains hidden assumptions.
• Language and style. Ask for grammar corrections, shorter sentences, more direct wording, or a more formal academic tone. Always check that the meaning has not changed.
• Figures and captions. Ask whether a caption explains what is shown, which conditions apply, and what message the reader should take from the figure.
• Coding support. Use AI to help write, debug, or refactor scripts, but test the code yourself and understand what it does before using the output.
• Critical review. Ask AI to act as a skeptical reader: what is unclear, what claims need evidence, what alternative explanation might exist, or where the argument jumps too quickly.
• Learning concepts. Ask for explanations of unfamiliar methods or concepts, then verify the explanation with course material, textbooks, papers, or your supervisor.

This kind of use can be very productive because it keeps you in control. You provide the scientific direction, and the AI helps you inspect, clarify, or improve the work.

16.3Risky ways to use AI

Some uses of AI are risky and should be avoided or treated with great caution:

• Do not ask AI to write large parts of the report and submit the result as if it were your own work.
• Do not cite papers, equations, values, or claims suggested by AI unless you have checked them in reliable sources.
• Do not use AI-generated references without verifying that the sources actually exist and say what the AI claims they say.
• Do not paste confidential, unpublished, personal, or sensitive project data into external AI tools unless you are sure this is allowed.
• Do not use AI to hide weak understanding. If you cannot explain a paragraph, equation, script, or figure in your own words, it should not be in your report.
• Do not let AI make the report generic. A BSc report should reflect the specific project, the actual choices made, and the real results obtained.

The most dangerous AI output is often not obviously bad. It may sound polished and plausible while being subtly wrong. This is why verification is not optional.

16.4A practical workflow

A useful workflow is to use AI in small, inspectable steps:

1. Write your own rough version first, even if it is incomplete.
2. Ask AI for a specific improvement, such as making a paragraph clearer, finding missing logic, or suggesting a better caption.
3. Compare the suggestion with your original text.
4. Keep only changes you understand and agree with.
5. Check all factual claims, references, equations, code, and numerical values independently.
6. Record representative prompts and outputs for the AI disclosure section.

Specific prompts usually work better than broad prompts. For example, instead of asking "write my introduction", ask "does this introduction move from broad context to the specific research question?" or "which sentences in this paragraph are vague and need a reference?" This keeps the tool focused on feedback rather than authorship.

End every AI-assisted step by reading the result yourself. You are the author, and you will be held responsible for the content of the report. Fact-check claims, verify references, inspect equations, test code, and make sure the final wording says what you actually mean. Be extremely critical: AI output can be useful, but it should never pass into the report without your own judgement.

17Preventing procrastination and writing blocks

Not every student likes writing. That is normal. Some students enjoy the experiments, calculations, coding, or analysis much more than the act of turning the work into text. However, the report will not become easier if writing is postponed until the end. Writing is part of the project, not a separate administrative task after the project is finished.

The most important instruction is simple: start before you feel ready. You do not need the perfect first sentence, the perfect structure, or the perfect explanation before opening the document. Often the first useful step is simply to type a rough sentence. Once a sentence exists, your mind is no longer facing an empty page. It has something to react to, improve, continue, or reject. One sentence can lead to the next, and after a few minutes the problem often changes from "I do not know how to start" to "this paragraph needs to be made clearer." That is a much easier problem.

Use small, concrete writing tasks. Do not begin a session with the vague goal "write the report." Begin with a task that can be completed in 20 or 30 minutes:

• Write three rough sentences explaining what one figure shows.
• Write a bullet list of the methods used in one calculation or experiment.
• Draft one paragraph that starts with "The purpose of this section is..."
• Rewrite one unclear caption.
• Add missing units, labels, or references to one subsection.
• Write a deliberately imperfect version of the conclusion.

The first version is allowed to be bad. In fact, it probably will be. That is not failure; that is how writing works. A rough paragraph gives you material to edit. An empty page gives you almost nothing. Do not confuse writing with polishing. First create text, then improve it.

If you are blocked, lower the difficulty of the next action. Instead of trying to write a full section, write the answer to one question:

• What did I do?
• Why did I do it?
• What does this figure show?
• What result surprised me?
• Which assumption matters most?
• What can I conclude without overclaiming?

These answers can later become paragraphs. Scientific writing often grows from clear answers to simple questions.

AI tools can help with writing blocks when they are used as a Socratic tutor rather than as a replacement author. In this mode, the AI should ask questions, help you clarify your thinking, and reflect your own ideas back to you. For example, you can ask:

"Act as a Socratic writing tutor. Ask me one question at a time to help me draft a paragraph explaining this result. Do not write the paragraph for me until I have answered several questions."

This kind of dialogue can help you start writing because it turns a blank page into a conversation. You can answer the AI in rough language, notes, fragments, or bullet points. After a few exchanges, you will often have enough material to write a first paragraph yourself. You may then ask the AI to point out missing logic, vague claims, or places where evidence is needed.

Be careful to stay in control. AI can help you get moving, but it should not decide what your report says. Do not accept text that you do not understand, cannot verify, or would not be able to explain to your supervisor. Use AI to ask better questions, find the next sentence, or test whether your explanation is clear. The scientific judgement must remain yours.

Supervisors can also help prevent writing blocks by asking for small intermediate products: an outline, a figure with a caption, a methods subsection, or a one-page summary of the main results. Students should not wait until they have a full draft before asking whether the structure makes sense. A small piece of writing, shared early, is often enough to make the next piece easier.

If writing feels difficult, do not interpret that as evidence that you are bad at it. Writing is difficult because it forces you to organize the project clearly. That difficulty is useful. Start small, write imperfectly, revise deliberately, and keep moving.

18Final remarks

Writing a BSc final report is not only a matter of filling the expected sections. It is the process of turning a project into a clear scientific account: what question was asked, how it was approached, what evidence was obtained, what can be concluded, and where the limits of the work lie. A strong report helps the reader follow that account without guessing what was done or why it matters.

Do not aim for a report that sounds impressive at the expense of being understandable. Aim for a report that is precise, honest, well structured, and easy to assess. Use the introduction to prepare the reader, the methods to make the work traceable, the results and discussion to build the argument, and the conclusion to state the answer as clearly as the evidence allows. Figures, tables, equations, references, appendices, and AI disclosures all serve the same purpose: they help the reader understand and trust the work.

The final stage of writing is therefore not only polishing sentences. It is checking whether the report does its job. Can a reader quickly see the main message? Are the most important claims supported by evidence? Are the limitations visible? Are the figures readable? Are the references complete? Is it clear what work was yours and what came from other sources or tools?

If the answer to these questions is yes, the report is doing what it should do. It presents the project in a form that others can read, evaluate, and build on. That is the real goal of a BSc final report: not to make the work look larger than it was, but to make its actual contribution clear.