Interim Guidance on the Use of AI Tools in Postgraduate Studies and Research

On 9 September 2026 I wrote to the postgraduate students of the College of Computing and Mathematical Sciences at Khalifa University, where I serve as Acting Associate Dean of Graduate Studies, about the use of artificial intelligence in their courses, their research and their theses. The University is preparing its official guidelines; until those appear, this is the interim advice of our College. I am publishing the letter here because the questions it answers are not ours alone.

---

I am writing to you about a question that many of you have already raised with your supervisors and with me: how should you use artificial intelligence tools, such as large language models and the coding and research assistants built on them, in your courses, in your research and in your thesis? Khalifa University is developing official institutional guidelines on this matter. Until they are published, I would like to share with you the expectations of our College and some practical advice, so that nobody has to guess in the meantime. This letter does not create new regulations. The academic integrity regulations of the University remain fully in force, and the rules set by your course instructors, your examiners and your supervisors take precedence over the general advice given here. What follows applies to all postgraduate students of the College, in Mathematics, Computer Science and Computer and Information Engineering, at both the MSc and the PhD level.

This letter reaches you in a week that will be remembered in the mathematical sciences, and I want to begin there, because a single episode teaches almost everything I have to say. On 8 September a laboratory announced that an internal AI system had produced a proof that the three-dimensional Navier–Stokes equations, which describe the motion of fluids and which are used every day in aircraft design, weather forecasting and the study of blood flow, can develop a singularity in finite time. The proof was found by a system of cooperating agents, of the order of ten thousand of them, running for about eighty-eight hours, and it came with a formal verification in the proof assistant Lean. To the credit of its authors, the manuscript was published in full, all one hundred and sixty-six pages of it, together with the formal code. This is one of the seven Millennium Prize Problems, and it happens to belong to my own field.

Now read the fine print, because the fine print is the lesson. When the Clay Mathematics Institute posed this problem in 2000, Charles Fefferman wrote the official statement, and he offered four alternatives, a proof of any one of which counts as a solution. Statements (A) and (B) ask whether a fluid that starts smoothly and is then left alone stays smooth for ever, and in both of them the external force is required to be identically zero. Statements (C) and (D), which assert instead that the equations break down, permit a smooth external force. The new theorem constructs a fluid that starts at rest and is driven by exactly such a force, and its authors say plainly which alternative they establish: (C), and with it (D). So the Millennium Problem has been resolved as it was posed, and at the same moment the question that almost everyone means by the Navier–Stokes problem, whether a fluid left to itself can break down, is precisely as open this morning as it was last week. Nothing was concealed here. The asymmetry is written into the official statement, the authors declare which alternative they prove, and the laboratory adds that it does not intend to claim the prize. The fine print simply had to be read. I would add one more observation, and I offer it as a lesson in reading announcements: a companion result, released in a footnote and given a small fraction of the attention, claims something that many specialists will consider deeper still. What is placed in the headline and what is placed in the footnote is a decision, and it is not always the mathematics that decides.

Notice, finally, how much of this letter is already contained in that one week. A proof assistant checked the argument, and a proof assistant can only check the statement it was given, which is the subject of point 15 below. Nothing has yet been refereed, or read and digested by the community that owns the problem, which is the subject of point 12. Within a day the announcement was followed by a public dispute about priority and about whether unpublished work had reached a competitor, which is the subject of points 7 and 9. And the proof did not come from nowhere: its own bibliography rests on a decade of theorems by named human mathematicians, and several of them, working with the same kind of assistance, proved closely related results in the same fortnight. I would rather you learned these lessons from a real episode in a real field than from my advice about them.

I want to be honest with you about the uncertainty. Nobody, in our College or elsewhere, can tell you today what your profession will look like in five years. But some things are already clear. Whether you go to industry, to a research laboratory or to a university, you will be valued for one thing above all: whether your judgement can be trusted. Can you tell a correct argument from a convincing one? Can you verify a result, a proof or a piece of code, and explain to others why it is right and why it matters? Your postgraduate degree exists to make you such a person. The new tools can help you to become one, or they can quietly empty your training of its content while your grades stay good. The difference lies entirely in how you use them.

