diff --git a/Makefile b/Makefile
index bc93650..9f355f7 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,4 @@
-documents = interim.pdf
+documents = interim.pdf final.pdf
 
 .PHONY: all clean cleanaux spell
 
diff --git a/final.tex b/final.tex
new file mode 100644
index 0000000..9b46de4
--- /dev/null
+++ b/final.tex
@@ -0,0 +1,82 @@
+\documentclass[a4paper, twoside]{report}
+
+\input{report/packages.tex}
+
+\title{A Deeper Dive into Relational Algebra by Way of Adjunctions}
+\author{Matteo Bongiovanni}
+\date{January 2023}
+\supervisor{Dr.\ Nicolas Wu}
+\secondmarker{Dr.\ Steffen van Bakel}
+\documenttype{MEng Individual Project}
+\university{Imperial College London}
+\department{Department of Computing}
+\degree{Joint Mathematics and Computing}
+
+\begin{document}
+\begin{comment}
+General Information
+The project report (occasionally referred to as a thesis) is an extremely important aspect of the project. It serves to show what you have achieved and should demonstrate that:
+
+You understand the wider context of computing by relating your choice of project, and the approach you take, to existing products or research.
+You can apply the theoretical and practical techniques taught in the course to the problem you are addressing and that you understand their relevance to the wider world of computing.
+You are capable of objectively criticising your own work and making constructive suggestions for improvements or further work based on your experiences so far.
+As a computing professional, you operate ethically and can explain your thinking and working processes clearly and concisely to third parties who may not be experts in the field in which you are working.
+Most of the project assessors will not have followed the project throughout and will only have a short time to listen to a presentation or see a demonstration. For this reason they will rely heavily on the report to judge the project.
+
+Many students underestimate the importance of the report and make the mistake of thinking that top marks can be achieved simply for producing a good product. This is fundamentally not the case and many projects have been graded well below their potential because of an indifferent or poor write-up. In order to get the balance right you should consider that the aim of the project is to produce a good report and that software, hardware, theory etc. that you developed during the project are merely a means to this end. Don't make the mistake of leaving the write-up to the last minute. Ideally you should produce the bulk of the report as you go along and use the last week or two to bring it together into a coherent document.
+
+It is helpful to get feedback from your supervisor about your project report, but supervisors cannot be expected to look at documents written at the last minute or at more than one chapter at a time. Allow plenty of time for this.
+
+Project Report Length
+The nominal maximum report length is 60 pages, plus appendices. Shorter reports may be appropriate for many projects and longer reports can be submitted with prior approval (see below).
+
+The page count includes:
+
+title page
+abstract
+dedications
+table of contents
+The page count does not include:
+
+bibliography
+appendices (but the report should make sense without the appendices)
+When writing up your work be reminded of the fact that a 60-page report isn't necessarily better than a 30-page report, in the same way that a 10,000 line implementation isn't necessarily better 5,000 line one. Conciseness, clarity and elegance are invaluable qualities in report writing, just as they are in programming. Indeed, you will lose credit if it is evident to the assessors that the report has been padded with superfluous content in order to make it appear more substantial than the work justifies. The assessors greatly value quality over quantity.
+
+It is important to understand that the report is assessed on the quality of the technical writing. Here this means your ability to document your ideas, design, implementation, evaluation, conclusions etc. succinctly, using appropriate scientific language, as might a researcher when writing up their findings in an technical magazine, academic journal or conference proceedings.
+
+If you have good reason to use more than 60 pages you should consult your supervisor and second marker and obtain their approval in advance - they will be required to read and assess the whole report, whereas other assessment team members may only scan key sections.
+
+Project Layout
+The physical layout and formatting of the report is also important. A tidy, well laid out and consistently formatted document makes for easier reading and is suggestive of a careful and professional attitude towards its preparation. Both LaTeX and MS Word will allow you to produce a cleanly formatted document. Many supervisors will advise you to use LaTeX as this solves most of the formatting problems for you. If your report is to contain a substantial number of mathematical formulae you are strongly advised to use LaTeX.
+
+Project Report Structure
+The exact structure of your project (the chapter titles etc) is up to you. Discuss with your supervisor what structure works best for your project.
+
+A project report will usually contain a number of chapters (Chapter 1, Chapter 2 etc). Each chapter contains Sections (2.1, 2.2 etc) and may also contain subsections (2.1.1, 2.1.2) etc. Try to avoid too many levels of subheading - three is usually sufficient.
+
+Projects will usually contain all of the following elements, although these may not exactly map to chapters.
+\end{comment}
+
+% Front matter
+\include{report/title/title}
+\include{report/title/abstract}
+\begin{comment}
+Table of contents:
+This should list the main chapters, sections and subsections of your report. Choose self-explanatory chapter and section titles and use double spacing for clarity. If possible you should include page numbers indicating where each chapter/section begins. 
+\end{comment}
+\tableofcontents
+
+% Main matter 
+\include{report/introduction/final}
+\include{report/background/final}
+\include{report/project/project}
+\include{report/evaluation/evaluation}
+\include{report/ethics/final}
+\include{report/conclusion/conclusion}
+
+% Back matter
+\bibliographystyle{unsrtnat}
+% DoC uses the Vancouver Referencing Format.
+\bibliography{report/bibs/combined}
+
+\end{document}
\ No newline at end of file
diff --git a/interim.tex b/interim.tex
index e8147eb..6ff0554 100644
--- a/interim.tex
+++ b/interim.tex
@@ -1,28 +1,6 @@
 \documentclass[a4paper, twoside]{report}
 
