Confirmation governance is its own grant
Being able to rename a node type must not imply being able to disarm its gate. And an actor who cannot see the setting must not be able to change it by saving the form it is hidden from.
The rule
- Confirmation governance is controlled by a dedicated administrative authority, separate from the authority to administer node types, and restricted.
- Where an actor does not hold it, the governance settings are not shown, and a save by that actor must leave the stored governance mapping byte-identical: a setting that was never stored stays unstored, so the node type keeps deriving its requirement (RT-GATE-7).
- The strength of the gate is exactly the strength of who holds this authority and who may edit workflows.
What it means
The authority to administer node types does not carry this one. An actor who can rename, recategorise or otherwise edit a node type still cannot touch its confirmation governance without the separate, dedicated authority — and without it, the governance controls are not merely disabled, they are not shown at all.
The clause a careful reader would miss is what happens to the rest of the save. An actor without the authority can still save the node type for everything the form does show them; the governance mapping simply has to survive that save untouched, byte for byte, rather than being silently reset to whatever the hidden controls would have defaulted to.
Example
A node type's stored governance before either actor saves it:
{ "policy": "ask", "author_controls": ["require"], "dynamic_controls": ["require"] }An actor without the dedicated authority still saves the node type — the label changes, the governance does not:
{ "label": "Renamed Gated Type" }The stored governance above is exactly what a second read of that node type returns afterward.