Versions and Scoring
This is the whole design of the module, and every other rule follows from it: a response binds to a version, never to an instrument.
Where to find it
Architect Panel → Forms:
- Instrument Versions — each published edition
- Assessment Instruments — where a new version is drafted and published
Why this matters
Assessment tools change. Questions get added. Thresholds move. A band that was "medium" in 2019 is "high" in 2026 because the guidance changed.
If a completed response pointed at the instrument, re-opening a 2019 assessment would score it against 2026 rules. A risk assessment that silently re-scores itself is worse than no assessment at all — somebody relied on the original number, acted on it, and it is no longer there to defend.
That is the scenario this design exists to make impossible.
It is prevented structurally, not by convention
The responses table has no instrument column at all. Not "should not be used" — it does not exist, so the wrong thing cannot be written, by any code path, ever.
Published versions are immutable
Once a version is published you cannot edit its items or bands. Editing them would change what existing responses mean, retrospectively and invisibly.
To change an assessment, publish a new version. Old responses keep pointing at the old one and continue to say what they always said.
Scores are stored, not recomputed
Each answer's score is written when the answer is given. Otherwise editing an option on a draft that later gets published would re-score completed work — the same problem by a different route.
What this gives you
- A 2019 assessment reads today exactly as it read in 2019.
- You can show which version of the tool was in force when a decision was taken.
- Trend reporting across a version change is honest, because you know which version each response used.
All three are questions asked in serious case reviews, inspections and litigation, and "the system recalculates it" is not an acceptable answer to any of them.
Comparing across versions
The flip side: scores from different versions are not automatically comparable. If you change the thresholds, a run of "high" outcomes after the change may reflect the change rather than the population.
When you publish a new version, note the date, and treat trend lines crossing it with care rather than reading them as a single series.
Worked example
A safeguarding triage tool is revised after a serious case review, adding two items and lowering the threshold for the highest band. Cases triaged before the change keep their original scores and bands. A report on triage outcomes over two years shows the version change as a marked line, so the rise in high-band cases afterwards is read correctly — as a threshold change, not a deterioration.
Recommendations
- Version deliberately and note why in the version description.
- Never try to "fix" a published version. Publish a new one.
- Mark version changes on any trend report.
- Keep old versions available — they are the record of what was asked at the time.