-%% Language and font encodings
-\usepackage[english]{babel}
-\usepackage[utf8x]{inputenc}
-\usepackage[T1]{fontenc}
-\usepackage{mathrsfs}
-
-%% Sets page size and margins
-\usepackage[a4paper,top=3cm,bottom=2cm,left=3cm,right=3cm,marginparwidth=1.75cm]{geometry}
-
-\usepackage{amsmath}
-\usepackage{amsthm}
-\usepackage{graphicx}
-\usepackage[]{listings}
-\usepackage[colorinlistoftodos]{todonotes}
-\usepackage[colorlinks=true, allcolors=blue]{hyperref}
-\usepackage{comment}
-\usepackage[numbers]{natbib}
-\usepackage{fancyref}
-
-\usepackage{report/title/titlestructure}
-
-%% Utils
-\usepackage{report/background/utils}
+\input{report/packages.tex}
 
 \title{A Deeper Dive into Relational Algebra by Way of Adjunctions}
 \author{Matteo Bongiovanni}
@@ -35,12 +13,6 @@
 \degree{Joint Mathematics and Computing}
 
 \begin{document}
-\input{report/title/title.tex}
-
-\begin{abstract}
-In their distinguished paper ``Relational Algebra by Way of Adjunctions''\cite{RelationalAlgebraByWayOfAdjunctions} it was noted that the monadic structure of bulk types can help explain most of relational algebra. It was found that some operations, such as selections and projections, are more easily reasoned about; this paper completes the rigorous mathematical description of others such as relational join or grouping. The paper takes the novel stance of having a more broad view of adjunctions when dealing with the bulk types in order to make this extension. A theoretically more efficient implementation of joins is an immediate consequence of this approach and the first goal of the project is to benchmark the differences. The project can also be taken into the direction of using this reasoning to mathematically explain other known database query optimisations and potentially invent others.
-\end{abstract}
-
 \begin{comment}
 The aim of the project interim report is multi-fold:
 
@@ -60,18 +32,21 @@
 If you need inspiration, take a look at the Distinguished Projects from previous years, focusing in particular at this stage on the introduction, background and evaluation sections.
 \end{comment}
 
+% Front matter
+\include{report/title/title}
+\include{report/title/abstract}
 \tableofcontents
-\listoffigures
-\listoftables
 
-\input{report/introduction/introduction.tex}
-\input{report/background/background.tex}
-\input{report/project/projectplan.tex}
-\input{report/evaluation/evaluationplan.tex}
-\input{report/ethics/ethicalissues.tex}
+% Main matter 
+\include{report/introduction/interim}
+\include{report/background/interim}
+\include{report/project/projectplan}
+\include{report/evaluation/evaluationplan}
+\include{report/ethics/interim}
 
