NovAPR Technologies

Alive States · prototype 0.3

Honest feedback for interfaces.

Alive States keeps track of what is true in an interface: what the server confirmed, what is still in flight and what failed. It never shows a request as saved before the server says so.

What it decides

Three things shape the feedback.

The same action can deserve a different response depending on how long it usually takes, whether the device is online, and how much a mistake would cost.

  • Latency

    Quiet when it is fast

    It learns how long reads and saves usually take, separately for each. An answer that arrives quickly gets no ceremony. A slow one gets visible feedback, then context, then a way to stop waiting.

  • Connection

    Offline is a state

    It reads online and offline status and slow-connection hints when the browser offers them. Work done offline is kept on the device and marked as waiting. It is not dropped or reported as saved.

  • Risk

    Sensitive means explicit

    A reversible action may show its new value at once, marked as unconfirmed. A sensitive action waits for explicit confirmation and keeps the last confirmed value until the server answers.

The lifecycle

Alive States decides. LavaMorphism shows it.

Alive States is the single source of truth for data and operations. LavaMorphism never decides an outcome: its surfaces only react to the phase Alive States reports.

How each Alive States phase appears in LavaMorphism
PhaseWhat it meansLavaMorphism shows
unavailableNo data yet. Nothing is invented.Idle. Matte obsidian.
cachedThe last confirmed data, from an earlier read.Idle. Obsidian at rest.
freshJust read from the source.Settled. Obsidian.
optimisticA save is in flight and the new value is visible, marked unconfirmed.Pending. Mercury flows out from where you acted.
syncingA save is in flight and the confirmed value stays visible.Pending. Mercury, with the confirmed value in place.
offlineNo connection. The work is kept on the device.Queued. Mercury pools and waits.
confirmedThe server confirmed.Ember sweeps across for about a second, then obsidian.
failedThe server refused. The confirmed value returns and the draft is kept.Failed. Mercury drains away.

Past the usual time for that action, a pending phase becomes slow and the mercury stalls. If two versions disagree, the front wavers halfway until you choose one.

Where it runs

Used in a real app.

In BetterGains, editing the calories of a logged meal runs on Alive States: the card keeps its identity, the draft stays apart from the confirmed value, and a rejected or stale response cannot overwrite what you typed.

Try the same logic in the lab

The SDK

React 19, with a core that needs no framework

Components for a boundary, a card, a value and a layout transition, plus hooks and reusable policies. The core reducer takes plain events:

let state = initialState(lastConfirmed)
state = aliveReducer(state, {
  type: 'WRITE', id, next,
  optimistic: risk !== 'high',
})
// only after a validated, successful response:
state = aliveReducer(state, {
  type: 'RESOLVE', id, data: serverData,
})

Prototype 0.3 · local package, not on npm yet

Haptics are optional and off by default. Reduced motion is respected.