# Chapter 22 Labs: The Capstone - Your Final Project

This chapter is the capstone of the book. Its labs are project-management and research-craft exercises, not attack-target labs. Two labs run in containers (Lab 3 and the Reproducibility Lab); three labs are host-only planning and writing exercises. The container environment provides a Jupyter server for the `22_project_dashboard.ipynb` notebook and a reproducibility demo that models what a pinned, seed-fixed artefact looks like in practice.

## Prerequisites

- Docker Desktop (or Docker Engine + Compose plugin) with at least 4 GB RAM allocated.
- Disk: approximately 2 GB for the Jupyter image; the repro-demo image builds from `python:3.12-slim` (about 150 MB).
- Labs 1, 2, and 4 need nothing beyond a text editor (or word processor); they are writing and planning exercises.
- For the Reproducibility Lab: no extra installs - the demo runs entirely inside the container.

## Quick Start

```bash
cd labs/ch22
docker compose up -d jupyter
```

Then open http://localhost:8900 in a browser. Navigate to `cyberbook/22_project_dashboard.ipynb`.

To run the reproducibility demo:

```bash
docker compose run --rm repro-demo
```

---

## Lab 1: Topic Clinic

**Host setup (not containerised)**

### Objective

Score three rough capstone ideas against the feasibility-novelty-contribution triangle, confirm data access, and convert the best idea into a single examinable research question.

### Setup

No container required. Use a text editor, spreadsheet, or a copy of `22_project_dashboard.ipynb` section 1 (scoring sheet).

### Walkthrough

1. Write three one-sentence capstone hunches drawn from chapters that interested you. Examples from the book: a detection-engineering measurement (Ch 18), a prompt-injection harness (Ch 19), an OT protocol study (Ch 20), a forensic or ATT&CK tooling artefact (Ch 6/17).

2. For each idea, score the three triangle corners on a 1-5 scale:
   - Feasibility: time, skills, compute, and confirmed data access.
   - Novelty: what does the existing literature and tool ecosystem already do?
   - Contribution: complete the sentence "if this works, then [named someone] can [specific thing]."

3. For the highest-scoring idea, run the three cheap feasibility tests:
   - Write a one-paragraph "happy path" (step-by-step from start to a finished result); mark any step that requires data, compute, or a third party's agreement.
   - Run a 30-minute focused literature and tool search to check novelty.
   - Write the single "so what?" sentence for contribution.

4. Confirm data access: name the specific dataset, API, lab device, or corpus, and state how you will obtain it and by when. If you cannot name it, this idea fails the data-access check - return to step 2 and choose another.

5. Rewrite the surviving hunch as one examinable research question naming a method, a dataset or target, a baseline or comparison, and a measurable outcome.

6. Capture the scores and the research question in the `22_project_dashboard.ipynb` scoring sheet.

### Expected Output

A completed scoring sheet with one research question that names a method, dataset, baseline, and measurable outcome, plus the first entries of your risk register.

### Verify Completion

You can state your research question to a peer in one sentence, they can name what the method is, what data is being used, and what success looks like.

### Cleanup

No containers to stop. Delete any draft files you no longer need.

---

## Lab 2: Proposal Draft Against a Generic Rubric

**Host setup (not containerised)**

### Objective

Draft a two-to-four-page research proposal using the eight standard components, self-mark it against the five-family rubric and the FHEQ Level 7 descriptor, and revise every amber and red before showing your supervisor.

### Setup

No container required. Use a word processor, markdown editor, or the text blocks in `22_project_dashboard.ipynb`.

### Walkthrough

1. Take the topic from Lab 1 and draft a two-to-four-page proposal using the eight standard components:
   - Problem statement.
   - Research question (single answerable sentence).
   - Aims and objectives (3-5 measurable, time-bounded verbs).
   - Brief literature context (3-4 key sources as a narrative, not a list).
   - Method (name datasets, baselines, and evaluation strategy).
   - Plan (a realistic schedule with milestones; use the Gantt from Lab 3 if already started).
   - Ethics (identify the ethical surface: human participants, personal data, vulnerability testing).
   - Deliverables (specific concrete artefacts).

2. Write the research question as a single answerable sentence, then list 3-5 objectives as action verbs you can tick off.

3. Name your data source explicitly and state in one line how you have confirmed access. If you cannot, change the topic now.

4. Write the one-sentence contribution: "After this project, the world will know / have ___ that it does not now." If you cannot complete it, narrow the scope until you can.