Part I. Guidance for all postgraduate students of the College

1. You are the author, and you carry the responsibility. Every sentence, formula, figure, table, line of code and result that you submit under your name is yours. You must be able to explain it and to defend it, in a meeting, in a seminar and at your thesis defence. An AI system cannot be an author, cannot be a co-author and cannot take responsibility for anything. If you cannot reconstruct and defend the core of your own work, the work is not finished, whatever a tool has produced.
2. Understand before you use. Do not use a result, an argument, a piece of code or a reference from any source, whether an AI tool, a paper, a website or a colleague, without understanding it fully. Do not settle for partial understanding. Current systems produce plausible-sounding material very quickly, and it is easy to absorb an error without noticing it, or to accept a half-understood step in order to move on. Your supervisors will ask probing questions about every claim you invoke, down to first principles. This is not distrust; it is how we make sure that the understanding is yours.
3. Think first, then consult. Attempt every problem on your own before you ask a tool, the literature or a colleague. The period when you do not yet know what to do is not wasted time; it is where the learning happens, and the wrong turns you take on your own show you what you had misunderstood. Keep a part of your work entirely free of AI assistance, so that you can measure your own strength. Do the things that you do for the first time, such as reading a research paper from beginning to end, writing your first proof or building your first implementation, without assistance. There will be time later to accelerate what you already know how to do.
4. Verify everything. Treat the output of an AI system with more suspicion than the work of a trusted colleague, not less. These systems are good at making an argument look sounder than it is, with phrases such as "it is easy to see" or "it follows immediately". Check every step, run every piece of code, and open every reference. Never cite a paper that you have not read: references produced by these tools are frequently incomplete, misattributed or simply invented, and citing them is a form of plagiarism even when no dishonesty is intended.
5. Code, data and experiments. Generated code is a draft, not a result. Read every line, understand it, test it, and check its licence and its security before it enters your project. Never let a tool produce, complete, "clean" or fill in experimental data; a fabricated data point is research misconduct no matter who or what produced it. For any result that depends on an AI system, record the tool, the version and the settings that you used, so that the result can be reproduced. If you use a model to evaluate, label or judge, validate it against human judgement first and report how you did so.
6. Write in your own words. Do not paste generated text into your thesis, your papers, your reports or your emails to your supervisor. Digest the material and then explain it yourself: the reader wants your thinking, and the writing is where your thinking becomes precise. Using a tool to correct the grammar and spelling of a draft that you wrote is acceptable; using it to generate the content is not.
7. Protect confidential material. Do not enter into any external AI service material that is not yours to share: unpublished results or drafts of your collaborators and your supervisor, manuscripts that you or your supervisor are reviewing, data collected under an ethics approval, data covered by an agreement with an industrial or governmental partner, and any personal information. Be careful also with your own unpublished ideas; what you type into a commercial system may be stored and used. Read the terms of any tool you use, and when in doubt, ask your supervisor before you use it. This is not a hypothetical risk. In the episode I described at the beginning of this letter, one of the mathematicians involved publicly questioned whether his own unpublished work, developed in private sessions with a commercial assistant, had become available to a competitor. The company denies it, while conceding that it cannot exclude that data derived from that usage improved its systems, and the matter is unresolved and may never be resolved. That is precisely the difficulty: an accusation of this kind is almost impossible to prove and almost impossible to disprove. The lesson, however, is available today and it costs nothing. What you type into somebody else's system has left your control.
8. Disclose how you use these tools. Tell your supervisor, at your meetings and in any write-up that you send, whether you have used AI tools and how. Be specific. "The idea of trying this change of variables was suggested by a model, and I then proved the estimate myself" or "this function was generated by a tool and I tested it on these cases" is useful; "AI was used" is not. Routine uses such as checking spelling, searching for references or formatting need no disclosure, in the same way that nobody discloses the use of a search engine. Honest disclosure will never be held against you; it lets your supervisor guide you, and it protects you if the origin of an idea is questioned later. Concealment is a different matter, and it is treated as such.
9. Keep a research log. Keep dated notes of what you asked a tool, what it returned, what you kept, what you rejected, and how you verified what you kept. This takes a few minutes a day. It is the basis of the statement on AI use that you will include in your thesis, it establishes what you contributed and when, and it is your best defence if a question of attribution or priority ever arises. This month has shown how suddenly such a question can arise, how public it can become, and how little there is to settle it with afterwards if the dated record was never kept.
10. The rules of the course, the examination and the supervisor come first. In coursework, follow the instructions of your instructor. In examinations, AI tools are not permitted unless the examiner explicitly says otherwise. Your supervisor may set stricter rules for their research group, and you are expected to follow them. A simple test helps when you are unsure whether a use is acceptable: imagine that a stronger student stands where the tool stands. Asking that student to explain a concept is fine; copying that student's solution to your assignment is cheating. The same holds for the tool.
11. Stay the master of the tool. Use these systems as a partner in a dialogue, not as an oracle. Ask for questions that help you find where you are stuck, ask for hints, ask for an example or a counterexample, ask which prerequisite you might be missing, and only rarely ask for a solution. Remember that these systems are trained to be agreeable and will often feed your own ideas back to you in language that you like; do not mistake that for confirmation. Watch yourself for signs of dependence: giving up sooner, reading less, or being unable to work when the tool is not there. If you notice them, step back.

