Whether a node asks is a governance decision, resolved in order
Requiring confirmation is a decision an administrator makes about a node type, not a property of the code that runs it. The executor's own declaration is only the fail-safe used when governance has not spoken.
The rule
- A node's effective confirmation requirement resolves governance-first, in this order: an allowed dynamic escalation whose runtime input is truthy asks (RT-GATE-9); otherwise an allowed instance-level author choice (carried in the reserved confirmation configuration key) takes its value; otherwise the node type's stored policy,
askorskip; otherwise, with no policy stored, the requirement derives from whether the node's executor declares that it has side effects. - That derivation is performed at gate time from the executor itself and must never be baked into stored configuration, so an executor that adopts the declaration later re-gates existing configuration automatically.
- A node type that has never stored a governance mapping resolves to the defaults: authors may waive and may require, with no dynamic surface.
- A stored mapping is taken literally: an emptied list of allowed controls is a revocation, not a fallback to the defaults.
What it means
A stored mapping is never read as a hint. Where an admin has unchecked every control a node type's governance offers, that emptied list is the answer — revocation, not an instruction to fall back on the wider set a node type gets when nobody has stored anything at all. The two look alike (both are short, both restrict what an author can do) but only one of them is "nobody decided yet."
Example
A node type that has never stored a confirmation mapping gets the full default reach:
{ "authorControls": ["waive", "require"], "dynamicControls": [] }A node type whose admin stored a mapping with every control unchecked keeps exactly that, not the default:
{ "authorControls": [], "dynamicControls": [] }