PRISM•MO
When the artefact is no longer the evidence
The assessment model most of us inherited rests on a simple assumption. The code a student hands in is a fair proxy for the code they wrote. With AI in the room, that assumption does not hold. Working code can now arrive in hours. Clean READMEs can be drafted in minutes. The finished artefact often looks stronger than the process that produced it.
The marker is left asking a question the submission itself cannot answer. Where did this come from? Which parts did the student work out, and which parts came back from a model? What was understood along the way, and what was kept without being understood at all?
The question behind the mark: what was understood, and what was generated? The final code, on its own, no longer answers it.
What "capturing thinking" has to mean
Thinking, in programming, is not a statement. It is a sequence of actions that produces working code. A brief restated. An approach chosen. A first attempt written. An error hit. A model asked. A reply rejected or kept. A fix applied. A test run. Each of those actions is a decision. Taken together, they are the thinking the mark is trying to read.
Capturing thinking, then, is not about writing more words at the end. It is about leaving a readable trace of the decisions while the work is being built.
- first attempts, before the model was opened
- prompts, model replies, and what was kept or changed
- errors hit, fixes applied, and the reason for each fix
- trade-offs chosen between approaches that would have worked
- short notes on why one path was taken over another
Why common approaches fall short
Most lecturers already ask for some record of how work was produced. The problem is that the most common formats do not hold up when AI is in the mix. Each one documents the output and misses the process.
Written after completion
A paragraph asking the student what they learned, produced once the code is already working. It sits apart from the actual decisions and is easy to fill in after the fact, with or without a model.
Proof of a finished state
An image of the test running, or the UI rendering. It shows that the output existed. It does not show who chose the approach, or which turns in the build produced it.
Describes what the code does
A short write-up of how the function behaves at runtime. Useful for a reader, but easily reconstructed from the code itself by the same model that may have helped write it.
The common failure: these formats document the output. They do not carry the process that produced it, which is the part the marker can no longer see from the code alone.
Six practical ways to capture thinking during development
None of what follows is new. Working developers use every one of these methods day to day, which is part of the point. They already fit the tools students use. The change is in making them visible to the marker, and applying them to every assignment rather than the ones where the lecturer happens to remember.
1. Version history
Git, or whatever the tool is, already records a sequence of changes. A small number of commits, with honest messages, shows where the student started, which parts they rewrote, and which parts stayed stable. A single final commit reading "final version" shows nothing. The instruction to students is simple. Commit as you go. Say what changed. Name the reason, not the file.
2. Lightweight decision logs
A few short prompts in the README, tied to specific points in the code, can carry more weight than a long reflection at the end. Why did you choose this approach? What did you try before this worked? What would you change with more time? The value sits in the link to a specific file or line, not the length of the answer. Two sentences against a real decision beats two paragraphs in the abstract.
3. AI interaction trails
When a model is used, the exchange itself is the evidence. Prompts the student wrote, replies they received, and what they kept, rejected, or changed. A short block in the README can carry this. The prompt. An excerpt of the reply. A note on what was wrong with it, or why it was kept. The aim is not to log every keystroke. The aim is to show how the student worked with the tool, and what they did with the answer it gave.
On AI use: PrismMO does not ask students to avoid AI. It asks them to account for it. The difference between a student who understood their code and a student who pasted it in often sits in this section of the README alone.
4. Debugging evidence
Errors are among the clearest traces of thinking. A short record of what broke, why it broke, and how it was fixed tells a marker more about understanding than a clean final function. The fix itself does not need to be elegant. The account of it needs to be accurate. A student who can name the bug they hit and the reason the fix worked has shown something the finished code cannot.
5. Iteration comparisons
A first attempt next to a final version, with a short note on what changed and why, is one of the most readable forms of evidence available. It carries the shape of the student's thinking without asking them to summarise it in the abstract. Two code blocks and a paragraph are often enough. The difference between the two blocks is the learning.
6. Short walkthroughs
A two-minute account of how the solution works and where the decisions sit, in writing or on video, gives the marker a way to check that the student can account for what they produced. Walkthroughs do not replace the other methods. They confirm them. A student who cannot talk through their own code has a gap somewhere in the trace.
What this changes for the marker
The shift is small in artefact and large in what the artefact carries. The code is the same. The README is the same file. What the marker is reading against it is different.
What the marker infers
- whether the code runs
- whether it meets the brief
- whether it looks like the student's work
Understanding is guessed from the output. If the code works, the student is assumed to have understood it. If AI was used, there is no record of how.
What the marker observes
- how the solution developed, commit by commit
- which decisions the student made, and why
- where AI was used, and what was done with the reply
- what broke, and how it was fixed
- what the student would change next time
Understanding is read from the trace. The criteria do not change. The evidence base does.
The move: from inferring understanding to observing it. The marker is no longer guessing at what the student knew. They are reading an account of what the student did.
Is this more work?
For the student, the total time on an assignment usually stays close to what it was. A few minutes of commit discipline and a few paragraphs in the README, in exchange for not having to produce a separate reflection document. For the marker, the reading takes longer per submission, but the decisions get easier to justify and standards across a cohort get easier to hold. The time spent marking an honest trace is time you previously spent second-guessing an opaque one.
The trade: more trustworthy evidence, not more evidence. The workload shifts toward reading a trace that is already there and away from reconstructing one that isn't.
The real difficulty: consistency
Most educators already use at least one or two of these methods. A commit history here, a reflection there, an occasional AI log when it comes up in conversation. The difficulty sits one level up. Running these methods consistently, across assignments, across students, across markers, so the evidence is comparable and the decisions are repeatable.
Without structure, capturing thinking ends up depending on the individual lecturer and the individual student on the day. With structure, it sits inside the module and survives staff changes, cohort changes, and shifting AI tools.
From techniques to a system
This is where PrismMO begins. The six methods above are the raw material. The PRISM Workflow is how they are arranged so the evidence lands in one place and can be read the same way every time. Five stages, named for the move the student is making at each point in the build.
Problem
The brief restated by the student, so the rest of the work can be read against a problem they have defined in their own words.
Respond
A first attempt before any AI is used. It does not need to be correct. It needs to be theirs.
Interact
Prompts, model replies, and what the student kept, rejected, or changed. The AI section of the README.
Synthesize
The final code, with a short account of how it was built from the earlier attempts and the AI exchanges.
Make visible
A short reflection linking decisions to what the student now understands, and what they would still change.
Each of the six methods sits inside a stage. Version history and iteration comparisons feed Respond and Synthesize. AI trails belong to Interact. Decision logs and debugging evidence run through most of the five stages. Short walkthroughs sit in Make Visible.
Where the evidence lives
Nothing on this page asks for a new platform or a new artefact. Every method lands in the README the student was already going to write. That is the point. One file, already inside the repo, carries the trace.
| Method | Workflow stage | Where it lives in the README |
|---|---|---|
| Version history | Respond, Synthesize | Repo commits, referenced in Dev Decisions |
| Decision logs | Respond, Synthesize, Make Visible | Design & Planning, Dev Decisions |
| AI interaction trails | Interact | AI section |
| Debugging evidence | Synthesize | Dev Decisions, Testing |
| Iteration comparisons | Respond, Synthesize | Design & Planning, Dev Decisions |
| Short walkthroughs | Make Visible | Reflection |
This structure matches how working developers already use README files in industry. For a student, the instruction is simple. Fill the sections you already have, and fill them as you go.
How the Framework reads the same evidence
The Workflow leaves the trace. The Framework turns it into marks against criteria lecturers already use. Four lenses, applied to the same README.
Output
Does the final build meet the brief? The same question traditional assessment asks, answered from the same artefact.
Process
Is there a trace of how the work was built? First attempts, iterations, and AI exchanges, in the README.
Decisions
Are choices explained? Rejected options, corrected AI output, trade-offs the student made.
Understanding
Can the student account for what they produced? The reflection section is where this sits.
The final program is not the evidence. The trace that produced it is.
Where to start
One task is enough. Pick an assignment students already submit with a README and a repo. Ask for the six methods, arranged through the PRISM stages, in that one file. Mark against the criteria the module already uses. The rest of the module stays as it is.
- Pick a task students already hand in with a README and a repo.
- Add the PRISM sections to the README template for that task.
- State, in the brief, that AI use is expected and that the README carries the evidence.
- Mark against the criteria you already use, reading the README through the four Framework lenses.
What this does not change: not the criteria, not the tools, not the artefact students submit. Only what that artefact is allowed to carry.
Keep thinking visible
The final code stopped being a trustworthy measure of understanding the moment AI entered the room. The response is not to try to detect AI out of the workflow. It is to leave a trace of the thinking that produced the code, inside the workflow, in the artefact the student was already going to submit.
That is the move PrismMO is built around. One file. Real methods. Five stages. Four lenses. The same criteria the module already uses.