Legitimate non-response protocol (rules and tests)
In AI systems, answering by plausibility is easy. Refusing correctly is difficult. Yet in an interpreted web, legitimate non-response is often the safest output: it prevents illegitimate inference, avoids creating interpretive debt, and protects the authority boundary.
This framework formalizes an opposable protocol: when to refuse, how to refuse, which proof conditions matter, and how to test that refusal is triggered correctly.
Operational definition
Legitimate non-response is a governed output in which the system refrains from answering because the required authority, proof, perimeter, or response conditions are not satisfied.
Why this protocol is central
Without a refusal protocol, systems tend to complete the gap with coherence. That behaviour may look helpful, but it turns uncertainty into ungoverned decision.
Application surfaces
The protocol applies to identity, authority, eligibility, recommendation, conflict arbitration, and any surface where a smooth answer would overstep the canon.
Typology of refusals
Legitimate non-response can arise from several causes:
- outside perimeter;
- missing proof on critical attributes;
- unresolved authority conflict;
- identity ambiguity;
- insufficient context;
- inaccessible or non-admissible source surface.
Rules (NRL-1 to NRL-10)
NRL-1: out-of-scope refusal
If the question exceeds the declared perimeter, the system should refuse rather than improvise.
NRL-2: refusal without proof on critical attributes
Where identity, authority, or eligibility requires proof, absence of proof blocks the answer.
NRL-3: refusal under non-arbitrable authority conflict
Conflicting sources do not justify synthetic certainty.
NRL-4: identity refusal
If the system cannot distinguish the relevant entity, it must suspend the answer.
NRL-5: insufficient context
A missing condition should lead to clarification or refusal, not silent filling.
NRL-6: bounded explanation
A legitimate refusal should state why the answer is blocked without pretending to know what is unavailable.
NRL-7: traceability
The refusal should remain explainable in terms of missing proof, perimeter, or conflict.
NRL-8: canonical redirection
Where possible, the refusal should redirect toward the right canon or clarification page.
NRL-9: testability
Refusal logic should be testable under known edge cases.
NRL-10: no punitive tone
Legitimate refusal is a governance output, not a moral judgment.
Why this protocol matters
Non-response becomes a trustworthy output only when it is explicit, bounded, and reconstructible. Otherwise, abstention appears arbitrary.
NRL-5: refusal for undated state
A system should refuse when a dynamic state is asserted without a valid time reference.
NRL-6: refusal of gap-filling
The model must not invent the missing link that would make an answer look complete.
NRL-7: refusal under capture signals
If the environment shows signs of interpretive capture, the system may need to suspend the answer rather than amplify the capture.
NRL-8: governed and useful refusal
A refusal should still orient the user toward the right canon, clarification, or required missing evidence where possible.
NRL-9: refusal traceability
The reason for refusal should be reconstructible in terms of perimeter, proof, conflict, or state insufficiency.
NRL-10: periodic validation
Refusal logic should be tested over time, especially after major releases or correction campaigns.
Refusal model (recommended format)
A mature refusal can often be structured as:
- why the answer is blocked;
- which condition is missing or unresolved;
- where to go next if a canonical clarification exists.
Test battery (NRL-T1 to NRL-T8)
NRL-T1: out-of-scope tests
Check whether the system refuses questions outside the declared perimeter.
NRL-T2: authority-conflict tests
Verify that unresolved conflicts do not produce synthetic certainty.
NRL-T3: identity-collision tests
Test whether ambiguity between neighbouring entities leads to refusal when proof is insufficient.
NRL-T4: dynamic-state tests
Check behaviour when the state is time-sensitive or stale.
NRL-T5: capture tests
Observe whether a saturated external framing can force an unauthorized answer.
NRL-T6: multi-turn tests
Ensure that the system does not silently overstep after several conversational turns.
NRL-T7: multi-formulation tests
Refusal should remain coherent across equivalent phrasings.
NRL-T8: post-release regression tests
Release changes should not silently weaken refusal logic.
Expected artefacts
Useful artefacts include refusal templates, authority maps, edge-case test batteries, audit logs, and links to canonical clarification pages.
FAQ
Isn’t refusal a bad user experience?
Not if it prevents a false authoritative answer. A bounded refusal is often a better user experience than an unjustified certainty.
How do you avoid refusing too often?
By clarifying the canon, tightening authority logic, and asking for clarification when a full refusal is not required.
What is the link with the Q-Layer?
The Q-Layer governs whether an answer is authorized at all. Legitimate non-response is one of its key outputs.