Content overhaul.

guidelines.md

@@ -0,0 +1,45 @@
+CS Thesis Structure (Rough Estimate)
+
+| # | Section | Pages |
+|---|---------|-------|
+| — | Abstract | 1 |
+| 1 | **Introduction** — motivation, problem statement, contributions, thesis roadmap | 4–6 |
+| 2 | **Background / Related Work** — prior methods, what you build on, what you differ from | 10–15 |
+| 3 | **Method** — your actual contribution (ROLL loss, KDE formulation, gradient derivation) | 10–15 |
+| 4 | **Experiments** — datasets, baselines, setup, results tables, figures | 12–18 |
+| 5 | **Discussion** — what the results mean, failure modes, limitations | 4–6 |
+| 6 | **Conclusion** — summary, future work | 2–3 |
+| — | References | 3–6 |
+| — | Appendix (optional) — proofs, extra tables, dataset details | 0–10 |
+
+**Total: ~50–80 pages** (varies a lot by field norms and advisor preference — ML/systems theses tend toward the lower end)
+
+---
+
+A few notes for your project specifically:
+
+- **Method** will be the centerpiece — KDE formulation, the custom autograd backward pass, and how you frame the FPR-constrained objective deserve careful treatment.
+- **Background** should cover: AUC/TPR@FPR optimization literature, KDE-based losses, imbalanced classification baselines (AUROC, focal loss, etc.).
+- **Experiments** you already have a lot of infrastructure for — KEEL datasets + large datasets gives you a good breadth story.
+
+What's your advisor's expected page range, and do you have a target submission date?
+
+Claude> This is very helpful thank you.
+
+- Does page count include figures?
+- Does page count include code sections?
+- Are all proof in thesises in the appendix and only referenced inside the actual discussion section?
+<shell-maker-end-of-prompt>
+Yes, yes, and it depends:
+
+**Figures** — yes, figures count toward page count. A results-heavy ML thesis can easily have 10+ pages of figures baked into those estimates above.
+
+**Code** — short snippets (pseudocode, a key algorithm block) go inline in the Method section and count toward pages. Full implementation code goes in the appendix or is omitted entirely — reviewers don't want to read your training loop. Pseudocode is almost always preferred over real code in the main body.
+
+**Proofs** — no fixed rule, but common practice:
+- If the proof is **short and central** to understanding your contribution (e.g. showing your loss is differentiable), put it inline.
+- If it's **long or technical** but important, put it in the appendix and write "proof in Appendix A" in the main text.
+- If it's **a known result you're just citing**, skip the proof entirely and just cite the paper.
+
+For your thesis specifically: the KDE gradient derivation (the backward pass) is probably worth a compact inline treatment since it *is* the core technical contribution — but the full derivation details can go in an appendix.
+