Thesis Structure: What Goes Where

A monograph MSc thesis in Computer Engineering typically runs 70 to 100 pages of body text. Longer is not better. A tight 75-page thesis reads as confident; a padded 140-page one reads as unfiltered, and it dilutes the argument that is your actual contribution.

Page budgets below assume roughly 85 pages. Scale proportionally, and check your department's own template first — its requirements override everything here.

Front matter

Abstract, 150–250 words. The most-read part of your thesis and worth an hour per sentence. A five-sentence skeleton that works: the context and problem; why existing approaches fall short; what you did; your headline quantified result; what it implies. No citations, no undefined acronyms, and a real number in the result sentence — an abstract that says "significant improvements" wastes its most valuable position.

Write it last.

Acknowledgements — genuine and brief.

Table of contents, list of figures, list of tables — auto-generated; never hand-maintain these.

Nomenclature or list of abbreviations — worth including for an OS+AI thesis, since you are combining two vocabularies and your committee may be expert in only one of them.

Chapter 1: Introduction

The introduction does one job: convince a reader that the problem matters and tell them precisely what you claim. Most readers, including some committee members, will read this chapter, the figures, and the conclusion carefully and skim the rest. Write accordingly.

A reliable progression, roughly a paragraph or two each:

Open with context — the world in which the problem exists, at a level a general computer engineer follows. Then the problem, stated concretely and, if possible, with a number or a figure that makes it real; a small motivating measurement of your own here is very effective. Then why it is hard, which is the paragraph that separates research from engineering: the obvious solution must be shown to fail, and for a reason, or the reader assumes you simply did not think of it. Then why now — what changed: new hardware, new workloads, a newly practical technique.

Then your insight, in one or two sentences: the key idea, before any mechanism. If a reader remembers one sentence from your thesis, this is it.

Then your contributions, as an explicit bulleted list of three to five items. Make them things you did, each verifiable: "we design X", "we implement X in the Linux kernel in 2,400 lines", "we show that X reduces p99 latency by 18% across four workloads", "we characterize when X fails." Avoid contributions that are really activities — "we survey the literature" is not a contribution.

Then a results teaser: your headline numbers, right here, in the introduction. Do not make readers hunt for chapter six. And finally a short roadmap paragraph.

Write a rough version early so you know what you are aiming at, then rewrite it completely at the end. Introductions written before the results always promise a slightly different thesis than the one you produced.

Chapter 2: Background

Give the reader exactly the concepts needed to follow chapters four through six, and nothing else.

The failure mode is the textbook chapter — fifteen pages restating how virtual memory works, copied in spirit from a course. This bores expert readers and signals padding. Your committee knows what a page table is.

The test is mechanical and worth applying literally: for every concept in this chapter, find where it is used in chapters four through six. No use, no concept. Conversely, every term used later without definition needs to be here.

For an OS+AI thesis you have a specific challenge: you are writing for two audiences. Your OS-expert committee members need the ML background and your ML-adjacent readers need the OS background, and neither wants to read the half they already know. Handle it by keeping each side compact and pitched at "expert in the other field," being explicit about which subsections a reader may skip, and spending your detail budget on the intersection — the part nobody is expert in, such as why inference latency constraints in a kernel hot path are qualitatively different from those in a serving system. The intersection is where your background chapter earns its pages.

Chapter 3: Related Work

Covered in depth in guide/02-reading-system.md. The essentials: organize by theme rather than by paper, end every group with the limitation it shares that motivates your work, and include the comparison table from your literature matrix — it is usually the highest-value element in the chapter.

Close the chapter with a short positioning paragraph stating plainly how your work differs from the closest two or three papers. Be specific and be fair. Overclaiming novelty against a paper whose author is in the room is a bad outcome, and the honest version — "closest to ours is X, which differs in that it assumes Y" — is stronger anyway.

Chapter 4: Design

Your longest chapter and your intellectual core. This is where a thesis is won.

Begin with goals and non-goals. The non-goals matter as much as the goals, because they are what let you legitimately decline whole categories of criticism: "we target single-node deployments; distributed coordination is out of scope" converts an attack into a scoping decision, provided you stated it up front rather than in response to a question.

Then an overview with an architecture figure, followed by a walkthrough of the data flow end to end, in prose, following one request or one decision through the system. Readers understand systems through traces far better than through component inventories.