5. Self-mark the draft against the five-family rubric (clarity of problem and question, contribution and novelty, methodological soundness, feasibility and planning, ethics and professionalism), scoring each red/amber/green.

6. Check the FHEQ Level 7 descriptor (systematic understanding, originality in application, practical understanding of research, complexity and autonomy) and revise every amber and red before showing your supervisor.

### Expected Output

A two-to-four-page proposal draft with self-marked rubric scores, ready for supervisor review.

### Verify Completion

Every rubric criterion is green or you can state a specific plan to fix each amber before submission.

### Cleanup

No containers to stop.

---

## Lab 3: Gantt Chart and Risk Register

**Container: `jupyter` service**

### Objective

Build a work breakdown, a milestone-anchored Gantt chart, and a RAG-coloured risk register for your capstone project, using `22_project_dashboard.ipynb`.

### Setup

```bash
docker compose up -d jupyter
```

Open http://localhost:8900 and navigate to `cyberbook/22_project_dashboard.ipynb`.

### Walkthrough

1. Decompose the proposal (Lab 2) into a work breakdown of discrete tasks, each with a duration and dependency, grouped into the clusters from section 22.4.1: literature review, ethics and data acquisition, artefact build or study, evaluation, writing, defence.

2. Define your milestones as zero-duration checkpoints (proposal signed off, ethics approved, artefact builds end-to-end, first full draft to supervisor, submission, defence) and place them on a 6-to-9-month timeline.

3. Open the `22_project_dashboard.ipynb` notebook. In the **Gantt** section, populate the task CSV (columns: task, start_week, duration_weeks, milestone). Run the cell to render the chart with task bars, milestone diamonds, and an explicit buffer block in the final 15-20% of the schedule.

4. Build the risk register: for each identified risk record likelihood (low/medium/high), impact (low/medium/high), RAG status, owner, response (avoid/transfer/mitigate/accept), and the residual risk after the response. Common capstone risks: data access not confirmed, ethics clearance delayed, scope creep from an industry partner, undocumented environment (reproducibility risk).

5. In the **Risk** section of the notebook, populate the risk CSV and run the cell to render the RAG-coloured risk summary.

6. Carry both artefacts to your first supervision meeting as live documents - update them at every meeting, do not file them.

### Expected Output

A rendered Gantt chart with at least one milestone per project phase, an explicit buffer block, and a RAG risk register with at least five risks each carrying a response strategy and a residual risk rating.

### Verify Completion

The notebook runs end-to-end without errors. The Gantt chart shows writing overlapping with late evaluation (not sequenced after it), and at least one risk is rated amber after mitigation to show honest residual risk.

### Cleanup

```bash
docker compose stop jupyter
```

Data in the `cyberbook/` volume mount is your own repo and is not deleted.

---

## Reproducibility Lab: Make Your Capstone Repository Reproducible

**Container: `repro-demo` service**

### Objective

Practise the Sandve et al. (2013) reproducibility rules and the ACM Artifacts Available / Functional badging standard by running a pre-built minimal reproducible artefact, verifying its output hashes, and then applying the same pattern to your own capstone code.

### Setup

```bash
docker compose run --rm repro-demo
```

This builds the `repro-demo` container from `./repro-demo/Dockerfile` (first run only) and executes `repro_demo.py`. Outputs are written to `./repro-demo/outputs/`.

### Walkthrough

1. Run the demo container and note the two SHA-256 hashes it prints (one for the CSV, one for the PNG figure):

   ```
   docker compose run --rm repro-demo
   ```

2. Run it a second time. Confirm both hashes are identical. This demonstrates Sandve Rule 6 (record random seeds) and Rule 7 (store raw data behind plots).

3. Open `./repro-demo/repro_demo.py` in an editor. Change `SEED = 42` to any other integer, rebuild the image, and re-run. Observe that the hashes change. Revert to 42.

4. Inspect `./repro-demo/Dockerfile` and `./repro-demo/requirements.txt`. These demonstrate Sandve Rule 3 (archive exact versions of external programs) and the README convention from section 22.8.3.

5. Apply the same pattern to your own capstone code:
   - Initialise a git repository and commit from the first day (Sandve Rule 4).
   - Write a README to the eight-part shape: title and purpose, install, run/usage, data provenance, expected output, licence, citation, environment pin.
   - Pin your environment: generate a `requirements.txt` with exact versions, or a lockfile, plus a minimal `Dockerfile`.
   - Set and record every random seed; store raw data behind every figure.
   - Have a classmate clone your repo cold and run from the README alone. Every question they ask is a README defect.

