Server Signals#

Purpose of Server‑Declared Awareness#

Server‑declared Awareness acts as the global anchor for the RTT‑App. It provides:

• A consistent interpretation of global clarity or drift.
• A shared reference point across all devices and platforms.
• A stable baseline that local signals can be compared against.
• A future‑proof path toward RTT‑Inside, where deeper sensing becomes optional.

The server does not explain why a state is declared. It simply publishes the current global condition.

Awareness Endpoint#

The RTT server exposes a simple JSON document at:

/.well-known/rtt-awareness

This endpoint returns a minimal, declarative structure such as:

{
  "clarity": "high",
  "drift": "low",
  "timestamp": "2026-02-28T20:00:00Z"
}

The app reads this document periodically, caches it, and merges it with local signals to compute the final Awareness state.

Signal Characteristics#

Server signals have several important properties:

• Canonical — they represent the authoritative global state for the RTT ecosystem.
• Lightweight — the payload is intentionally small and easy to cache.
• Permissionless — the app retrieves the document using standard network requests.
• Decoupled — server logic can evolve without requiring app updates.
• Non‑diagnostic — the server declares clarity or drift without exposing internal reasoning.

These characteristics ensure that server signals remain stable and predictable across versions.

How Server Signals Influence Awareness#

Server‑declared Awareness provides the global half of the merge model:

• When the server reports high clarity, local instability is interpreted as Local Drift.
• When the server reports low clarity, even stable local conditions may be interpreted as Global Drift.
• When both local and server signals indicate instability, the app enters the Drift state.
• When both are stable, the app reports Clear.

This relationship ensures that the app’s Awareness state reflects both immediate conditions and broader context.

Update and Caching Behavior#

The RTT‑App follows a conservative, cache‑first approach:

• Fetch the server state periodically.
• Cache the last known value.
• Fall back to the cached value when offline.
• Expire the cache only after a safe interval.

This ensures stable behavior even in degraded network conditions.