Skip to content
SYSNOMINAL|BUILDv2026.06.27|REGIONSELF_HOST

Signal Composition

DATA PLATE
DOC
Signal Composition
ID
SS-NOTE-COMP-2026.06
REV
A
SURFACE
PUBLIC
MODEL
State is queried. Decisions are made. Actions remain application-owned.
PURPOSE
Supporting example for cross-signal decision inputs.
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 submitted evidence about the decision moment after your application evaluates the facts.

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 reads facts.
The application chooses an action.

ROLE OF STATEMIRROR

StateMirror belongs after evaluation. It can preserve structured facts your application considered at a decision moment, including companion signal outputs when your application submits them.

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

Evidence Lanes are optional canonical evidence shapes. They are not required formats, and StateMirror Core does not validate, enforce, or interpret them as policy.

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?
  • Submit a StateMirror snapshot or skip evidence preservation?

SimpleStates does not answer these questions. That responsibility remains application-owned.

← Notes·Composition Examples