Version the methodology as data

A score can change because the evidence changed or because the rules changed. The record needs to distinguish those events.

Give each published methodology an immutable version identifier. Store the full definition used for a run, or store a content-addressed reference to a definition that cannot be edited in place. The definition should include question identifiers, accepted answer shapes, option codes, rule expressions, weights, thresholds, labels, explanation fragments and report mappings.

Keep stable identifiers even when display wording changes. A question identifier such as data_governance_ownership should not be replaced merely because an editor improves the sentence shown to respondents. If the meaning or accepted evidence changes, create a new methodology version and record the migration decision.

Represent rules in a form that can be reviewed without reading application control flow. That may be configuration with a small expression language, explicit decision tables stored as data, or ordinary code with generated methodology documentation. Whichever form is chosen, validate it before publication. Reject duplicate identifiers, unreachable levels, weights that do not satisfy the declared scheme, references to missing questions and explanation text that has no corresponding outcome.

Do not edit a methodology version after results exist. Correct a serious error by publishing a replacement version and documenting which runs are affected. Recalculation should be an explicit operation. Keep the original result, the new result, the reason and the actor who authorised it.

A methodology change needs review at two levels. Subject-matter reviewers confirm that the rule expresses the intended judgement. Technical reviewers confirm that the engine executes it correctly. A pull request can show both the readable rule change and the fixture changes it requires.