Signal Composition
Real systems rarely rely on a single signal. Most decisions emerge from the composition of multiple independent facts.
This note documents where signal composition breaks down, and why SimpleStates refuses to collapse composition into implicit authorization.
Signal composition is the act of reading multiple signals and evaluating them together at a decision point.
- PlanSignal answers: what this entity is entitled to
- DenySignal answers: what must not occur
- ExpirySignal answers: what is still valid in time
Your application reads these facts, then decides what action to take.
- Composition is not authorization
- Composition is not permission
- Composition is not policy enforcement
- Composition is not a truth guarantee
Combining signals does not magically produce a correct outcome.
It produces a set of facts your system must interpret.
Teams often collapse composition into a single boolean:
if (plan === "pro" && !denied && !expired) {
allow();
}This looks reasonable. It is unsafe.
Missing data, stale reads, clock skew, or partial writes silently turn into permission.
- Not denied ≠ permitted
- Not expired ≠ authorized
- Plan state ≠ entitlement execution
- Absence of a signal is not approval
Composition preserves uncertainty.
Enforcement collapses uncertainty.
StateMirror exists after composition.
Once your system evaluates multiple signals and chooses an outcome, StateMirror can preserve what was known at that moment.
It does not validate composition.
It records the result of your judgment.
When composition fails, your system must decide explicitly:
- Fail open or fail closed?
- Degrade capability or block entirely?
- Retry, defer, or escalate?
SimpleStates does not answer these questions.
That responsibility is intentionally external.