Fail closed is not stupidity
When an action has significant consequences, continuing with incomplete data may be worse than stopping. The system must distinguish tolerable degradation from a condition that invalidates operation.
Block with an explanation
A good block says which condition is missing, what evidence was expected and who can resolve it. “I cannot” without context is frustrating; “approval X is missing for evidence Y” is operational.
Refusal is a valid output
Designing only the successful path forces improvisation when something breaks. Including blocked states in the contract turns uncertainty and failure into expected behavior.
Blocking should be an explicit state
A generic error does not distinguish technical failure from a deliberate decision not to continue. States such as insufficient evidence, authority required or dependency unavailable let operators and automations know which intervention is appropriate.
Do not fill gaps with imagination
When critical data is missing, a model can still produce a plausible answer. Architecture needs to know which fields or sources are mandatory for a conclusion and prevent fluent language from substituting for the requirement.
Escalate with useful context
A productive block explains which condition is missing, what was attempted and which evidence would allow continuation. The person receiving the case should not have to restart from zero or interpret an opaque “I can’t.”
Operational pressure does not change authority
Urgency does not magically create permissions or evidence. It may activate a predefined emergency path, but that path needs its own authority and record. Otherwise every urgent case erodes the boundary until it becomes irrelevant.
Measure blocks to improve the system
A high number of correct blocks may reveal an unstable source or a process that asks for too much intervention. Recording them improves architecture without removing the ability to stop. The goal is to reduce unnecessary blocks, not force completion.
A useful test
One concrete way to put this idea under pressure is to construct cases deliberately missing a source, permission or approval and verify that the system stops with an actionable explanation rather than completing the task through another path. The test should not ask only whether an answer appears, but which state remains, what evidence is preserved and whether another operator can understand why the system behaved that way. This turns an editorial principle into an observable property and exposes places where architecture still depends on invisible assumptions.
What this note does not claim
Blocking should not become an excuse for fragility or poor experience; blocks should be specific, measurable and reduced when the process can be made safe without losing the boundary. This distinction matters because a good practice stops being useful when it becomes a universal promise. The goal is to make one design boundary explicit so it can be discussed, tested and adapted to the domain while facts, inferences, permissions and decisions remain separate.