How do you plan the writing of a Machine Learning thesis?

Before writing, clearly define what you want to communicate. Write down all ideas that contribute to that objective, group them by topic, choose a logical order (cause-effect, problem-solution), and only then start writing. Writing without planning produces confusing documents and forces you to rewrite from scratch.

How do you structure the documentation of a Machine Learning project?

A thesis or ML project documentation should include: cover page, abstract, table of contents, introduction, feasibility analysis, theoretical framework, materials and methodology, results, conclusions, and references. The most important section is Materials and Methodology, where algorithms, models, and technical decisions are described.

How do you cite sources in APA format in an AI thesis?

Citations must appear both in the text and in the References section. In the text, use the format Last Name (Year) or (Last Name, Year, p.X). The full reference at the end includes author, year, title, publisher, and location. Never assume the reader will understand an acronym without first defining it in parentheses.

/ Document ML / Write a better thesis

How to Write a Better Machine Learning Thesis

Practical writing and documentation guide for AI projects

15 min read Alan López Bachelor's · Master's · PhD

What will you find in this guide?

How to plan your writing before typing a single line
Which style mistakes ruin technical documents
How to cite sources and reference figures correctly
What goes in each section of your documentation

Knowing how to do Machine Learning is not enough if you can't communicate it.

This guide is based on real guidelines used in engineering courses. The goal is for your documentation to be clear, structured, and defensible.

Phase 1Before writing: the importance of planning

The most common mistake is not writing badly. It's writing without knowing what you want to say.

A good programmer does not start writing code without first understanding the problem. The same applies to writing: drafting a document should come after thinking about what will be written and in what order.

As the saying goes: no wind is favorable to a sailor who doesn't know which port they're heading to.

The goal of your documentation is to communicate clearly what your project is, how you developed it, and why you made the decisions you made.

How to plan content step by step

Make sure you understand the topic well. If you're unsure, research first.
Write down on a sheet the objective you want to achieve by writing that section.
Write down all the ideas that contribute to that objective.
Select only the ideas that genuinely add value.
Choose the order in which you will present them: cause–effect, problem–solution, chronological.

Only after having that mental map are you ready to start writing.

Doing this saves time and frustration. It's not bureaucracy — it's avoiding having to rewrite everything from scratch halfway through the process.

Phase 2While writing: style, clarity, and coherence

Once you know what you're going to write and in what order, it's important to do it clearly.

This is not about writing beautifully. It's about writing to be understood.

On style

Style has to do with how you group words to form sentences. Some practical rules:

The document must be clear and fluid. One sentence should lead to the next; one paragraph should lead to the next.
Long sentences are harder to understand than short ones. The longer the sentence, the greater the chance the reader loses the thread.
A sentence ideally has between 8 and 15 words. A paragraph can have up to 14 lines.
Avoid unnecessary informal language: slang and colloquialisms have no place in a technical document.

On semantics and consistent language

Semantics has to do with the meaning of words. Pragmatics with what is understood from a complete sentence.

Before writing, make sure you know exactly what each word you use means. For example: do you know the difference between effect and affect? Between its and it's?

Always use the same word to refer to the same idea.

If in one section you call a system capability a "function," don't call it an "instruction" or "command" later without reason. Using synonyms is valid to keep the text from becoming monotonous, but it should not obscure the central concept.

How to avoid run-on sentences

A run-on sentence is the most common mistake among those who write the way they speak: joining two ideas in a single sentence without a proper grammatical connection between them.

To avoid it, remember:

Do not use commas to separate ideas. If you're unsure whether to use a comma or not, make two sentences.
Use a semicolon when two ideas are so closely related that they should not be separated by a full stop.
To separate distinct ideas, use a full stop.

On abbreviations and acronyms

Never assume the reader knows an acronym.

The first time it appears in the text, write the full phrase and the acronym in parentheses:

In Object-Oriented Programming (OOP) ...

From that point on you can use the acronym freely throughout the rest of the document.

Abbreviations in general are best avoided, unless they are standard in the field.

Phase 3How to cite sources and reference elements

APA format

Citations to information sources are done in APA format.

There are two ways to cite in the text:

With emphasis on the author:

Kaku (2009) states that... (p.90)

With emphasis on the text:

"verbatim quote in quotation marks" (Kaku, 2009, p.90)

Remember: the citation must appear in the text, not only in the References section at the end. They are two different things.

References to figures, tables, and algorithms

No figure, table, or algorithm should appear in the documentation without being referenced in the text.

You are not writing a mystery novel. If you include a visual element, explain in the text what it is for and when to look at it.

Standard format:

Figures are numbered with a caption: Figure 1. Brief description.
Tables are numbered with a title: Table 1. Brief description.
Algorithms are named and their function is explained before presenting them.

Phase 4After writing: what to review

Finishing the draft is not finishing the document. You always need to revise.

Typographical errors

The font type is the same throughout the document
The text is justified
All agreed formatting guidelines are followed
The page numbers in the table of contents match the document

Spelling errors

No word is misspelled
All punctuation marks are justified
Capitalization is used correctly

Style errors

Sentences are self-contained and understandable on their own
Each paragraph adequately explains what it was meant to convey
Each section contains the information that belongs to it
All consulted sources are cited
All figures, tables, equations, and algorithms are referenced

ReferenceStructure of the project documentation

An engineering project documentation or ML thesis has well-defined sections. Here is what goes in each one.

Cover page

Its purpose is to inform quickly. Do not overload it with large or unnecessary images.

It must include:

Institution logo
Title — it must not be ambiguous; it must describe the project precisely
Names of team members
A single contact email
Updated date

Abstract

A paragraph of approximately 250 words that condenses the entire document.

It must explain the problem, the proposed methods, and the results obtained.

It is the first thing read carefully, so highlight the relevance of the project.

Write it with as little jargon as possible so that non-specialist readers can also understand it.

Provides the reader with the order of the document and page numbers to find each section.

Verify that the numbers match the final document before submitting.

Introduction

Presents the project protocol. The reader should be able to answer these questions after reading it:

What is the problem to be solved?
How has it been attempted before? What similar solutions exist?
What makes this project necessary?
What is intended to be achieved?

Do not answer the questions one by one. Write them as flowing text that answers them implicitly.

Feasibility analysis

A brief section that answers two concrete questions:

Commercial feasibility: market description, direct and indirect competitors, associated risks
Technical feasibility: can the necessary elements be obtained? Is a prototype possible? Are the skills available to execute it?

Theoretical framework

Explains the knowledge necessary to understand the Materials and Methodology section.

Include information about the components or technologies you will use, and technical context about the problem you are solving.

Do not include filler content. The goal is for the reader to understand the document, not to demonstrate how much you've read.

Materials and Methodology

This is the most important section.

Its purpose is to precisely describe every algorithm, model, system, and method implemented in the project.

It must be detailed enough for someone to reproduce your work. If it's not here, it doesn't exist.

Results

Presents the achievements obtained in the implementation.

Each result must be accompanied by metrics, figures, or tables that support it — and referenced in the text, not simply attached.

Conclusions

Describes the relevance of the results obtained and the work that remains for the future.

Do not repeat what you already said in Results. Interpret. Connect the findings with the original problem.

Appendices and Glossary

Appendices include material related to the project that is not strictly necessary to understand it: additional research, supplementary code, annexes.

The glossary defines the relevant technical terms that the reader might not know.

References

Include all consulted sources in APA format.

Remember: a source not cited in the text should not appear in References. And a source cited in the text must appear here, without exception.

Previous Document

Next Projects