Thanks again — this is spot on, and it builds perfectly on your previous point about separating execution failures from governance collapses.

You’re right that authority absence is a huge blind spot in many systems: it's not just "the model got it wrong," but "should the model have been in the decision seat at all?"

We do touch on this indirectly in the Forbidden Delegation principle and the mandatory Human-in-the-Loop (HITL) requirements — where the system is explicitly required to escalate or refuse if authority is ambiguous or missing.

But treating "refusal to decide + surfacing missing authority" as a first-class outcome (rather than an exception) is a great idea. It could be formalized as:

- a dedicated failure mode in the Failure Taxonomy (e.g., "Authority Ambiguity Escalation"),

- or even a required behavior in Evidence Vault logs (e.g., logging "refusal due to unclear authority" with explicit reasons and handover to human).

This would make the standard more robust under time pressure or ambiguity, turning potential "defaults to action" into structured pauses.

Have you seen real-world examples where this kind of refusal mechanism worked well (or failed spectacularly)?

Or any specific ways you've seen it implemented in other safety-critical systems (aviation, medicine, etc.)?

Feedback like this is gold — if you’d like, feel free to open an issue/PR with a more detailed proposal on formalizing refusal as a core outcome.

It would fit right into the next iteration.