Preparing for an uncertain future

The tools you use today will be replaced within a few years, and the skill of operating a particular one is perishable. What lasts is different: solid fundamentals in your discipline, the ability to read critically and quickly and to spot a gap or a circular argument, judgement about which questions matter and which do not, the habit of verifying before believing, the ability to explain your work clearly in writing and in person, and the ability to work with other people. These are the abilities that the tools cannot supply, and that employers and research groups will increasingly pay for because they are becoming rare. Invest your time in them.

In our College, I would add one more: learn how these systems actually work. Understanding their mechanism, their training and their failure modes is part of being a professional in computing and in the mathematical sciences, and it is the surest protection against being impressed by them for the wrong reasons. And do not let the word AI shrink until it means a chatbot. Jeremy Avigad has argued recently, and I agree with him, that the sprint of the companies to settle famous conjectures is crowding out most of what these technologies actually offer the mathematical sciences: proof assistants and the libraries built around them, automated reasoning, satisfiability and constraint solvers, and machine learning used to find patterns in mathematical data, to search for objects of interest and to locate the parameters at which interesting behaviour begins. He adds a point that our discipline has not faced honestly, namely that the young people who invested in these skills were for a long time penalised for it, because their work appeared in computer-science venues and counted for little on an academic job application, so that many of them left for industry. I do not think that should be true in our College. If you build these skills alongside your mathematics, I will count it as part of your training and not as a distraction from it, and I would like to hear from you if you find that it is counted otherwise elsewhere.

Read what the companies say about their own systems in the same spirit. An announcement that a model has solved a famous problem or passed a benchmark is business communication before it is science: it is written to attract attention, customers and investment. Judge the mathematical content only once the result, the proof and an independent verification have been separated from the publicity, and let your community and the literature, not press releases, tell you what matters in your field. Keep in mind, too, the sharpest form of the difficulty, which this month has just supplied: a claim can be entirely correct, carry a machine-checked certificate, be documented honestly by its own authors, and still not be the answer to the question you believed was being asked. There is no substitute for reading the statement itself.

Part II. Additional guidance for students in mathematics

