Chapter 1 — Advanced research integrity and methods
Lesson map
Lesson 01 published. Map, example, EX001.
flowchart TD
N0["Learning outcomes"]
N1["1.1 The opening case"]
N2["1.2 The research question"]
N3["1.3 Integrity with operational data"]
N4["1.4 Choosing methods"]
N5["1.5 Reproducibility from the start"]
N6["1.6 Grounding in sources"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX001"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["1.1 The opening case"]
N2["1.2 The research question"]
N3["1.3 Integrity with operational data"]
N4["1.4 Choosing methods"]
N5["1.5 Reproducibility from the start"]
N6["1.6 Grounding in sources"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX001"]
[Learning outcomes]
|
v
[1.1 The opening case]
|
v
[1.2 The research question]
|
v
[1.3 Integrity with operational data]
|
v
[1.4 Choosing methods]
|
v
[1.5 Reproducibility from the start]
|
v
[1.6 Grounding in sources]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX001]
Learning outcomes
You will (1) frame a doctoral question about cloud and container configuration risk; (2) apply research integrity to studies using operational data; (3) choose methods that fit the question; (4) plan for reproducibility from the start.
1.1 The opening case
Amara Okoye is a doctoral candidate at the fictional Thornfield University, supervised by Prof. Henrik Lund. Her industry partner, the fictional Meridian Health Cloud, runs about forty Kubernetes clusters for clinical scheduling services. A review the year before found a log-collection workload running as privileged with host filesystem access for eleven months; the daily configuration scan had reported it, but the report was one line among hundreds. Amara asks whether checking configurations at admission, before workloads start, shortens the time risky configurations stay live compared with daily scanning.
1.2 The research question
A doctoral question must be specific, answerable and new. Amara's working form: "In managed Kubernetes clusters, does admission-time enforcement of Pod Security Standards reduce the exposure window of risky workload configurations, compared with daily scanning, without unacceptable deployment failures?" Each phrase sets a boundary: managed clusters, a named standard, a measurable outcome and a cost that must also be measured.
The last clause matters as much as the first. Prof. Lund's first question was what result would count as no effect, and Amara wrote it down before any data: a median difference under two hours, or an interval including zero. The cost half has its own threshold, a rejection rate no higher than 5% of deployments after the first fortnight.
1.3 Integrity with operational data
Configuration and audit data come from a partner's production systems. Amara agrees in writing what may be collected (configuration metadata and timestamps, never patient data or secrets), how it is stored and who sees it. The university ethics board reviews the plan because staff behaviour is indirectly observed through deployment records.
The written agreement names the exports Amara receives: pod specifications with secrets removed, audit-log timestamps and namespace names, nothing from inside the workloads. Because Meridian runs health services, the agreement also states that any patient data found by mistake is deleted at once and reported to Meridian's data protection officer, not analysed.
1.4 Choosing methods
The question compares two control designs, so it needs measurement of the same outcome under each, with attention to confounders: teams that adopt admission control early may already be more careful. Amara plans a stepped rollout across clusters, which gives comparison periods without withholding the control from anyone permanently.
A stepped rollout also helps with time. Because clusters switch one step a month, a general improvement across Meridian, such as teams getting better at writing pod specifications, would affect clusters still on scanning as much as those already switched. Comparing them in the same calendar months separates that trend from the control's effect, which the examiners later asked about.
1.5 Reproducibility from the start
Every analysis will be a script under version control, every dataset a synthetic or de-identified export with a hash, and every decision a dated note. Most of the course's labs rebuild small, synthetic versions of these steps so that readers can repeat them.
In practice, that means the generator for synthetic audit logs is written early, alongside the measurement script, rather than at the end for the archive. Every figure in the thesis is produced by a script that can run on those synthetic files, so an examiner without access to Meridian can still check that the method produces what the thesis reports.
1.6 Grounding in sources
NIST SP 800-190 describes container risks and countermeasures, including limiting privileges; the Kubernetes Pod Security Standards define Privileged, Baseline and Restricted profiles; Burns et al. (2016) describe how Kubernetes grew from Google's Borg and Omega, which explains why configuration is declarative and checkable before workloads run.
Each source sets a boundary for the study. SP 800-190 justifies treating privileged containers as risky; the Pod Security Standards supply a public definition of "risky" that others can check; and the declarative design Burns et al. describe is why admission-time enforcement is possible at all: a pod specification can be evaluated before anything runs.
Worked example
Amara's first supervision meeting produces a one-page plan: question, outcome (hours between a risky configuration becoming live and being removed or blocked), comparison (daily scan versus admission enforcement), cost measure (deployment rejections and override requests), data rules and an archive plan. Prof. Lund asks her to state now what result would count as no effect; she writes "a median difference under two hours or an interval including zero".
Synthetic case. Thornfield University, Meridian Health Cloud, people and data are synthetic.
Errors and limits
Defining "no effect" after seeing results invites bias; write it down first.
Exercises
- EX001 — Question parts. Which boundaries does Amara's question set? Rubric: 3 = clusters, standard, outcome, cost; 2 = three; 1 = one; 0 = none.
- EX002 — Opening finding. What did the earlier review find? Rubric: 3 = privileged log collector live 11 months despite scan; 2 = partial; 1 = vague; 0 = none.
- EX003 — Data agreement. What may and may not be collected? Rubric: 3 = metadata and timestamps; no patient data or secrets; 2 = partial; 1 = vague; 0 = none.
- EX004 — Ethics review. Why does the ethics board review the plan? Rubric: 3 = staff behaviour observed indirectly; 2 = partial; 1 = vague; 0 = none.
- EX005 — Stepped rollout. Why use a stepped rollout? Rubric: 3 = comparison without withholding permanently; 2 = partial; 1 = vague; 0 = none.
- EX006 — No-effect rule. How did Amara define no effect? Rubric: 3 = median difference under 2 h or interval including zero; 2 = partial; 1 = vague; 0 = none.
- EX007 — Declarative config. Why does Kubernetes' history matter here? Rubric: 3 = declarative config checkable before running; 2 = partial; 1 = vague; 0 = none.
Synthesis
A precise question, written integrity rules and early reproducibility shape the whole study.