+% Back matter
 \bibliographystyle{unsrtnat}
 % DoC uses the Vancouver Referencing Format.
-\bibliography{report/bibs/interim}
+\bibliography{report/bibs/combined}
 
 \end{document}
\ No newline at end of file
diff --git a/report/appendix/appendices.tex b/report/appendix/appendices.tex
new file mode 100644
index 0000000..a2ff5dd
--- /dev/null
+++ b/report/appendix/appendices.tex
@@ -0,0 +1,5 @@
+\begin{comment}
+The appendices contain information which is peripheral to the main body of the report. Information typically included are things like parts of the code, tables, proofs, test cases or any other material which would break up the theme of the text if it appeared in the main body of the text. 
+
+Label these as Appendix A, Appendix B etc and refer to the appropriate appendix from the main body of the report.
+\end{comment}
\ No newline at end of file
diff --git a/report/appendix/userguide.tex b/report/appendix/userguide.tex
new file mode 100644
index 0000000..d8153aa
--- /dev/null
+++ b/report/appendix/userguide.tex
@@ -0,0 +1,12 @@
+\begin{comment}
+User Guide Appendix
+It is not common to provide a user guide in the report. This can be included in the repo you submit for the software archive.
+
+If you do feel that you should supply a user guide (e.g. for projects which result in a new piece of software), you might choose to provide a user guide providing easily understood instructions on how to use it.
+
+A particularly useful approach is to treat the user guide as a walk-through of a typical session, or set of sessions, which collectively display all the features of your system.
+
+Technical details of how the package works should be in the body of the report. Keep this concise and simple.
+
+The use of diagrams illustrating the package in action prove particularly helpful.
+\end{comment}
\ No newline at end of file
diff --git a/report/background/background.tex b/report/background/background.tex
index 45cfa50..2716515 100644
--- a/report/background/background.tex
+++ b/report/background/background.tex
@@ -1,24 +1,3 @@
-\chapter{Background} % 10-20 pages
-\begin{comment}
-This should form the bulk of the interim report. You should consider that your objective here is to produce a near final version of the background section, as it will appear in your final report.  All of this material should be re-usable, so it is worth getting it right at this stage of the project.  The details of what to include can be found in the Project Report guidelines.
-
-From the Project Report guidelines:
-The background section of the report should set the project into context by relating it to existing published work which you read at the start of the project when your approach and methods were being considered. There are usually many ways of solving a given problem, and you shouldn't just pick one at random. Describe and evaluate as many alternative approaches as possible. The published work may be in the form of research papers found in the academic literature, articles, text books, technical manuals, or even existing software or hardware of which you have had hands-on experience. You must acknowledge the sources of your inspiration. You are expected to have seen and thought about other people's ideas; your contribution will be putting them into practice in some other context. However, avoid plagiarism: if you take another person's work as your own and do not cite your sources of information/inspiration you are being dishonest. When referring to other pieces of work, cite the sources where they are referred to or used, rather than just listing them at the end. Accidental plagiarism or not knowing how to cite and reference is not a valid reason for plagiarism. Make sure you read and digest the Department's plagiarism document .
-
-In writing the Background chapter you must demonstrate your ability to *analyse*, *synthesise* and *apply critical* judgement. Analysis is shown by explaining how the proposed solution operates in your own words as well as its benefits and consequences. Synthesis is shown through the organisation of your Related Work section and through identifying and generalising common aspects across different solutions. Critical judgement is shown by discussing the limitations of the solutions proposed both in terms of their disadvantages and limits of applicability.
-
-Typically you can look for Background work using different search engines including:
-* Google Scholar
-* IEEExplore
-* ACM Digital Library
-* Citeseer
-* Science Direct
-
-**Note 1:** Often the terms *Background, Literature Review, Related Work* and *State of the Art* are used interchangeably.
-**Note 2**: Keyword search is wonderful, but you need the right *Keywords*.
-**Note 3:** IEEExplore, ACM Digital Library and Science Direct may require you to be on the College network to download the PDF versions of papers. If at home, use VPN.
-\end{comment}
-
 In this chapter we will first introduce the mathematical concepts used in the construction of relational algebra in \cite{RelationalAlgebraByWayOfAdjunctions} as discrete topics in order to introduce some intuition and context. We will then use all that we covered to explore the evolution of the mathematical descriptions of database systems. Finally, an overview of other academic research used in this project's contributed will be presented.
 
 \input{report/background/categorytheory.tex}
