A Data Science or AI thesis viva needs an examiner panel that can question both the argument and the code, and most graduate schools’ standard viva-panel composition rules were written before that was a routine requirement. The direct answer: pair a methodologically strong internal examiner with an external examiner whose own research or industry background includes hands-on model-building, add a structured code-review component to the defence itself, and score both the written thesis and the accompanying codebase against a single published rubric — not two separate, informal standards.
Why a Data Science or AI viva needs a different examiner-expertise mix
A traditional viva panel composition rule — one internal examiner, one external examiner, both broadly expert in the candidate’s discipline — assumes that reading the thesis document is sufficient to assess the work. For a Data Science or AI thesis, a meaningful share of the actual research contribution lives in the codebase, not the prose: the model architecture choices, the data-preprocessing pipeline, the hyperparameter search, and whether the reported results are actually reproducible from the submitted code. An examiner panel with no member who has personally built and debugged a comparable model is not equipped to interrogate that layer of the work, regardless of how strong their statistical or theoretical background is — the same category of code-similarity and plagiarism-tool gap already documented for Computer Science departments’ tooling needs applies to examiner expertise, not just software. The fix is not adding a third examiner by default — it is being deliberate that at least one panel member, usually the external examiner, has direct hands-on model-building experience in a closely related sub-area (natural language processing, computer vision, reinforcement learning, or whichever the thesis actually uses), not just general machine-learning familiarity.
Should the code be examined as part of the viva, or separately?
Institutions handle this two ways, and both are defensible if formalised: some run the code review as a distinct, timed component within the viva itself — the candidate walks the panel through a specific part of the pipeline live, answering questions about design choices in real time, the same way they defend a methodology chapter; others require a written code-review report from a designated technical examiner submitted before the viva, with the viva itself then focused on discussing that report’s findings alongside the thesis argument. The live, in-viva approach tests a candidate’s real-time command of their own codebase more rigorously; the pre-viva written report approach is more thorough on technical detail because the reviewer has time to actually run the code, not just watch a walkthrough. Neither approach is inherently better — what matters institutionally is picking one and stating it explicitly in the examination regulations for this thesis type, rather than leaving it to be negotiated informally between the supervisor and the external examiner on a case-by-case basis.
A rubric that scores the thesis and the codebase against one standard
The most common structural failure in Data Science and AI viva assessment is running two separate, informally weighted judgements — “the writing was strong” and “the code seemed fine” — that never get reconciled into a single documented outcome. A published rubric that a panel completes during or immediately after the viva should score, as named, separately-weighted components: the research contribution and argument (is the research question well-motivated and the contribution genuinely novel); methodological soundness (is the model, evaluation metric and experimental design appropriate to the question); reproducibility (does the submitted code, given the stated environment and data, actually reproduce the reported results — this is increasingly treated as a pass/fail gate on its own, separate from methodological quality, because a result that cannot be reproduced is not evidence of anything regardless of how sound the underlying method looks on paper); and code quality and documentation (is the codebase organised, commented and usable by someone other than the candidate, which matters for institutions where the code itself may be reused or built upon). Weighting these explicitly, and publishing the weighting before the viva, removes the ambiguity that otherwise surfaces only when a panel disagrees mid-viva about how much a reproducibility gap should count against an otherwise strong thesis.
Reproducibility checks: what to actually require
A minimum, practical reproducibility bar a graduate school can require without demanding a full independent re-run of every experiment: the candidate submits a version-controlled repository (not a folder of loose scripts) with a clear environment specification (a requirements file, container definition, or equivalent), a README describing how to reproduce the headline results, and confirmation that at least the core reported figures regenerate from the submitted code and a stated data source or synthetic equivalent where the real data cannot be shared. A designated technical examiner or reviewer running this check before the viva, rather than the full panel attempting it live, is the more common and more practical institutional model — it converts reproducibility from an open question raised mid-defence into a documented pre-viva finding the panel can discuss with evidence in hand.
A template panel-and-rubric structure
| Role | Focus | Timing |
|---|---|---|
| Internal examiner | Research contribution, argument, disciplinary fit | Full viva |
| External examiner (hands-on ML/AI background) | Methodological soundness, model design choices | Full viva |
| Technical/code reviewer (may be the external examiner or a separate designated role) | Reproducibility, code quality, documentation | Pre-viva review, findings discussed in viva |
Smaller programmes without the staffing to designate a separate technical reviewer typically fold that role into the external examiner’s remit explicitly, which is why the external examiner’s own hands-on background matters more for this thesis type than for a purely theoretical one.
Common failure modes that undermine a Data Science viva
Three patterns recur when institutions apply an unmodified traditional viva format to this thesis type. First, an examiner panel selected purely on subject-area seniority rather than hands-on technical currency — a distinguished statistician with no recent hands-on deep-learning experience can misjudge a reproducibility gap as a minor issue or, conversely, treat a normal negative-results pattern in machine learning as a methodological failure. Second, reproducibility surfacing for the first time live in the viva, when a panel member happens to ask “does this actually run”, rather than as a documented pre-viva finding — this produces exactly the kind of unminuted, informal judgement call that cannot support a grading decision if later challenged. Third, no explicit institutional position on whether a candidate may use third-party pretrained models, APIs or datasets without full disclosure of their provenance and licensing terms, which is a genuinely different disclosure question from the plagiarism and citation norms a traditional viva panel is trained to look for — a foundation model’s training data provenance and a dataset’s licence terms need their own disclosure standard, not an assumption that ordinary citation practice covers it.
How this differs from general AI-governance policy already on this site
This is deliberately narrower than institution-wide AI governance. See how AI rules differ for a doctoral thesis versus coursework for the broader accountability and disclosure framework a doctoral programme needs; that piece covers permitted AI-assisted drafting and disclosure for the candidate’s own writing process. This piece addresses a different, more specific problem: how the examination panel itself is composed and how it scores a thesis whose research object — not just its drafting process — is an AI or machine-learning system. The two questions overlap at points (both eventually touch disclosure and reproducibility) but a programme needs both policies stated separately, because a candidate can fully comply with the institution’s AI-use-in-writing policy while still submitting a thesis whose model and code require the viva-specific structure described above.
Aligning this with existing consistent-marking practice
A rubric-scored, pre-documented reproducibility check is the Data Science-specific application of the same calibration principle covered more generally in how to get consistent marking on extended written work — criteria specific enough that two examiners would apply them identically, decided before the viva rather than negotiated informally during it. The difference here is simply that one of those criteria (reproducibility) has an objective pass/fail test a panel can point to, which is a genuine advantage over most extended-written-work marking criteria that remain inherently more subjective.
Where Tesify fits
None of the above is something an AI writing platform can substitute for — reproducibility and code quality are assessed on the codebase itself, not the thesis prose. Where Tesify helps is on the written argument and methodology chapter that frames the technical work: the Tesify AI Writing Editor for Institutions gives supervisors a supervised view of drafting progress on the argument itself, which is useful groundwork before a viva where the panel needs the written contribution to be as clearly articulated as the technical one. A free departmental pilot lets a Data Science programme test this against one cohort.
Frequently asked questions
Does a Data Science or AI thesis viva always need a code-review component?
Yes, in some form — either live within the viva or as a pre-viva written technical report. A thesis with a substantial machine-learning or model-building contribution cannot be fully assessed from the written document alone.
Should reproducibility be a pass/fail gate or part of the overall score?
Many institutions now treat it as effectively pass/fail, separate from methodological quality scoring — a result that cannot be reproduced from the submitted code and stated environment is not verifiable evidence, regardless of how sound the method appears on paper.
Who should conduct the reproducibility check?
A designated technical examiner or reviewer, ideally before the viva rather than live during it, so the panel has documented findings to discuss rather than attempting to verify code in real time.
Does the external examiner need to be a machine-learning specialist?
Not necessarily a specialist in the exact sub-area, but they should have direct hands-on model-building experience in a closely related area — general statistical or theoretical expertise alone is not sufficient to interrogate model design choices and code quality.
What should a candidate submit alongside the written thesis?
A version-controlled repository with a clear environment specification and a README describing how to reproduce the headline reported results, using the real data or a stated synthetic equivalent where the real data cannot be shared.
How is this different from general viva-format guidance already common in doctoral handbooks?
General viva guidance assumes the thesis document is the complete object of assessment. A Data Science or AI thesis has a second, equally consequential artefact — the codebase — that needs its own examiner expertise, its own review process and its own place in the scoring rubric.
Does a candidate need to disclose which pretrained models or third-party datasets were used?
Yes, and this should be an explicit institutional requirement stated separately from the general academic-integrity policy — provenance and licensing disclosure for a foundation model or dataset is a different question from citation practice for prior scholarship, and a viva panel needs it documented before the defence, not discovered during it.
Can a smaller programme run this model without a dedicated technical-reviewer role?
Yes — fold the reproducibility and code-quality review explicitly into the external examiner’s remit rather than leaving it unassigned, provided that examiner’s own background includes direct hands-on model-building experience.