One assignment, seen two ways

The assignment

A first-year programming task. Write a function that takes an annual income and returns the tax owed under UK income tax bands. The student is expected to handle the personal allowance, the basic-rate band, and the higher-rate band, and to submit a working build in a GitHub repo with a README.

How the submission usually arrives

In a standard submission, the README explains what the program does and the repo contains the final function. The code compiles and returns the right numbers for the test cases in the brief.

function calculateTax(income) {
  if (income <= 12570) return 0;
  if (income <= 50270) return (income - 12570) * 0.2;
  return (50270 - 12570) * 0.2 + (income - 50270) * 0.4;
}

The artefact is fine. The problem is what sits around it. From the submission alone, a marker cannot tell where the function came from, which parts the student worked out, which parts came from a model, and whether the numbers were understood or copied. The code is the evidence and the reasoning at the same time, and those two things are no longer the same.

The PRISM Workflow inside the same task

PrismMO does not replace the assignment. The task stays the same. The repo stays the same. The README stays the same file. What changes is what the README carries. Five stages sit inside the work and leave a trace the student can point to.

Walkthrough

Problem

The student writes the problem into the README before touching an editor.

Given an annual income, return the tax owed using three bands: zero up to 12,570, twenty per cent up to 50,270, forty per cent after that. Return net income alongside the tax. Treat negative income as invalid. No allowance for National Insurance or Scottish rates.

Short, but it pins down what the code has to do and what it does not have to do. The marker can now read the rest of the work against a problem the student has defined.

Respond

A first pass, written before any model is opened.

function calculateTax(income) {
  let tax = 0;
  if (income > 12570) {
    tax = (income - 12570) * 0.2;
  }
  return tax;
}

One band handled. Higher-rate income is wrong. The student knows it. The value of this snippet is not that it works. It is that it marks a starting position that a marker can compare the final code to.

Interact

The student asks a model for help with the higher-rate band and records the exchange.

Write a JavaScript function for UK income tax bands.

if (income > 50000) {
  tax = income * 0.4;
}

The student notes, in the README, what is wrong with the reply: the threshold is 50,270, not 50,000, and the forty per cent rate applies to the income above the higher threshold, not to the full amount. The correction happens in the next block.

if (income <= 50270) {
  tax = (income - 12570) * 0.2;
} else {
  tax = (50270 - 12570) * 0.2;
  tax += (income - 50270) * 0.4;
}

Synthesize

The final function, and a two-line note in the README about how it was built.

function calculateTax(income) {
  let tax = 0;
  if (income > 12570) {
    if (income <= 50270) {
      tax = (income - 12570) * 0.2;
    } else {
      tax = (50270 - 12570) * 0.2;
      tax += (income - 50270) * 0.4;
    }
  }
  return tax;
}

Make Visible

My first version only handled the basic rate. The model gave me a shape for the higher band but used the wrong threshold and taxed the full income at forty per cent. I kept the structure, fixed the threshold, and changed the calculation to apply forty per cent only to income above 50,270. Next time I would write a small table of expected results first and test against it before touching the code.

Two paragraphs. The student has said what they did, what went wrong, and what they would change. The marker is no longer guessing.

Before and after

Where this lives in the README

Nothing on this page lives in a new file or a new platform. Every stage of the PRISM Workflow maps to a section of the README the student already has to write.

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 PRISM Framework reads the work

The Workflow makes the thinking visible. The Framework turns that visibility into marks against criteria the lecturer already uses.

The final program is not the evidence. The trace that produced it is.

Start with one assignment

PrismMO is built to work inside a module, not replace it. The first step is one task, one brief, one marking round with the PRISM Workflow in place. No new platform, no new toolset, no change to the criteria the module already uses.

1. Pick a task students already hand in with a README and a repo.
2. Add the PRISM sections to the README template for that task.
3. State, in the brief, that AI use is expected and that the README carries the evidence.
4. Mark against the criteria you already use, reading the README through the four Framework lenses.