Negative Capabilities
A negative capability answers a narrow question: is there an explicit reason this action must not occur?
DenySignal emits that fact. It does not authorize, block, or enforce.
Failure mode of allow-lists
Allow-based systems often encode logic like:
allowed = conditionA && conditionB && conditionC;
This can fail quietly when:
- State is missing
- Inputs are stale
- A new case is added but not wired everywhere
- Absence of information is interpreted as permission
Negative capability framing
A deny-first signal asks a narrower question:
- Is there an explicit denial fact present?
If the answer is yes, your application can decide how to react. If the answer is no, that means only that no denial fact is currently known.
Invariants
- Not denied ≠ permitted
- Absence of a denial fact is not an allow-list
- Denial state is not authorization
- Returned state is application-evaluated
Negative capabilities preserve uncertainty instead of collapsing it into false confidence.
Failure modes
- Stale reads cause denial to persist longer than intended
- Missing writes make intended denial invisible
- Identifier mismatch returns the wrong subject or scope
- Operators forget to remove denial records
These are signal failures. Your application still owns the response.