SYSNOMINAL|BUILDv2026.01.01|REGIONSELF_HOST

Boundary Essay

DATA PLATE
DOC
Boundary
ID
SS-ESSAY-BOUNDARY-2026.01
REV
A
SURFACE
PUBLIC
MODEL
State is queried. Decisions are made. Actions are executed elsewhere.
PURPOSE
Defines responsibility boundaries for signal-only infrastructure.
REF
Boundary
ESSAY FRAME

SimpleStates exists to separate factual state from application behavior.

Its tools emit deterministic signals. They do not authenticate users, authorize actions, block requests, run workflows, or decide outcomes.

THE BOUNDARY RULE

SimpleStates stops at state.

Your application owns identity, business rules, authorization, gating, side effects, human overrides, and final judgment.

This boundary is not a limitation. It is the product.

STATE ≠ OUTCOME

Most boundary failures begin when a system treats a readable fact as if it were an executable decision.

  • State is a fact your system can read.
  • Outcome is behavior your system causes.

SimpleStates builds state primitives. Your application implements outcomes.

WHY SIGNAL-ONLY EXISTS

Outcome logic is application-specific. It depends on routes, domain rules, user experience, risk posture, and operational judgment.

A generic outcome layer tends to become one of three things:

  • over-promised and incorrect
  • too invasive to integrate safely
  • a hidden dependency that becomes a new outage surface

SimpleStates refuses that role. It emits a small set of facts at read time. Your code decides what happens next.

NON-NEGOTIABLE SEMANTICS
  • Not denied ≠ permitted. It only means no denial signal is currently present.
  • Not expired ≠ authorized. It only means the expiry signal does not currently indicate expiration.
  • Plan state ≠ permission. It is one input among many in your own enforcement logic.
  • Evidence ≠ judgment. A snapshot can explain what was known; it does not decide whether the outcome was correct.
  • Absence of a restriction is not permission.
FAILURE MODES

SimpleStates is self-hosted. Your environment can misfire. Networks can fail. Databases can go down. Inputs can be stale, missing, or incorrect.

Your application defines how to behave when signals cannot be confirmed. That includes choosing fail-open or fail-closed behavior per use case.

SimpleStates emits stored facts only. It does not guarantee safety, correctness, or appropriateness for your domain.

WHO THIS IS FOR
  • Founders who want deterministic primitives
  • Teams who want to own outcome logic
  • Engineers who prefer explicit boundaries over platform promises
  • Builders who want facts they can inspect, compose, and explain later

If you want a plug-and-play access control system, SimpleStates is not that.

Self-hosted. Signal-only. No SLAs. No emergency support.

Back: index