Version the methodology as data

A score can change because the evidence changed or because the rules changed. Your records need to tell you which one happened.

Give every published methodology an immutable version ID. For each run, store the full definition that was used or a content-addressed reference to a definition nobody can edit in place. The definition should hold the question IDs, accepted answer shapes, option codes, rule expressions, weights, thresholds, labels, explanation fragments and report mappings.

Keep IDs stable when only the display wording changes, so a question ID like data_governance_ownership survives an editor improving the sentence respondents see. If the meaning changes, or the evidence you'll accept changes, that's a new methodology version, and you write down how you decided to migrate.

Rules should be readable without tracing application control flow. That might be configuration with a small expression language, decision tables stored as data, or ordinary code that generates its own methodology documentation. Whichever you pick, validate it before you publish. Reject duplicate IDs, levels nobody can reach, weights that don't fit the declared scheme, references to questions that don't exist and explanation text with no matching outcome.

Once results exist against a methodology version, don't edit that version. If you find a serious error, publish a replacement and document which runs it affects. Recalculating should be a deliberate step that keeps the original result, the new result, the reason and who authorised it.

I'd want two kinds of review on any methodology change. A subject-matter reviewer checks that the rule says what they meant it to say, and a technical reviewer checks that the engine actually runs it that way. One pull request can show both the rule change and the fixture changes that come with it.