Scoping: From Topic to Defensible Claim

You have a topic. A topic is not a thesis. This document gets you from one to the other, which means three things: choosing which of three fundamentally different research postures you are taking, writing a claim that could be proven false, and establishing that the claim has not already been settled by someone else.

Choosing your angle

Work at the intersection of operating systems and AI splits into three postures. They look similar from outside and are completely different to execute. Pick deliberately, because your choice determines what you must build in month one.

Angle A — AI applied to an OS problem

Replacing or augmenting a kernel heuristic with a learned component: learned page prefetching, reinforcement-learned CPU scheduling, ML-driven readahead or cache replacement, learned index structures in a filesystem, LLM-assisted configuration tuning or crash triage.

Why it appeals: the framing is clean and the story writes itself. Decades-old heuristics were tuned for hardware and workloads that no longer exist, and a learned policy adapting to the actual workload should beat a fixed rule.

The failure mode that kills these projects, stated plainly: the incumbent heuristic is not merely fast, it is nearly free. It costs a few hundred nanoseconds and no memory. Your model must beat it net of its own inference cost, memory footprint, and training cost, inside a hot path where a cache miss is a meaningful expense. A great many projects in this space produce a model with excellent offline prediction accuracy and a system that is slower end-to-end. If you take this angle, you must measure end-to-end system performance with the model in the loop from the very first week you have anything working. Offline accuracy is not a result. It is a hypothesis about a result.

Two related traps. First, the strawman baseline: comparing against an untuned default rather than a well-tuned heuristic is the criticism most likely to sink your defense. Second, evaluating on the same workload distribution you trained on, which tells you nothing about whether the policy generalizes — and generalization to unseen workloads is the entire premise of the approach.

Feasible in 6–12 months if: you keep the model tiny and the integration point narrow. A decision tree or small linear model at one well-chosen hook beats an ambitious deep architecture you cannot get into the kernel. Consider userspace-first prototyping, or eBPF-based policy injection, or sched_ext if your target is CPU scheduling — anything that avoids you spending five months on kernel plumbing.

Angle B — OS and systems support for AI workloads

Building systems mechanisms that serve AI: GPU memory management for LLM inference, KV-cache paging and eviction policies, scheduling for multi-tenant inference serving, memory tiering or offloading for models that exceed device memory, checkpoint and restore for long training jobs, batching and admission control for serving.

Why it appeals: the workloads are economically important right now, the bottlenecks are real and well-documented, and OS techniques transfer cleanly because the problems genuinely are OS problems wearing new clothes — paging, scheduling, isolation, admission control.

The failure modes here are different. You need real hardware, and you need it for extended stretches; a shared cluster where you get four-hour slots will not support careful latency measurement. Confirm your hardware access in week one, in writing, before you commit to this angle. The field also moves very fast, so there is genuine risk of being scooped mid-project — mitigate by making your contribution a mechanism or an insight rather than a raw performance number, since mechanisms survive being scooped and leaderboard positions do not. And these projects are engineering-heavy: be realistic about how much of your twelve months is systems implementation.

Feasible in 6–12 months if: you build inside an existing serving stack rather than building a serving stack. Modify vLLM or SGLang or similar; do not write your own.

Angle C — Measurement and characterization

Rigorously measuring something nobody has measured properly: how a production scheduler behaves under LLM inference workloads, where time actually goes in an inference serving stack, how existing learned-systems proposals hold up when reimplemented and evaluated fairly, what the real cost of some mechanism is at scale.

Why it appeals: it is by far the lowest-risk angle. It cannot fail to produce results, because the measurements are the results. There is no month-eight moment of discovering your idea does not work. It is also the angle most likely to actually be read and cited, because good measurement papers have long lifespans, and reproduction studies of learned systems work are genuinely valuable and genuinely scarce.

The failure mode is entirely different from A and B: it is "so what?" A pile of graphs is not a contribution. What makes a measurement thesis strong is that each finding comes with an implication — this is why the current design is wrong, this is what a system should do differently, this assumption in the literature does not hold. You must also work harder to establish novelty, since "nobody measured this" is a weaker claim than "nobody built this" and requires more thorough literature work to support.

It is also the best fallback. If you take angle A or B and the idea does not pan out, a rigorous characterization of why it does not work is a legitimate thesis. Note that this is only available to you if your Phase 1 measurement infrastructure was solid, which is one more reason to invest there.

Choosing between them

