PRISM•MO
Why the work needs a shape
Students can now produce working code and clean explanations in hours. The artefact looks stronger than ever. The process behind it is harder to see. A marker opens a repo, reads a README, runs the build, and has to decide how much of the thinking was the student's. From the artefact alone, that decision is a guess.
The way students reach for AI is also not the way working developers use it. A student asks a model for a whole answer. An experienced developer works against a brief, a codebase, and a set of constraints, and drives the model through short, specific exchanges. Teaching and assessment can move toward that working pattern where the course allows.
The question behind the work: what was understood, and what was generated? PRISM Workflow is built around that question. It structures the doing so the answer is legible from the submission.
The five stages
The Workflow is not a new framework students have to learn from scratch. It maps to what already happens when someone builds software with a model in the loop, and gives each step a name and a place to live.
Problem
Restate the brief in the student's own words. Inputs, outputs, constraints, and what the brief does not cover.
Respond
A first attempt made before any model is opened. Pseudocode, a rough function, a sketch on paper. Unaided and often imperfect.
Interact
Work with the model. Record the prompts, the replies, and what the student kept, rejected, or changed.
Synthesize
Bring the pieces together into a final build. A short note explains how it was assembled from the earlier attempts and the AI exchanges.
Make Visible
A reflection linking decisions to understanding. What was learned, what was corrected, what the student would change next time.
Problem
Before any code is written, the student writes the problem into the README. Not the brief, pasted. The brief, restated. Inputs, outputs, success criteria, and the edges the student has noticed.
- what is being built, in plain language
- what the inputs and outputs are
- which constraints apply and which do not
- what the brief does not cover
The value of this stage is not thoroughness. It is ownership. The rest of the work is read against the problem as the student defined it, which gives the marker something specific to compare the final code to.
Respond
The student makes a first attempt with no model involved. This can be pseudocode, a rough function, a data-flow sketch, or a paragraph of plain English describing the approach. It does not have to work. It has to be theirs.
Why it matters: an unaided starting point is the one reliable baseline for reading the rest of the work. Without it, a marker has no way of knowing what the student brought to the task before the model did.
Interact
The student opens a model and starts working. Prompts, replies, and decisions about what to keep go into the AI section of the README as they happen. The point is not the model. The point is the exchange.
Write a JavaScript function for UK income tax bands.Alongside the prompt, the student notes what the model returned, what was wrong with it, and how it was changed. A few lines is enough. The goal is a readable trace: enough for a marker to see the correction happening, and to distinguish copied output from worked-through output.
What undermines this stage: pasting a full model reply with no commentary, or summarising "I used AI to help" after the fact. The evidence value comes from the exchange being visible in the moment.
Synthesize
The student pulls the attempts and the AI exchanges into a final build. The final code sits in the repo as it always would. The short note in the README explains how it was assembled: what came from the first attempt, what came from a model, what was corrected, and what was added at the end.
- the final function or module
- what was carried over from earlier attempts
- what was changed from the model's output
- what was tested and how
Make Visible
The last stage is the reflection. Two or three short paragraphs in the README, written once the build is finished. The student says what they did, what went wrong, what the model got wrong, and what they would change next time.
My first version only handled the basic rate. The model gave me a shape for the higher band but used the wrong threshold. I kept the structure, fixed the threshold, and changed the calculation so forty per cent only applied above 50,270. Next time I would write a small table of expected results first and test against it before touching the code.
This is where understanding is stated, not inferred. A marker can read the reflection against the earlier sections of the README and see whether the stated understanding matches the trace that produced the code.
Where each stage lives in the README
PRISM Workflow does not add a new artefact. It uses the README the student already has to write. Each stage maps to a section of a standard README structure most developers already recognise.
| Workflow stage | README section | What the section carries |
|---|---|---|
| Problem | Overview, Problem and requirements, User stories | The brief, restated, with edges and constraints |
| Respond | Design and planning | First attempts before any AI is used |
| Interact | AI section | Prompts, replies, and what was kept or changed |
| Synthesize | Dev decisions, Testing | How the final build was assembled and checked |
| Make Visible | Reflection | Decisions, mistakes, and what the student now understands |
Beginner use and advanced use
In beginner use, the PRISM sections are named in the brief and in the README template. The student fills them as they go and knows exactly what each one is for. This is the route most first adopters should take.
In advanced use, the Workflow becomes scaffolding built into the assignment brief rather than named to students. The brief asks for the same evidence, but using the vocabulary of the module instead of the PRISM labels. The trace produced is the same. What changes is how visible the model is to the student.
What this does not change
- the criteria you already mark against
- the artefacts students submit
- the tools or platforms in the module
- the time you spend on a marking round
PRISM Workflow sits inside the course. It does not replace the brief, the criteria, or the repo. It changes what the repo is allowed to carry.
PRISM Workflow and PRISM Framework. The Workflow is how the work is done. The Framework is how that work is read: Output, Process, Decisions, Understanding. The two sit together. The Workflow produces the trace. The Framework assesses it.
Run it on one assignment
The entry point is a single task, not a redesign. Pick one assignment your students already submit with a repo and a README.
- 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.
- Ask students to write Problem and Respond before they open a model.
- Read the submissions through the Framework and mark against the criteria the module already uses.
Keep thinking visible.