DenySignal — Spec Sheet
Primitive type: Denial fact emitter
Execution model: Read-time lookup
Hosting model: Self-hosted
Determinism: Deterministic given stored denial state
Inputs
- Subject identifier such as user, account, token, scope, or custom key
- Optional scope or context identifier
- Operator-defined denial facts written by your system
- Optional reason, severity, or metadata if your deployment stores it
Outputs
- Denial present
- Denial not present
- Optional denial metadata if present in stored state
Guarantees
- Returns stored denial state as of read time
- Does not mutate state on read
- Does not execute side effects on read
- Deterministic for a given stored state
Non-guarantees
- Correctness of your denial policy
- Timeliness of denial updates
- Consistency across distributed systems
- Authorization correctness
- Security, safety, abuse-prevention, or compliance outcomes
Invariants
- Not denied is not permitted
- Denial state is not authorization
- Absence of a denial fact is not permission
- Returned state is application-evaluated
Failure modes
- Denial write missing or delayed → stale or incomplete state
- Identifier mismatch → wrong subject or scope returned
- Lookups may fail or return partial data
- Network or database failures may prevent reads
- Your application must define behavior when denial state cannot be confirmed
Performance characteristics
- Read latency: typically a PostgreSQL point lookup
- Concurrency: limited by your PostgreSQL connection pool and indexes
- Caching: not included; implement in your application if required
Out of scope
- Authentication
- Authorization
- Request blocking
- Enforcement logic
- Policy definition
- Firewall, WAF, or gateway behavior
- Auditing, alerting, or notifications
Implementation details
- Language: TypeScript (Node.js)
- Interface: HTTP or embedded application call depending on deployment
- Database: PostgreSQL
- Deployment: self-hosted service or embedded local component