Three questions decide this in practice. What hardware do you have exclusive, extended access to — this constraint is hard and eliminates options rather than being negotiable. How comfortable are you with training, validating, and debugging models, honestly, since angle A punishes shallow ML skill. And how much risk can your program tolerate, given that a 6-month deadline with a hard submission date argues for C or a narrow B.

Fill in templates/thesis-statement-worksheet.md and bring your answer to your advisor with reasoning, not as an open question. Arriving with "I think B, narrowed to KV-cache eviction, because I have exclusive access to two A100s and I am stronger at systems than at ML" produces a far better conversation than "which should I do?"

Writing a thesis statement

A thesis statement is one sentence that could turn out to be false. That is the whole test. If no experiment could contradict it, it is a topic description.

A usable formula:

By [mechanism], [system] achieves [quantified improvement] in [metric] on [workload class] compared to [named baseline], at a cost of [honest overhead].

Some examples of the difference.

"I will investigate the use of machine learning in operating system schedulers." This is a topic. It cannot be false. Nothing follows from it.

"Machine learning improves OS scheduling." Now it is a claim, but it is unfalsifiable as stated — which ML, which scheduler, which workload, improves what?

"Replacing CFS's wakeup-placement heuristic with a decision tree trained on per-workload cache-locality features reduces p99 latency by more than 15% for latency-sensitive colocated workloads, while adding under 200ns per scheduling decision." This one is falsifiable in five distinct places, and every one of them tells you an experiment you must run. Note that the overhead bound is part of the claim rather than a caveat, which is exactly right for angle A.

Two notes on using it. Write it in week two knowing it is wrong; its job right now is to expose which assumptions you have not examined. And expect to narrow it as results arrive, because narrowing a claim to match your evidence is the single most reliable way to strengthen a thesis. Committees attack overreach far more often than they attack modest, well-supported claims.

Below the thesis statement, write two or three claims that decompose it. Each one becomes a row in your claims-to-experiments matrix and, usually, a section of your evaluation chapter. If you cannot state the experiment that would test a claim, the claim is not yet concrete enough.

Establishing the gap

Your related work chapter has to answer why this was not already done. There are three honest kinds of gap, and it helps to know which one you are claiming.

An unexplored regime. The technique exists but nobody has applied it where you are applying it, and there is a specific reason the transfer is non-obvious — different constraints, different scale, different workload characteristics. The strength of this gap depends entirely on articulating why the transfer is hard. "Nobody has tried it" is weak on its own; "prior work assumes microsecond-scale decisions and this domain requires nanosecond-scale, which rules out their approach" is strong.

An unvalidated assumption. The literature rests on a premise nobody checked, and you check it. These are excellent when you find them, and you find them by reading the evaluation sections of papers with real suspicion. Which workloads did they not test? What does "we assume" appear next to?

An unmeasured cost. Prior work reports the benefit and is quiet about the price — inference latency, memory footprint, training cost, cold-start behavior, what happens when the workload shifts. This gap is extremely common in learned-systems work and is often the most valuable thing a careful student can contribute.

Write the gap as a single paragraph now, in week two, and keep revising it. Then be honest with yourself in one specific way: search hard for the paper that already did this. Spend a deliberate afternoon trying to kill your own idea, using different vocabulary than your own (other communities name things differently), checking the last two years of the major venues, and following the citation graph forward from your core papers. Finding the killer paper in week two is a good day. Finding it in month eight is a catastrophe.

Scope discipline

The one-idea rule. A masters thesis supports one idea well. Two ideas means both are supported badly. When you notice yourself with two contributions, ask which one is the thesis and demote the other to future work.

Keep an explicit cut list. A file of good ideas you are not doing. Every interesting idea goes there rather than into the project. This is what makes saying no survivable — you are not discarding the idea, you are scheduling it for never, in writing, where you can see it. The cut list also seeds your future work section for free.

Design a fallback in week four, not month eight. Write down the answer to: if my main idea does not work, what do I submit? Usually the answer routes through angle C — the infrastructure and baselines from Phase 1 plus a rigorous characterization of why the approach fails. Knowing this exists changes how you work, because you stop treating a negative result as an existential threat and start treating it as a branch you have already mapped.

The one-page problem statement

The deliverable for Phase 0. One page, and your advisor signs off on it before you leave this phase. It contains: the problem and who has it; why it is hard, meaning why the obvious solution fails; why now, meaning what changed to make this worth doing; your thesis statement; two or three decomposed claims; the gap, in one paragraph naming the three closest papers; your fallback; and what you need to have working by week eight.

If you cannot fit this on one page, you have not finished scoping.