Skip to main content
Security and complianceGovernment

Every score change needs to be explainable a year later

Scores get corrected — an item is voided, a key is fixed, a session is regraded. Whether that is defensible depends on what was recorded at the time.

2 min read

ST

Written by

Seratlas Team

Engineering and delivery

2 min read

We build and operate assessment software. We write here about the parts that are harder than they look.

A published score will sometimes be wrong. An item turns out to have two defensible answers, a key was entered incorrectly, a session was interrupted and rerun. None of these is a scandal; all of them are ordinary, and all of them require changing a number somebody has already been told.

The scandal is being unable to explain, eleven months later, why the number is different.

What an appeal actually asks for

Not "is this score correct". The question is narrower and harder: what produced this score, what changed, who decided, and on what basis. A system that stores only the current value can answer none of those, and the gap is discovered at the worst possible time — with a specific candidate waiting and a regulator copied in.

The record that answers it

The responses, separate from the score

The candidate's raw responses and the scoring that was applied to them are two different facts, and conflating them makes every recomputation destructive. Keeping responses immutable means a corrected key produces a new score from the same evidence, rather than an overwritten score with no evidence at all.

The scoring rules as they stood

A key, a rubric, and a pass mark are versioned objects. Recomputing a two-year-old sitting under today's rules produces a defensible-looking number that answers the wrong question. The record has to say which version was in force.

A reason, in words, attached to the change

This is the field systems omit, because it cannot be derived. Every other part of the trail can be captured automatically; the reason has to be typed by the person authorising the change, which means the interface must require it. A free-text field nobody can skip produces a worse-formatted and far more useful record than a dropdown of six categories.

Who, and under what authority

An actor, a timestamp, and the role the action was taken under. Roles change; recording the role at the time of the action is what keeps the trail readable after a reorganisation.

Two mistakes worth naming

Updating a score in place and relying on backups for history. Backups establish what the system held on a date; they do not establish who changed what, and reconstructing a decision from two snapshots is not a record, it is an inference.

Logging to a system with a retention period shorter than the appeal window. Ninety-day log retention behind a two-year certification challenge period is a gap that looks like a configuration detail and functions as an inability to respond.

The design consequence

Scores are derived values, not stored facts. Treating them that way — responses plus a versioned rule set plus a recorded decision, producing a score — is what makes every question about a score answerable by replay rather than by memory.

Common questions

It is necessary and not sufficient. A log of state transitions with no reason attached tells you a score changed but not why, and "why" is the whole content of an appeal response.

Fewer people than can view one, and never the same person who authorises the change. The separation matters less for preventing misconduct than for making the record credible when it is questioned.

Building something like this?

If any of the above is a problem you are currently having, we are happy to talk about it without a sales process attached.