SYSNOMINAL|BUILDv2026.01.01|REGIONSELF_HOST

Signal Composition

DATA PLATE
DOC
Signal Composition
ID
SS-NOTE-COMP-2025.12
REV
A
SURFACE
PUBLIC
MODEL
Applications compose facts. Applications decide. Applications enforce.
PURPOSE
Describes cross-signal composition boundaries and failure modes.
REF
Notes

Real systems rarely rely on one fact. They read plan state, denial state, expiry state, and local application context together.

Signal composition is useful, but it is not enforcement. Combining facts does not create permission. It creates an input set your application must evaluate explicitly.

WHAT COMPOSITION IS

Signal composition is the act of reading multiple SimpleStates primitives at a decision point.

  • PlanSignal answers: what plan or entitlement facts are known?
  • DenySignal answers: is an explicit denial fact present?
  • ExpirySignal answers: is this thing expired at read time?
  • StateMirror may preserve the evidence after your application evaluates it.

Your application reads these facts, applies its own rules, and owns the outcome.

WHAT COMPOSITION IS NOT
  • Composition is not authorization.
  • Composition is not permission.
  • Composition is not policy enforcement.
  • Composition is not a truth guarantee.
  • Composition is not a workflow engine.

SimpleStates returns facts. Your application decides whether those facts are sufficient, stale, missing, contradictory, or unsafe.

COMMON FAILURE MODE

Teams often collapse composition into a single boolean:

if (plan === "pro" && !denied && !expired) {
  allow();
}

This looks reasonable, but it hides the hard part: deciding what to do when one fact is stale, missing, delayed, ambiguous, or unavailable.

A boolean can make uncertainty disappear in code without making it disappear in reality.

INVARIANTS
  • Not denied ≠ permitted.
  • Not expired ≠ authorized.
  • Plan state ≠ access control.
  • Absence of a signal is not approval.
  • Successful composition is not successful enforcement.

Composition preserves facts.
Enforcement chooses an outcome.

ROLE OF STATEMIRROR

StateMirror belongs after evaluation. It can preserve the facts your application considered at a decision moment.

It does not validate the decision, recompute the signals, interpret the payload, or prove the outcome was correct.

It records the evidence your system chose to submit.

FAILURE HANDLING

When composition fails, your application must decide explicitly:

  • Fail open or fail closed?
  • Degrade capability or block entirely?
  • Retry, defer, escalate, or record a manual-review path?
  • Capture a StateMirror snapshot or skip evidence recording?

SimpleStates does not answer these questions. That responsibility stays outside the signal plane.

← Notes·Composition Examples