Then a section per mechanism — the substance. And within each one, the thing that distinguishes a design chapter from documentation: rationale, including alternatives you rejected. For each significant decision, state what you chose, what else you considered, and why you chose as you did. This is the difference between "here is what the system does" and "here is why the system must be this way," and it is what makes a reader trust that you understood the design space rather than stumbling into one point in it. It also pre-empts a large fraction of defense questions, because "why didn't you do it the other way?" is already answered in your text.

Then be explicit about correctness and safety: invariants you maintain, what happens under failure, and — critically for learned components in an OS — what happens when the model is wrong. A reader will not accept a kernel mechanism without knowing its worst case. If you have a fallback path when confidence is low, describe it here; if you do not, explain why the failure mode is tolerable.

Write this chapter as you design, in Phase 2. The rejected alternatives are the part you cannot reconstruct later, and they are the part that matters most.

Chapter 5: Implementation

Enough that a competent engineer could rebuild it, and enough that a reader can calibrate how much real work this was.

Include the software stack with exact versions, where your code hooks into the existing system (specific subsystems, functions, or extension points), lines of code broken down by component as a rough complexity signal, and the engineering problems that were genuinely hard.

That last part deserves emphasis, because students routinely omit it out of a sense that difficulties are embarrassing. They are not. A candid account of the three things that were unexpectedly hard — the lock you could not hold across the inference call, the floating point you could not use in kernel context, the memory you could not allocate in that path — is interesting, demonstrates depth, and is often the most quoted part of a thesis by the next student to attempt something similar. Constraints you discovered are findings.

Keep code listings short and rare. A ten-line snippet illustrating a key interface earns its space; a two-page function does not. Point to the repository instead.

Chapter 6: Evaluation

Structure it around questions, not around whatever you happened to run. Each section header is a question your claims-to-experiments matrix generated, and each section answers it.

Open with a methodology section that establishes credibility before any results: hardware specification, what you controlled and how, workload descriptions with a justification sentence each, how baselines were tuned, number of repetitions, and how you report variance. This is also where you answer the skeptical questions pre-emptively, and a reader who trusts your methodology reads your results generously.

Then a headline result — one figure that makes your central point, early. Then a section per claim. Then overhead, in its own section, honestly. Then ablations, showing that each component contributes. Then sensitivity, showing your result is not a single lucky parameter setting. Then where it fails — the adversarial case, reported by you.

Every figure needs a paragraph of prose that says what to look at, what the result is, and why it happens. A figure with only a caption is a figure the reader will interpret differently than you intended. The "why" is what separates evaluation from measurement, and it usually requires performance counters or profiles rather than end-to-end timings alone.

Detailed measurement methodology is in guide/06-evaluation-playbook.md.

Chapter 7: Discussion and Limitations

Counterintuitively, this chapter increases your credibility. Stating your limitations clearly signals that you understand your own work's boundaries; omitting them signals either that you have not thought about them or that you are hoping nobody notices. Committees are very good at noticing.

Cover threats to validity honestly — the limits of your hardware, your workloads, your scale, your assumptions — and for each one, say what it would take to address it. Discuss generality: where else this applies and where it does not. Reflect on what you would do differently. And offer a deployment perspective: what would actually be required to put this in production, which for kernel work usually surfaces real concerns about maintainability, debuggability, and the fact that a learned policy is much harder to reason about at 3am than a heuristic.

Do not use this chapter to apologize. Bound your claims precisely; do not undermine them. There is a real difference between "our evaluation covers single-socket systems; NUMA behavior remains open" and "our evaluation is unfortunately quite limited."

Chapter 8: Conclusion and Future Work

Restate the problem, your approach, and your results in a form that stands alone. Some readers read only this. Then a short future work section: three or four specific, concrete directions. Your cut list from Phase 0 supplies these for free.

Avoid vague gestures at "applying deep learning to other subsystems." Name the next experiment someone should run.

Figures

Budget roughly one figure or table per two to three pages, so about 30 to 40 in an 85-page thesis, weighted toward design and evaluation.

Draft your figures before writing the prose around them. Sketching the evaluation figures you intend to produce — before you have data — is a fast way to discover that a claim has no supporting experiment, and it is much cheaper to discover that with a pencil than with a compute cluster.

Every figure needs a caption that stands alone, since readers encounter figures out of order and a caption reading "Results for experiment 3" is useless. Number figures by chapter, reference every one from the text, and place each near its first reference.

Figure quality standards are in guide/06-evaluation-playbook.md.