Signing & version history

A Material Impact Assessment is only worth anything if a qualified person has signed it and the firm can show how it has changed over time. Chronity makes both first-class.

Signing a use case

Open a use case from the Taxonomy list. While it's a draft, it's a proposal — the classifier doesn't treat it as authoritative. When you're satisfied it reflects your firm's professional position, you sign it. Signing:

• stamps it with your name and the date,
• moves it to signed status,
• makes it the version the classifier applies from that point on.

Signing is the moment your professional judgement attaches to the document. Treat it with the seriousness you'd give signing any compliance artefact — because that's exactly what it is.

Versions, not overwrites

You never edit a signed use case in place. Editing a signed use case creates a new version as a draft; the old signed version stays in the record. When you sign the new one, it becomes current and the previous version becomes history. Nothing is lost — the question "what did our MIA say in March, and who decided to change it?" always has an answer.

The version-history timeline

On a use case's detail page there's a version history timeline: newest first, each version showing its status, who signed or updated it, and when. For any version you can open a diff against the previous one — a side-by-side, word-level comparison of both the description and (more importantly) the standing reliability analysis, with additions and removals marked. There's a clear marker at the draft → signed boundary, so you can see exactly what changed between one signed MIA and the next.

This matters more than it might sound. The standing reliability analysis is the narrative an auditor will scrutinise; being able to show precisely how it evolved, and that each change was a deliberate signed decision, is a strong position to be in.

What good practice looks like

• Sign deliberately, not reflexively. A signed use case is your firm asserting a professional position. Read the standing analysis as if you'd have to defend it.
• Revise when reality changes, not on a schedule. A new tool, a new kind of work, a reliability concern an alert surfaced, a use case the review queue keeps choking on — those are the triggers to cut a new version.
• Use the diff before signing a revision. Look at exactly what you're changing in the standing analysis. It's the cheapest possible review and it's right there.

Signing changes classification going forward

A new signed version applies to work classified after it's signed. Historical observations keep the classification they were given under the taxonomy version in force at the time — which is correct: the record reflects the firm's position as it was, not retroactively rewritten.

Next: Track 1 sign-off.