Reflective journal My account of the SDF work, written in February 2026 about events in 2025.
Technical materials The code, processing logic and diagrams of what I built, showing how it worked.
Dated messages Messages from the time, used only to confirm dates and the order of events.
Participant account What an interviewee described. Not observed or checked independently.
Interpretationdashed outline Conclusions drawn from the evidence.
Stage of use Whether a change was in use, being tested, explored or proposed. These labels describe a stage, not whether the change succeeded.
Setting 2 · Breadth · Chapter 5
Institutional support staff
Three interviewees worked in roles involving university data, systems, AI development, risk communication or support. Each spoke from their own responsibilities, not for the university. Their projects were separate, not stages of one programme.
Participant accountIP01–IP03 · Thesis Chapter 5
Building or testing a capability did not settle its wider use
IP01Partly rolled out
A managed service for subject-related assistants
The starting problem was finding a managed way to upload and use institutional information, rather than an uncontrolled public tool. A service with controlled upload, source citation and access arrangements had been developed, and some assistants had begun rolling out.
“we wanted to go and find some kind of capability where we could upload data securely”
What held back wider use: IP01 linked a slower wider rollout to governance and concern that generated answers could sound authoritative while being wrong, so being able to inspect the sources behind an answer mattered.
IP02In development
AI applications for colleagues
IP02's team developed AI-enabled applications, including one combining database queries with a hosted language model. In a team-managed cloud environment they could set up some prototype infrastructure themselves.
“having that control of our own environment, yeah, definitely helps with some of the friction”
What wider use needed: architecture and security sign-off and checks of robustness, security and scalability before colleagues could rely on an application. Whether this application reached production is not established.
IP03Being tested
A message-drafting prototype
IP03 was testing an in-house alternative to a purchased service: a workflow that drew on selected information and guidance to draft individualised risk-related messages, placed in IP03's own email drafts for review.
“I'm using dummy data at the moment. I'm not using live data”
What was outstanding: testing with live data and production approval. IP03 called the prototype a “workaround”; the thesis does not classify it as workaround formation, because it had not entered routine communication work.
These were separate projects, each with its own review requirements. Exact titles, units, systems and projects are generalised to protect participants. Thesis Sections 5.2–5.5
What was being checked differed in each project
IP01Source records→Extraction and modelling→Ongoing warehouse reconciliation for complete, accurate later queriesEstablished data-platform work, not shown to be introduced by GenAI. A separate concern: keeping the sources behind a generated answer inspectable.
IP02Custom AI application→Sign-off and robustness, security and scalability checks→Wider use, subject to reviewRequirements described for wider use; completed approval not established.
IP03Made-up records and guidance→Draft in IP03's own mailbox→IP03 reviews before sendingStill in testing. IP03's separate, manual preparation of recipient lists was established communication work, not part of the prototype.
“there's a lot of time and effort put into reconciliation to ensure that what is returned from that data warehouse is accurate, and that's an ongoing process” IP01
Each row is a separate setting, not a sequence or an equal stage of implementation. Adapted from Thesis Figure 5.6.1. Thesis Section 5.6
What this setting showed
RQ1 · Friction
The effect differed by task: slower rollout with answer-risk review (IP01), added engineering and sign-off work (IP02), and staying in dummy-data testing (IP03). Review and approval count as friction only through such effects.
Local control over a development environment (IP02) and an in-house prototype still being tested (IP03) are local adaptations. Neither shows an alternative incorporated into regular work. IP01's service was a separate response.
Preparation and checking could be hidden from a later user without being unrecognised. IP03 described list preparation as “invisible time”; the interview does not establish that it was unallocated or unrecognised.
Three interviews do not describe a university-wide process, a shared approval pathway, a measured delay or a general shortage of resources. Thesis Sections 5.8–5.9