1. A proof is not a proof until you have checked every line. Generated arguments fail most often at exactly the steps that are declared obvious. Go through each step down to first principles. A short and elegant proof of a statement that has resisted experts deserves the most suspicion, not the least. It is entirely acceptable to ask a system repeatedly for clarification until every step is justified; the system will not become annoyed. But once you have the argument, verify it yourself, without the tool, before you believe it.
2. Prove; do not merely test. Examples and numerical experiments are precious: they refute false statements, they build intuition, and they show you whether you have understood a theorem. If you cannot apply a result to its simplest case by hand, you have not understood it yet. But no amount of numerical evidence replaces a proof, and a plausible argument confirmed by a computation is still only a plausible argument.
3. Trace the origin of every idea. These systems are remarkably good at combining ideas from the literature and remarkably bad at saying where the ideas came from. When an argument contains something that looks new to you, find out where it first appeared, and give credit. If you cannot find the source, say so to your supervisor. Attribution is a matter of honesty, and the mathematical community is small enough to remember.
4. Use formal tools for what they are. Proof assistants such as Lean and Rocq, and computer algebra systems, give an exact check of a formal statement, and this is valuable. But be precise about what that check delivers. A machine-verified proof guarantees exactly one thing: that the formal statement follows from the axioms the proof uses. It does not guarantee that the formal statement means the same as the sentence you wrote in your thesis, and it does not guarantee that the formal proof follows your argument. Formalisations have been circulated in which the main theorem had quietly been restated as an axiom, in which the statement had been weakened until it became provable, and in which a tool repaired a gap without saying so, leaving the author to go on believing an argument that was wrong. There is one remedy and it costs almost nothing: read the code. You do not need to be fluent in Lean to see whether the theorem at the top says what you meant and whether the steps below resemble the proof you had in mind, and if you wrote the argument you are the best-placed person in the world to check that correspondence. Nobody else will do it for you. What you want, and what your examiners will ask for, is understanding, not only a positive answer from a checker.
5. Protect your starter problems. The first problems of a research career exist to teach you the techniques of your field, and that purpose is lost if a machine solves them for you. Agree with your supervisor which problems you work on, do them by hand, and do not ask a system for complete solutions of your thesis problems. Nothing that a tool can do for you at this stage is something that your supervisor cannot do better, and a question that you fear is stupid should be asked to your supervisor, not to a machine. That is what we are here for.
6. Read slowly; write for a human reader. Careful, slow reading of the literature is a skill that no summary replaces. When you write, keep the big picture in view and explain how the main ideas fit together; generated arguments tend to explain what is elementary at length and to hurry past what is subtle. Do not let generated text set your notation, your terminology or your style. You may suspect that exposition is a minor skill in the new era. The opposite is true. In the fluid-mechanics breakthroughs of these past two weeks the arguments were heavily assisted by machines, and the authors of one of them described their own first draft as the worst write-up they had ever seen in the history of mathematics; what turned it into mathematics was human work of exactly this kind, and the digestion of these results by other mathematicians is going on as I write. That work is not the residue left over after the machine has finished. It is the part that makes a theorem usable by anybody else.
7. Practise the questions. The abilities that will remain distinctly ours are choosing the problem, finding the right formulation, deciding what is worth developing, and explaining why a result matters. Practise them deliberately: for every new object you meet, ask what you would like to know about it, what it might be related to, and which tools you would try. Many of our colleagues hold themselves to the standards of the Leiden Declaration on Artificial Intelligence and Mathematics, and I recommend that you read it.

Let me end where I began. This guidance is interim; it will be revised when the official guidelines of the University are published, and I would like it to be improved by you. If you disagree with something here, or if your experience suggests a better rule, write to me. Talk to your supervisor about these tools openly and often; the most important sentence in this letter is that honest disclosure is safe. My door and my email are open to you.

You have chosen a difficult path, and you have chosen it at a moment when your field itself is changing fast. The struggle you feel when a problem does not give way is not an obstacle to your training. It is the training. Nobody can do that part for you, and no tool can take its result away from you once it is yours.

---

Further reading: the Leiden Declaration on Artificial Intelligence and Mathematics (leidendeclaration.ai), and the collection of essays by mathematicians at proofsandprompts.com, where I would single out Seewoo Lee on what a formal proof does and does not guarantee, and Jeremy Avigad on what mathematics should now become. For the episode described at the beginning of this letter, read the official statement of the problem, written by Charles Fefferman for the Clay Mathematics Institute (claymath.org), and compare its four alternatives with the theorem that was announced. It is five pages, and the exercise is worth an hour of your time.