Boundary Essay

Signal-only primitives. Self-hosted. Deterministic. No magic.

SimpleStates tools emit state signals. They do not enforce outcomes. They do not authenticate users, authorize actions, or block requests.

This page describes semantics and responsibility boundaries. It is not a tutorial, integration guidance, or a statement of best practice.

Most systems fail by mixing two different things:

• State (a fact your system can read)
• Outcomes (behavior your system causes)

SimpleStates builds state primitives. Your application implements outcomes.

Outcome logic is application-specific. It depends on your routes, your domain rules, your UX, and your risk model. A generic outcome layer becomes either:

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

SimpleStates refuses that role. These tools emit a small set of facts at read time. Your code decides what happens next.

• 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.
• Absence of a restriction is not permission.

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

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

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

• Founders who want deterministic primitives
• Teams who want to own outcome logic
• Engineers who prefer explicit boundaries over promises

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

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