ExpirySignal (Artifact v1.0.1) [ID: EXP-01]
ExpirySignal is a self-hosted expiration signal primitive.
It records whether an expiry timestamp (or window) exists for a subject or scope and returns the current expiry signal at read time.
ExpirySignal exists to keep time-based state explicit, decoupled, and auditable as a first-class primitive, rather than an incidental field buried inside unrelated domain tables or background job logic.
ExpirySignal does not schedule actions, revoke tokens, or enforce outcomes.
It only emits whether an entity is expired at read time.
What it emits
- Expired
- Not expired
What it does NOT do
- Does not authenticate identity
- Does not authorize actions
- Does not block requests
- Does not run background jobs or scheduled execution
- Does not revoke sessions or invalidate tokens
Typical use
Before granting time-bound access (trial, temporary grant, cooldown, lockout), your application queries ExpirySignal and explicitly decides how to handle an expired signal.
Critical rule
Not expired ≠ authorized.
Absence of an expiry record is not permission.
SimpleStates emits state. Your system implements outcomes.
Self-hosted. Signal-only. Deterministic behavior.
Failure modes
- Clock skew / time mismatch → different readers can disagree
- Expiry write is missing or delayed → reads can return “not expired” incorrectly
- 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 “not expired” as permission → your application can allow actions when it should not