PRISM•MO
Why a second lens
Most marking schemes for programming coursework were written when the final artefact told most of the story. A function either worked or it did not. A screen either did what the brief asked or it did not. Understanding could be inferred from the result because the result could only come from the student.
AI in the loop breaks that inference. A clean function and a clear explanation no longer belong to the same source. A marker reading only the final build has to guess which parts the student worked out and which parts arrived already formed. PRISM Framework gives a marker four specific places to look, so the guess is replaced by a reading.
Workflow and Framework together. The Workflow puts evidence of thinking into the README as the work happens. The Framework reads that evidence under four lenses and maps it back to the criteria the course already uses. The two are designed to sit in the same submission.
The four lenses
Each lens answers a question most markers already ask. Nothing below replaces existing criteria. The lenses are a way of organising what a marker is looking for inside an AI-assisted submission.
Output
Does the final build meet the brief? The same question traditional assessment asks, answered from the same artefact: the working repo, the build, the tests.
Process
Is there a readable trace of how the work was built? Problem statement, first attempts, AI exchanges, and the path from one to the other.
Decisions
Are choices explained? Rejected options, corrected model output, trade-offs the student made and the reasons they give for them.
Understanding
Can the student account for what they produced? The reflection section of the README, read against the rest of the trace.
Output
Output is the familiar ground. The build runs. The function returns the right values for the stated inputs. The interface behaves on the paths the brief describes. Markers already have criteria for this, and the Framework does not change them.
What changes is the weight. In a traditional submission, Output carried almost all the marks because it carried almost all the visible evidence. In a PrismMO submission, Output is one lens of four, and it answers a narrower question: does the code do what it is supposed to do?
Process
Process is read from the README and the commit history. A marker is looking for a route: how the student moved from the brief to the build, including the AI exchanges along the way.
- the brief restated in the student's own words
- an unaided first attempt, with its limits visible
- prompts and model replies, with notes on what was kept
- a short account of how the final build was assembled
A submission can score well on Output and still have a thin Process. The Framework treats that as a signal to read the other two lenses carefully, not as a failure on its own.
Decisions
Decisions are the places where the student chose one thing over another. A rejected model reply. A threshold the student changed. A library they declined to use. A test case they added because the brief was ambiguous.
Strong signal: a student corrects a model reply and says why in one or two lines. The correction is in the code, the reason is in the README. The two line up.
Weak signal: model output pasted into the repo with no commentary, or a reflection that names decisions the rest of the README shows no trace of.
Understanding
Understanding is read last. By the time a marker reaches the reflection section, they have already seen the problem, the first attempt, the AI exchanges, and the final build. The reflection either holds against that trace or it does not.
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.
A reflection like this is short, specific, and checkable. Each claim can be traced back to a section of the README or a line of code. That is what Understanding means under the Framework: the student can account for what they produced, and the account matches the trace.
Reading the README through the Framework
The Framework does not ask the student to produce anything new. It is a reading order for the README the Workflow has already populated.
| Lens | Where to read | What a strong signal looks like |
|---|---|---|
| Output | Repo, build, tests | Brief is met; tests pass; edge cases handled |
| Process | Problem, Design and planning, AI section | First attempt is visible; AI exchanges are recorded in the moment |
| Decisions | AI section, Dev decisions | Rejected options and corrections are named with a reason |
| Understanding | Reflection | Claims in the reflection match the trace in the rest of the README |
Mapping to the criteria you already use
Most programming modules already assess the things the four lenses describe. The Framework is a translation layer: it gives existing criteria a clearer place to be evidenced in an AI-assisted submission.
| Typical module criterion | Framework lens | Where the evidence sits |
|---|---|---|
| Programming fundamentals | Output, Process | Final code, and the iterations that produced it |
| Problem analysis | Process, Decisions | Problem statement and the constraints the student names |
| Tool and AI use | Decisions | AI section: prompts, replies, what was kept or changed |
| Reflection and evaluation | Understanding | Reflection section, read against the full README |
| Testing and validation | Output, Process | Test files and the Testing section of the README |
The mapping above is a starting point, not a fixed template. Each module has its own wording, and the Framework is meant to sit under that wording, not on top of it.
What the Framework does not do
- it does not introduce new assessment criteria
- it does not replace an awarding body's marking grid
- it does not assign weightings between the four lenses
- it does not mark the submission for you
The weightings, the grid, and the final judgement stay with the lecturer and the module they teach. The Framework gives that judgement a cleaner evidence base to work from.
PrismMO is not a detection tool. The Framework does not try to identify AI output or flag it. Detection is the wrong question. Evidence of thinking is a better one, and the four lenses are built to read for that evidence, not against the model.
Run it on one submission
The easiest way to see whether the Framework fits a module is to read one submission under the four lenses and compare it to the module's usual marking round.
- Pick a recent submission that was handed in with a repo and a README.
- Read the repo once for Output. Note what the criteria would normally say.
- Read the README once under Process, then Decisions, then Understanding, in that order.
- Compare the reading to the mark you would have given from the final build alone.
Keep thinking visible.