6. If your artefact touched a real system and found a real flaw, write the disclosure note following coordinated vulnerability disclosure (ISO/IEC 29147:2018). Never publish a working exploit against a third party's live system as part of your submission.

### Expected Output

Two identical SHA-256 hashes on both runs of the demo. Your own artefact repository has a pinned `requirements.txt` (or lockfile), a `Dockerfile`, seeds set and recorded, and a README a stranger can follow.

### Verify Completion

```bash
docker compose run --rm repro-demo
```

Both hashes match the values from the first run. A peer clones your capstone repository and reproduces your headline result from the README alone without asking you any questions.

### Cleanup

```bash
docker compose down
# Optionally remove the built image:
docker image rm ch22-repro-demo 2>/dev/null || true
```

---

## Lab 4: Defence Rehearsal - Slide Deck and Mock-Viva Question Bank

**Host setup (not containerised)**

### Objective

Build a defence slide deck under the one-slide-one-idea rule, time a full dry run aloud, build a mock-viva question bank across the five question families, and rehearse with a peer or supervisor to identify the single weakest answer before the real defence.

### Setup

No container required. Use any presentation tool (PowerPoint, Keynote, Google Slides, or a plain text outline). A timer is required for the dry run.

### Walkthrough

1. Build a defence slide deck for your capstone (or a worked example) under the one-slide-one-idea rule:
   - Slide 1: Motivation (why anyone should care) - one sentence heading.
   - Slide 2: Research question or artefact goal - one sentence heading.
   - Slides 3-5: Method at a level a non-specialist can follow (2-3 slides).
   - Slides 6-9: Results with a single hero figure foremost (3-4 slides).
   - Slide 10: Honest limitations (one slide - this is a strength, not a weakness).
   - Slide 11: Contribution and next steps.
   - Every slide heading is a full assertive sentence ("Our detector cuts false positives by a third"), not a label ("Results").

2. Time a full dry run aloud against a clock - not silently in your head. A 15-minute slot means the result must arrive by minute 8. If you are still on background at minute 10, cut the background, not the results. Rehearse the 60-second oral summary of the whole project.

3. Build a mock-viva question bank: write at least three questions in each of the five families, targeted at your project's weakest joints:
   - Contribution: "In one sentence, what did this project add that did not exist before?"
   - Method: "Why this dataset/baseline/evaluation, and not the obvious alternative?"
   - Validity: "What would convince you that this result is real and not an artefact of your setup?"
   - Limitations: "Where would this break? What is the first thing you would not trust it on?"
   - Ethics: "How did you handle the data/disclosure/consent, and what would you do differently?"

4. For each question, draft a spoken answer of 2-4 sentences. For the hardest one, practise the "I don't know, but my expectation is X because Y, and I would test it by Z" form rather than a bluff.

5. Run the bank with a peer or supervisor playing the panel, to time, with no notes. Record which question exposed a gap you could not close cleanly. That gap is your highest-value remaining revision before the real defence.

### Expected Output

A slide deck, a question bank with written answers, and one line identifying the single weakest answer to fix.

### Verify Completion

You can deliver the full deck aloud in the allotted time, and you can answer every question in the bank in 2-4 sentences without notes, including the "I don't know" form for at least one question.

### Cleanup

No containers to stop.

---

## Teardown

Stop all running containers:

```bash
docker compose down -v
```

This removes containers and the named network. It does not delete your notebook or output files from the host volume mount.

---

## Safety and Authorisation Note

Chapter 22 is a project-management and research-craft chapter. No lab in this pack involves scanning, exploiting, or interacting with any real system.

The `repro-demo` container runs purely synthetic data with no real network captures and no real vulnerability information. The random values it generates are for teaching purposes only and carry no real-world security meaning.

If your actual capstone artefact involves offensive techniques (a fuzzer, a scanner, a prompt-injection harness), apply the following rules from the book:
- Only run offensive tools against the provided lab target or a system you own or have explicit written authorisation to test.
- If you discover a real vulnerability in a real system, follow coordinated vulnerability disclosure (ISO/IEC 29147:2018): report privately, give a reasonable remediation window, and coordinate any public release. Do not publish a working exploit in a public repository.
- Never run an OT fuzzer or scanner against a live operational system.
