Setting 1 · In depth · Chapter 4
My Staff Development Fund reporting workflow
The Staff Development Fund (SDF) provided an allocation for each staff member's professional development. Part of my job was preparing statements of each person's spending against that allocation. This is the workflow I took part in, tried to improve, rebuilt and then kept checking.
1 · The same matching, every cycle
- Prepare statements
- Check figures
- Circulate to staff
- Answer questions
For each staff member I matched their record and fund allocation with their expense transactions, calculated the totals, and prepared a statement and an email. Then I checked the figures and answered questions.
Each figure had to stay connected to the right person and allocation, so a mistake in preparation could carry through to what staff received. Repeating this by hand every cycle was the first source of friction.
Thesis Section 4.2.1
2 · Fitting a response into the organisation
Python processing was already under development. My February 2025 message described a script generating staff-specific spreadsheets and email files, with Copilot intended as the front end for staff queries. What I still needed was an IT environment and permissions where the arrangement could run.
- February 2025A colleague in a management role forwarded my request to central IT; I answered questions about environment, storage and access.
- April 2025After almost two months without a substantive reply, I lodged a service-desk ticket.
- May 2025After a senior colleague followed up, I learnt that part of the request fell outside that team's responsibility and that the role I had asked for gave broader access than the work needed.
- Late May 2025I lodged a more specific ticket and arranged a meeting.
“At the time, I expected that formal ticketing might prompt a response where direct email follow-up had not” Reflective journal, 16 February 2026
“I understood this as a correction to the scope of my permission request and as evidence of a gap in my own knowledge of enterprise security governance” Reflective journal, 16 February 2026
The dated messages confirm this sequence. They do not show why the requests moved slowly, whether the May follow-up caused progress, or whether a suitable environment was later obtained. Writing code locally addressed only part of the problem. Thesis Sections 4.2.2–4.2.3
3 · From speed to traceability
At first
Produce statements faster
Then
Keep figures traceable and explainable
When a staff member asked about a figure, I needed to know which records it came from and how it had been calculated. An output that was faster to create but harder to check would not have made the work more workable. So data preparation, automation and traceability became connected design requirements. Thesis Section 4.2.4
4 · The connected arrangement
Each part had its own job. Select a part to see how it worked.
Source records
Staff reference and transaction data
The reference information (staff records and fund allocations) and expense transactions for each reporting cycle. A temporary SQLite staging area brought them into one repeatable processing sequence.
Technical materials · Thesis Section 4.3.1
Python processor
A shared code, TR_Code, kept each transaction linked to the right staff record; totals were calculated and outputs prepared for different purposes
Selected and joined the records, calculated debit, credit and net totals for each staff member, and generated the outputs below. Built-in checks looked for missing, blank or duplicate TR_Code values, recorded rows where a code could not be extracted, compared input and valid row counts, and kept execution logs.
The checks showed how the processing ran. They did not establish that every figure was correct in its administrative context.
Technical materials · Thesis Sections 4.3–4.4 · Figures 4.3.2.1 and 4.4.3.1
For reporting
A spreadsheet and matching email file for each staff member, prepared as a pair and sent to staff
Generating the statement and the email that carried it together moved part of the repeated packaging work into the processor, and kept each communication tied to the right staff record.
Technical materials · Thesis Section 4.3.2
For questions
Selected data files, with direct identifiers replaced, that I asked questions about in plain language through Microsoft 365 Copilot
An anonymisation utility replaced direct identifiers in the selected files while keeping the relationships needed for checking. I supplied these prepared files directly to Copilot, from April to December 2025; there was no separate system searching a document collection. Copilot could bring together totals and transaction details from the files.
Copilot’s usefulness depended on the preparation before it. Interface limits affected how much material I could supply at once.
Reflective journal and technical materials · Thesis Sections 4.4.1 and 4.5 · front matter
For checking
Processing logs and saved outputs that kept a route back to the records
Together with the TR_Code links, these let me move from a figure in an output back to the prepared records and, where needed, the source records.
Technical materials · Thesis Section 4.4.2
My checking and explanation
When a figure or a Copilot answer needed attention, I went back to the prepared records and the funding context, reconciled them, and explained the result
Copilot answers were checked and reconciled before I used them with staff. Questions about what a figure meant could still arise after statements were sent, as in an October 2025 query about the total available and a November 2025 reply about a claim paid from a separate award.
Two exchanges do not show how often such questions arose, or whether the arrangement reduced them.
Reflective journal, with dates confirmed by messages from the time · Thesis Sections 4.6 and 4.7
My conclusion: this connected arrangement, including my checking, became part of recurring SDF reporting, which the thesis analyses as workaround formation. Python or Copilot on its own was not the workaround. The arrangement changed part of the reporting work without replacing the wider university process. Thesis Sections 4.7 and 2.9.2
I supplied selected files directly to Copilot rather than building a system that searches a document collection, so this is not retrieval-augmented generation (Lewis, P., Perez, E., Piktus, A., Petroni, F., Karpukhin, V., Goyal, N., Küttler, H., Lewis, M., Yih, W., Rocktäschel, T., Riedel, S., & Kiela, D. (2020). Retrieval-augmented generation for knowledge-intensive NLP tasks [Preprint]. arXiv. https://arxiv.org/abs/2005.11401). The processor code is published as Lee, S. C. (2026). Staff Development Fund (SDF) processor (Version 1.0.0) [Computer software]. GitHub. https://github.com/shangchiehlee/data_automation/tree/main/SDF. Thesis Sections 2.7 and 4.5
5 · What remained around the outputs
The arrangement became part of regular reporting, but the work did not end when a statement was produced. Two exchanges in late 2025 show the questions that could still come back.
October 2025
A staff member asked me to confirm the total available, then withdrew the question the same day after finding written confirmation themselves.
November 2025
A staff member replied that a recent large claim had been paid from a separate award, not the development fund, and that they were not trained to read financial spreadsheets. The figure needed to be understood in relation to the funding source covering the expenditure.
“[The exchanges] also show that making the data available did not remove the need for human interpretation or support” Reflective journal, 16 February 2026
These two exchanges illustrate why staff could still need help interpreting figures after receiving a statement. They do not show how often this happened or whether the arrangement reduced such questions. I used Copilot to query selected prepared files; staff received the statements. Thesis Section 4.6.2
My conclusion: developing, preparing, checking, reconciling and explaining all took time, skill and responsibility, and sat behind the outputs. That is less visible work. My records do not show enough about role expectations, workload allocation, support or recognition to call it invisible labour. Thesis Section 4.7
How I know this
| Source | What it can show | What it does not, by itself, show |
|---|---|---|
| Reflective journal (main source) | How I saw my experience, problems, decisions and responses, looking back | My understanding at the time; it was written in February 2026 about 2025 events and is not independently confirmed |
| Technical materials | What I built and how parts of it operated: the processor, anonymisation utility, processing logic and diagrams | What the arrangement meant for the organisation, or that every figure was right in context |
| Dated messages | Dates and the order of events | They were not analysed as a separate source |
Because I built and ran the workflow, I could examine decisions, uncertainty and judgement that finished outputs do not show. That same involvement can make events look more coherent looking back, so I keep apart what I recorded, what the code shows and my later interpretation. Copilot was part of the workflow, not a source of research evidence. More on the method Thesis Sections 3.4, 3.5 and 3.7.2