Assessment Instruments

Assessment Instruments

Risk assessment, file review, supervision, appraisal, safeguarding triage. One engine, because they are the same object: a set of questions, answered about a record, producing a score and a band.

Where to find it

Architect Panel → Forms:

• Assessment Instruments — the console — build and publish instruments
• Instrument Versions — the published versions
• Instrument Items — the questions
• Instrument Bands — the score ranges and what they mean

Completed assessments appear as a pane on the record they were carried out against.

It ships inert: there are no instruments until you create one, so nothing can be assessed until you have decided what should be.

The parts

• An instrument — the named tool. "Tenancy risk assessment", "Case file review".
• A version — a specific published edition of it.
• Items — the questions, each with answer options carrying scores.
• Bands — score ranges with meanings. 0–9 low, 10–19 medium, 20+ high.
• A response — one completed assessment against one record.

Building one

1. Create the instrument and give it a clear name — it will appear on the record.
2. Add items. Keep the wording exactly as your policy or guidance words it; an assessment paraphrased by whoever built the form is an assessment that no longer matches the policy it implements.
3. Give each answer option a score.
4. Define bands and what each means in practice — not just "high" but what a high score obliges somebody to do.
5. Publish the version.

Bands should carry an action

A band that says "high" and nothing else leaves the decision exactly where it was. A band that says "high — refer to the safeguarding lead within 24 hours" turns the assessment into a process. Write the action into the band description.

Worked example — a housing tenancy risk assessment

Twelve items covering arrears, ASB history, vulnerability and property condition. Scores band into Standard, Enhanced and Intensive. Enhanced triggers a monthly contact obligation; Intensive triggers a joint visit and a management referral. The assessment is a pane on the tenancy record, so the current band is visible to anyone opening it.

Worked example — a legal file review

A supervising partner reviews a sample of matters quarterly against a fixed instrument: are the client care letters on file, is the risk assessment current, is the file note contemporaneous. The score gives a compliance position per fee earner over time, and the same instrument version is used across the whole sample so the results are comparable.

Recommendations

• Copy the wording from the source guidance rather than rewording it.
• Give every band an action.
• Keep instruments short. A forty-item assessment gets rushed, and a rushed assessment is worse evidence than a short honest one.
• Pilot with two or three assessors and compare their scores on the same case before rolling out.

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.