diff --git a/report/background/final.tex b/report/background/final.tex
new file mode 100644
index 0000000..fb9ab4c
--- /dev/null
+++ b/report/background/final.tex
@@ -0,0 +1,17 @@
+\chapter{Background}
+\begin{comment}
+The background section of the report should set the project into context by relating it to existing published work which you read at the start of the project when your approach and methods were being considered. There are usually many ways of solving a given problem, and you shouldn't just pick one at random. Describe and evaluate as many alternative approaches as possible. The published work may be in the form of research papers found in the academic literature, articles, text books, technical manuals, or even existing software or hardware of which you have had hands-on experience. Your must acknowledge the sources of your inspiration. You are expected to have seen and thought about other people's ideas; your contribution will be putting them into practice in some other context. However, avoid plagiarism: if you take another person's work as your own and do not cite your sources of information/inspiration you are being dishonest. When referring to other pieces of work, cite the sources where they are referred to or used, rather than just listing them at the end. Accidental plagiarism or not knowing how to cite and reference is not a valid reason for plagiarism. Make sure you read and digest the Department's plagiarism document .
+
+In writing the Background chapter you must demonstrate your ability to analyse, synthesise and apply critical judgement. Analysis is shown by explaining how the proposed solution operates in your own words as well as its benefits and consequences. Synthesis is shown through the organisation of your Related Work section and through identifying and generalising common aspects across different solutions. Critical judgement is shown by discussing the limitations of the solutions proposed both in terms of their disadvantages and limits of applicability.
+
+Typically you can look for Background work using different search engines including:
+
+Google Scholar
+IEEExplore
+ACM Digital Library
+Citeseer
+Science Direct
+Note 1: Often the terms Background, Literature Review, Related Work and State of the Art are used interchangeably.
+Note 2: Keyword search is wonderful, but you need the right Keywords.
+Note 2: IEEExplore, ACM Digital Library and Science Direct may require you to be on the College network to download the PDF versions of papers. If at home, use VPN.
+\end{comment}
\ No newline at end of file
diff --git a/report/background/interim.tex b/report/background/interim.tex
new file mode 100644
index 0000000..1658b56
--- /dev/null
+++ b/report/background/interim.tex
@@ -0,0 +1,22 @@
+\chapter{Background} % 10-20 pages
+\begin{comment}
+This should form the bulk of the interim report. You should consider that your objective here is to produce a near final version of the background section, as it will appear in your final report.  All of this material should be re-usable, so it is worth getting it right at this stage of the project.  The details of what to include can be found in the Project Report guidelines.
+
+From the Project Report guidelines:
+The background section of the report should set the project into context by relating it to existing published work which you read at the start of the project when your approach and methods were being considered. There are usually many ways of solving a given problem, and you shouldn't just pick one at random. Describe and evaluate as many alternative approaches as possible. The published work may be in the form of research papers found in the academic literature, articles, text books, technical manuals, or even existing software or hardware of which you have had hands-on experience. You must acknowledge the sources of your inspiration. You are expected to have seen and thought about other people's ideas; your contribution will be putting them into practice in some other context. However, avoid plagiarism: if you take another person's work as your own and do not cite your sources of information/inspiration you are being dishonest. When referring to other pieces of work, cite the sources where they are referred to or used, rather than just listing them at the end. Accidental plagiarism or not knowing how to cite and reference is not a valid reason for plagiarism. Make sure you read and digest the Department's plagiarism document .
+
+In writing the Background chapter you must demonstrate your ability to *analyse*, *synthesise* and *apply critical* judgement. Analysis is shown by explaining how the proposed solution operates in your own words as well as its benefits and consequences. Synthesis is shown through the organisation of your Related Work section and through identifying and generalising common aspects across different solutions. Critical judgement is shown by discussing the limitations of the solutions proposed both in terms of their disadvantages and limits of applicability.
+
+Typically you can look for Background work using different search engines including:
+* Google Scholar
+* IEEExplore
+* ACM Digital Library
+* Citeseer
+* Science Direct
+
+**Note 1:** Often the terms *Background, Literature Review, Related Work* and *State of the Art* are used interchangeably.
+**Note 2**: Keyword search is wonderful, but you need the right *Keywords*.
+**Note 3:** IEEExplore, ACM Digital Library and Science Direct may require you to be on the College network to download the PDF versions of papers. If at home, use VPN.
+\end{comment}
+
+\input{report/background/background.tex}
\ No newline at end of file
diff --git a/report/background/utils.sty b/report/background/utils.sty
index 27db914..716d2c4 100644
--- a/report/background/utils.sty
+++ b/report/background/utils.sty
@@ -1,3 +1,4 @@
+\ProvidesPackage{utils}
 % Categories
 \newcommand{\cat}[1]{\ensuremath{\mathscr{#1}}}
 \newcommand{\objs}[1]{\ensuremath{\mathrm{Ob}_{\cat{#1}}}}
diff --git a/report/bibs/interim.bib b/report/bibs/combined.bib
similarity index 100%
rename from report/bibs/interim.bib
rename to report/bibs/combined.bib
diff --git a/report/bibs/instructions.txt b/report/bibs/instructions.txt
new file mode 100644
index 0000000..fb0046d
--- /dev/null
+++ b/report/bibs/instructions.txt
@@ -0,0 +1,16 @@
+This consists of a list of all the books, articles, manuals etc. used in the project and referred to in the report. You should provide enough information to allow the reader to find the source. In particular references must contain all the information regarding the publication of the paper and must be consistently formatted. Usually this means:
+
+For journals: Authors, Title, Journal, volume number, issue number, page number, publisher, month, year.
+For conferences: Authors, Title, Conference name, Place where held, publisher, page number, month, year.
+For technical reports: Authors, Title, institution, Technical report number, month, year.
+For web references: Authors, Title, Web-reference, date accessed.
+URLs and DOIs are optional for published work but preferred.
+A weakness of many reports is inadequate citation of a source of information. It's easy to get this right so there are no excuses. Each entry in the bibliography should list the author(s) and title of the piece of work and should give full details of where it can be found. For example:
+
+[5] Kiss, C., Field, A.J., Eisenbach, S. and Peyton Jones, S., Higher-order Type-level Programming in Haskell, Proc. 24th ACM SIGPLAN International Conference on Functional Programming (ICFP 2019), Berlin, July 2019. pp 102:1-102:26. 
+
+Using a reference management programme can make your life simpler (but it is still important to know how to reference manually). See for example Bibdesk , JabRef , RefWorks, etc.
+
+The Department usually uses the Vancouver referencing format.
+
+A student supplied biblatex style for Vancouver Referencing is available on Piazza.
\ No newline at end of file
diff --git a/report/conclusion/conclusion.tex b/report/conclusion/conclusion.tex
index 3533e97..0ff27e5 100644
--- a/report/conclusion/conclusion.tex
+++ b/report/conclusion/conclusion.tex
@@ -1 +1,5 @@
-\chapter{Conclusion}
\ No newline at end of file
+\chapter{Conclusion}
+\begin{comment}
+Conclusions and Future Work
+The project's conclusions should sumarise the key insights that have been gained, be they positive or negative. For example, "The use of overloading in C++ provides a very elegant mechanism for transparent parallelisation of sequential programs", or "The overheads of linear-time n-body algorithms makes them computationally less efficient than O(n log n) algorithms for systems with less than 100000 particles". Avoid tedious personal reflections like "I learned a lot about C++ programming...". It is common to finish the report by listing ways in which the project can be taken further. This might, for example, be a plan for doing the project better if you could do a re-run, turning the project deliverables into a more polished end product, or extending the project into a programme for an MPhil or PhD.
+\end{comment}
\ No newline at end of file
diff --git a/report/ethics/ethicalissues.tex b/report/ethics/ethicalissues.tex
index 16ea1b6..be9c010 100644
--- a/report/ethics/ethicalissues.tex
+++ b/report/ethics/ethicalissues.tex
@@ -1,7 +1,3 @@
-\chapter{Ethical issues} % 1-2 pages
-\begin{comment}
-What are the wider ethical, legal, professional and societal issues surrounding your project and the accompanying research? You should use the ethics checklist as the basis for this discussion. 
-\end{comment}
 The project itself (in its early stages) does not have a novel ideal as a useable output and thus is very neutral in its ethical impact. Instead it has the ability to recommend or withhold recommendation of an earlier approach to database optimisations via implementation and benchmarking results, and in its final stages may recommend further optimisations and so the more interesting ethical discussion is around the ethics of database optimisations.
 
 Databases are a necessity for most modern applications. Furthermore, database optimisations are especially important for large, scaling products or services. This means that improving this area of computer science has a very indiscriminate effect on the type of software products that can make use of it. Of course, just as any private company could make use of the newer more efficient techniques, any military hosting a database could too. It is also worth noting the implementation is in a functional programming language, a rising paradigm \todo{cite} typically associated with reliability \todo{add another quality} \todo{Add citation for this} which aligns very well with the real-time and safety critical nature of military applications. \todo{cite that these are important for military applications}
diff --git a/report/ethics/final.tex b/report/ethics/final.tex
new file mode 100644
index 0000000..7993171
--- /dev/null
+++ b/report/ethics/final.tex
@@ -0,0 +1,4 @@
+\chapter{Ethical Issues}
+\begin{comment}
+You are required to include a short discussion of ethical, legal, societal and professional issues that are relevant to your project (usually 1 to 2 pages long). This should fit in the most appropriate section of your project report, often the Background or Conclusions section.
+\end{comment}
\ No newline at end of file
diff --git a/report/ethics/interim.tex b/report/ethics/interim.tex
new file mode 100644
index 0000000..2a66604
--- /dev/null
+++ b/report/ethics/interim.tex
@@ -0,0 +1,5 @@
+\chapter{Ethical issues} % 1-2 pages
+\begin{comment}
+What are the wider ethical, legal, professional and societal issues surrounding your project and the accompanying research? You should use the ethics checklist as the basis for this discussion. 
+\end{comment}
+\input{report/ethics/ethicalissues.tex}
\ No newline at end of file
diff --git a/report/evaluation/evaluation.tex b/report/evaluation/evaluation.tex
index 120676c..b449e9b 100644
--- a/report/evaluation/evaluation.tex
+++ b/report/evaluation/evaluation.tex
@@ -1 +1,4 @@
-\chapter{Evaluation}
\ No newline at end of file
+\chapter{Evaluation}
+\begin{comment}
+Be warned that many projects fall down through poor evaluation. Simply building a system and documenting its design and functionality is not enough to gain top marks. It is extremely important that you evaluate what you have done both in absolute terms and in comparison with the state of the art. This might involve quantitative evaluation, for example based on numerical results, performance etc. or something more qualitative such as expressibility, functionality, ease-of-use etc., possible with respect to a target user base. The evaluation, often coupled with a discussion of future work (see below), should make clear the strengths and weaknesses of what you have done. It is important to understand that there is no such thing as a perfect project. Even the very best pieces of work have their limitations, so you are expected to provide a proper critical appraisal.
+\end{comment}
\ No newline at end of file
diff --git a/report/introduction/final.tex b/report/introduction/final.tex
new file mode 100644
index 0000000..6a78143
--- /dev/null
+++ b/report/introduction/final.tex
@@ -0,0 +1,4 @@
+\chapter{Introduction}
+\begin{comment}
+The introduction should summarise the subject area, the specific problem you are addressing, including key ideas for their solution, together with a summary of the project's main contributions. When detailing the contributions it is helpful to provide forward references to the section(s) of the report that provide the relevant technical details. The introduction should be aimed at an informed, but otherwise non-expert, reader. A good tip is to assume that all your assessors will read the abstract and introduction, whereas the more detailed technical sections may only be read by your first and second markers - it's therefore really important to get it right.
+\end{comment}
\ No newline at end of file
diff --git a/report/introduction/interim.tex b/report/introduction/interim.tex
new file mode 100644
index 0000000..68e7005
--- /dev/null
+++ b/report/introduction/interim.tex
@@ -0,0 +1,5 @@
+\chapter{Introduction} % 1-3 pages
+\begin{comment}
+It’s a good idea to *try* to write the introduction to your final report early on in the project. However, you will find it hard, as you won’t yet have a complete story and you won’t know what your main contributions are going to be. However, the exercise is useful as it will tell you what you *don’t* yet know and thus what questions your project should aim to answer. For the interim report this section should be a short, succinct, summary of the project’s main objectives. Some of this material may be re-usable in your final report, but the chances are that your final introduction will be quite different.  You are therefore advised to keep this part of the interim report short, focusing on the following questions: What is the problem, why is it interesting and what’s your main idea for solving it?  (DON'T use those three questions as subheadings however!  The answers should emerge from what you write.)
+\end{comment}
+\input{report/introduction/introduction.tex}
\ No newline at end of file
diff --git a/report/introduction/introduction.tex b/report/introduction/introduction.tex
index 1541d04..28aa805 100644
--- a/report/introduction/introduction.tex
+++ b/report/introduction/introduction.tex
@@ -1,8 +1,3 @@
-\chapter{Introduction} % 1-3 pages
-\begin{comment}
-It’s a good idea to *try* to write the introduction to your final report early on in the project. However, you will find it hard, as you won’t yet have a complete story and you won’t know what your main contributions are going to be. However, the exercise is useful as it will tell you what you *don’t* yet know and thus what questions your project should aim to answer. For the interim report this section should be a short, succinct, summary of the project’s main objectives. Some of this material may be re-usable in your final report, but the chances are that your final introduction will be quite different.  You are therefore advised to keep this part of the interim report short, focusing on the following questions: What is the problem, why is it interesting and what’s your main idea for solving it?  (DON'T use those three questions as subheadings however!  The answers should emerge from what you write.)
-\end{comment}
-
 Databases are vital to modern day society for their ability to structure, sort and query vast amounts of data from any domain, ranging from specialised images of eyes \todo{add citation here} to crystal structure \cite{CambridgeStructuralDatabase}. Of course no one theoretical model of data has surfaced since its conception, with different approaches describing how exactly to hold the data. Examples of such data models include the semi-structured model \cite{DatabaseSystems} and, more relevant to this project, the relational model \cite{RelationalModel} as introduced in \fref{sec:relationalmodel}.
 
 The relational model has rich support for the expression of queries and is by no means not varied across its use. Two examples of its family of query representations are \emph{relational calculus} and \emph{relational algebra} with their various advantages \cite{RelationalCalculus,RelationalModel}. \todo{they are equivalent though?} However, the favoured specification of queries for the authors of \cite{RelationalAlgebraByWayOfAdjunctions} seemed to be list comprehensions, a beautiful feature that ``provide for a concise and expressive notation for writing list-processing code''. \cite{MonadComprehensions} They eventually propose using GHC's extended list comprehension syntax in a way to help bridge the already close relationship between relational calculus and list comprehensions \cite{GHCListComprehension,ComprehensiveComprehensions}. Such a method is required in order to avoid the significant theoretical performance hit when working with equijoins.
diff --git a/report/packages.tex b/report/packages.tex
new file mode 100644
index 0000000..ff69c66
--- /dev/null
+++ b/report/packages.tex
@@ -0,0 +1,23 @@
+%% Language and font encodings
+\usepackage[english]{babel}
+\usepackage[utf8x]{inputenc}
+\usepackage[T1]{fontenc}
+\usepackage{mathrsfs}
+
+%% Sets page size and margins
+\usepackage[a4paper,top=3cm,bottom=2cm,left=3cm,right=3cm,marginparwidth=1.75cm]{geometry}
+
+\usepackage{amsmath}
+\usepackage{amsthm}
+\usepackage{graphicx}
+\usepackage[]{listings}
+\usepackage[colorinlistoftodos]{todonotes}
+\usepackage[colorlinks=true, allcolors=blue]{hyperref}
+\usepackage{comment}
+\usepackage[numbers]{natbib}
+\usepackage{fancyref}
+
+\usepackage{report/title/titlestructure}
+
+%% Utils
+\usepackage{report/background/utils}
\ No newline at end of file
diff --git a/report/project/project.tex b/report/project/project.tex
index c2dbbd5..b591e3f 100644
--- a/report/project/project.tex
+++ b/report/project/project.tex
@@ -1 +1,5 @@
-\chapter{PROJECT X}
\ No newline at end of file
+\chapter{Project}
+\todo{change chapter name}
+\begin{comment}
+The central part of the report usually consists of three or four chapters detailing the technical work undertaken during the project. The structure of these chapters is highly project dependent. They can reflect the chronological development of the project, e.g. requirements, design, implementation, experimentation, optimisation, evaluation etc. although this is not always the best approach. However you choose to structure this part of the report, you should make it clear how you arrived at your chosen approach in preference to the other alternatives documented in the background. If you have built a new piece of software you should describe and justify your design and details any interesting problems with, or features of, your implementation. Integration and testing are also important to discuss in some cases. You need to discuss the content of these sections thoroughly with your supervisor.
+\end{comment}
\ No newline at end of file
diff --git a/report/title/abstract.tex b/report/title/abstract.tex
new file mode 100644
index 0000000..191fa70
--- /dev/null
+++ b/report/title/abstract.tex
@@ -0,0 +1,8 @@
+\begin{comment}
+The abstract is a very brief summary of the report's contents. It should be no more than half a page long. Somebody unfamiliar with your project should have a good idea of what it's about having read the abstract alone and will know whether it will be of interest to them. Note that the abstract is a summary of the entire project including its conclusions. A common mistake is to provide only introductory elements in the abstract without saying what has been achieved.
+\end{comment}
+
+
+\begin{abstract}
+In their distinguished paper ``Relational Algebra by Way of Adjunctions''\cite{RelationalAlgebraByWayOfAdjunctions} it was noted that the monadic structure of bulk types can help explain most of relational algebra. It was found that some operations, such as selections and projections, are more easily reasoned about; this paper completes the rigorous mathematical description of others such as relational join or grouping. The paper takes the novel stance of having a more broad view of adjunctions when dealing with the bulk types in order to make this extension. A theoretically more efficient implementation of joins is an immediate consequence of this approach and the first goal of the project is to benchmark the differences. The project can also be taken into the direction of using this reasoning to mathematically explain other known database query optimisations and potentially invent others.
+\end{abstract}
\ No newline at end of file
diff --git a/report/title/acknowledgements.tex b/report/title/acknowledgements.tex
new file mode 100644
index 0000000..d265e26
--- /dev/null
+++ b/report/title/acknowledgements.tex
@@ -0,0 +1,3 @@
+\begin{comment}
+It is usual to thank those individuals who have provided particularly useful assistance, technical or otherwise, during your project. Your supervisor will obviously be pleased to be acknowledged as they will have invested quite a lot of time into overseeing your progress and supporting you.
+\end{comment}
\ No newline at end of file
diff --git a/report/title/title.tex b/report/title/title.tex
index 36e2cda..121bbc9 100644
--- a/report/title/title.tex
+++ b/report/title/title.tex
@@ -1,3 +1,7 @@
+\begin{comment}
+This should include the project title and the name of the author of the report. You can also list the name of your supervisor if you wish. 
+\end{comment}
+
 \begin{titlepage}
 
 \newcommand{\HRule}{\rule{\linewidth}{0.5mm}} % Defines a new command for the horizontal lines, change thickness here