ExpirySignal — Spec Sheet

[ DOWNLOAD DATASHEET ]

Inputs

• Entity identifier (user, account, token, scope, or custom key)
• Expiry timestamp or expiry window written by your system
• Optional context identifier (scope, feature, environment)
• Time source (system clock) used at read time

Outputs

• expired (boolean)
• expires_at (ISO timestamp)
• cause_code (string)
• renewable (boolean)

Renewable field

• renewable is operator-provided metadata stored alongside the expiry record.
• It is not computed from rules.
• It does not grant permission to renew.
• If renewal is allowed, your application must implement the renewal workflow and write a new expiry record explicitly.

Guarantees

• Returns stored expiry state as of read time
• Does not mutate state on read
• Does not execute side effects

Non-guarantees

• Clock correctness or clock synchronization
• Timeliness of expiry writes
• Consistency across distributed systems
• Authorization correctness
• Security, safety, or compliance outcomes

Invariants

• Not expired ≠ authorized
• Expiry state ≠ permission
• Absence of an expiry record is not permission
• Returned state is advisory only

Failure modes

• Clock skew / time mismatch → different readers can disagree across distributed deployments
• Missing/delayed expiry write → reads can be wrong
• Identifier mismatch → wrong entity state returned
• Partial writes / database inconsistency → stale or incorrect reads
• Network/database failure → reads can fail or time out

Performance characteristics

• Read latency: typically a single PostgreSQL read + time comparison
• Concurrency: limited by your PostgreSQL connection pool and indexes
• Scheduling: none (no background execution)
• Time source: your clock (correctness and sync are your responsibility)

Out of scope

• Session invalidation
• Token revocation
• Request blocking
• Background execution
• Policy definition
• Automatic enforcement