ExpirySignal (Artifact v1.0.1) [ID: EXP-01]
ExpirySignal is a self-hosted temporal validity primitive.
It records expiry timestamps or windows for a subject or scope and returns the current temporal validity fact at read time.
ExpirySignal keeps time-based state explicit, decoupled, and auditable as a first-class primitive instead of burying it inside unrelated domain tables or background job logic.
ExpirySignal does not schedule actions, revoke tokens, invalidate sessions, authorize users, or enforce outcomes.
It only emits whether an entity is expired at read time.
What it emits
- Expired
- Not expired
- Expiry timestamp
- Optional cause code and renewable metadata
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
- Does not grant renewal permission
Typical use
Before granting time-bound access such as a trial, temporary grant, cooldown, or lockout, your application queries ExpirySignal. Your application then evaluates the temporal validity fact and executes the outcome elsewhere.
Boundary rule
Not expired ≠ authorized.
Absence of an expiry record is not permission.
SimpleStates emits facts. Your system implements outcomes.
Self-hosted. Signal-only. Deterministic behavior depends on stored state and time source.
Failure modes
- Clock skew or time mismatch → different readers can disagree
- Expiry write is missing or delayed → reads can return “not expired” incorrectly
- Subject or scope mismatch → reads can return the wrong signal for the wrong entity
- Partial writes or database inconsistency → reads can be stale or incomplete
- Network or database failure → reads can fail, time out, or return unexpected data
- Interpreting “not expired” as permission → unsafe application behavior