SYSNOMINAL|BUILDv2026.01.01|REGIONSELF_HOST

DenySignal (Artifact v1.0.0) [ID: DNY-01]

DATA PLATE
INPUT
Operator writes (deny present / not present)
OUTPUT
Denial signal (read-time)
SIDE EFFECTS
None on reads
EXECUTION
Read-time only (no enforcement)
DEPS
PostgreSQL

[ DOWNLOAD DATASHEET ]

DenySignal is a self-hosted denial signal primitive (negative capability).

It records whether a denial flag exists for a subject or scope and returns the current denial signal at read time.

DenySignal exists to keep denial state explicit, decoupled, and auditable as a first-class primitive, rather than an incidental field inside unrelated domain tables.

DenySignal does not deny access, block execution, or authorize actions.
It only emits whether a denial signal is present.

What it emits

  • Denial present
  • Denial not present

What it does NOT do

  • Does not authenticate identity
  • Does not authorize actions
  • Does not block requests
  • Does not act as a firewall, WAF, or gateway

Typical use

Before performing a sensitive operation, your application queries DenySignal and explicitly decides how to handle a denial signal.

Critical rule

Not denied ≠ permitted.
It only means no denial signal is currently present.

SimpleStates emits state. Your system implements outcomes.

Self-hosted. Signal-only. Deterministic behavior.

Failure modes

  • Deny write is missing or delayed → reads can return “denial not present” while your system intended “denial present”
  • Subject/scope mismatch → reads can return the wrong signal for the wrong entity
  • Partial writes / database inconsistency → reads can be stale, incomplete, or incorrect
  • Network/database failure → reads can fail, time out, or return unexpected data
  • Interpreting “denial not present” as permission → your application can allow actions when it should not

Spec Sheet