[SC-17596] Note that a risk tier template can move between organizations

[juanmleng]

Pull Request Description

What and why?

Manage risk tier templates covered the whole lifecycle of a template inside one organization — create, publish, version, duplicate, archive, restore, delete — and said nothing about carrying one to a different organization, which an organization template export supports. A governance admin who wants to reuse a methodology they have already built looks on this page first and finds nothing.

Adds a short Move a template to another organization section before What's next: a paragraph saying the move is an Admin UI task, that only the Active version of a lineage travels, that it arrives as a Draft to be published in the destination, and that governance stage lists and workflow bindings are not carried — plus one callout for the failure mode.

Deliberately short. Every other object in an organization template export — inventory record types, document types, workflows, finding types, inventory fields — was documented as a release-note bullet and nothing more. The direct sibling is finding types, in 25.09: "Export/import: Organization templates now include configurations for finding types." Risk tiering already has its equivalent release note on the implementing backend PR, landing in the 26.09 plan, and it covers the headline plus the drafts caveat. So this section records only the two things that have no signal anywhere else: stage lists and workflow bindings not travelling, and a template being skipped whole and silently when the destination organization lacks an inventory field one of its components scores. An earlier draft of this carried seven bullets and a companion section in the installation docs; both were cut as out of proportion to how the siblings are documented.

Before: the page implied a template lives and dies inside one organization. After: a reader knows the methodology is portable, knows it needs publishing on arrival, and knows the one way it can go missing without telling them.

How to test

skills/validmind-docs-coverage/scripts/render-pages.sh guide/risk-tiering/manage-risk-tier-templates.qmd

Renders clean — the only warnings are the pre-existing Unable to resolve link target: validmind/validmind.qmd ones, which appear on untouched pages too. git diff --check is clean. The new heading renders the anchor #move-a-template-to-another-organization and the callout renders as a note.

What needs special review?

Both retained claims were read off the merged implementation rather than the story, and one differs from how the story described it. The story said a factor whose field key is missing in the destination is skipped with a warning; the shipped code skips the whole template instead, because dropping one component leaves the saved thresholds calibrated to a score range that no longer exists, and a factor with no components scores nothing. The section documents the shipped behaviour.

The other is that only the Active version of a lineage is exported — Draft-only and fully-archived lineages are left out — which is worth a check from someone who knows the export path.

Also worth a view on placement: this went on Manage risk tier templates rather than Working with risk tiering because it is something you do to a template, alongside the other lifecycle operations, rather than a concept.

Dependencies, breaking changes, and deployment notes

Documentation only. No dependencies — the section is self-contained and links nowhere new.

Release notes

The risk tiering guide now explains that a risk tier template can be carried to another organization through an organization template export: only the active version travels, it arrives as a draft that has to be published before assessments can use it, and it is skipped entirely if the destination organization is missing an inventory field the template scores. Learn more ...

Checklist

• What and why
• Screenshots or videos (Frontend)
• How to test
• What needs special review
• Dependencies, breaking changes, and deployment notes
• Labels applied
• PR linked to Shortcut
• Unit tests added (Backend)
• Tested locally
• Documentation updated (if required)
• Environment variable additions/changes documented (if required)

[cachafla]

@juanmleng we don't need this since the Admin UI is not a customer facing feature.