Glossary
Canonical Power Oracle terminology for sessions, splits, recovery, and denominators.
Use these terms consistently across Power Oracle pages and clients.
Split-aware work and power analysis API
The canonical product phrase for Power Oracle. It emphasizes that the API computes work and power while preserving split structure.
Session-first, split-aware
The canonical compute-model phrase. It means the request starts with full session context and then models the ordered work segments inside that session.
Session elapsed time
The top-level duration_seconds. This is the full elapsed session duration.
Split
A meaningful work segment inside the session. A split can be a round, interval, set, movement chunk, or grouped work segment, depending on what timing is actually known.
Split active time
The split-level duration_seconds. This is active work time for that split only.
Recovery
Time after a split that belongs to session accounting but not to the split active-power denominator.
rest_seconds_after
The request field used to represent known recovery after a split.
Unattributed duration
Time that exists in session elapsed time but is not accounted for by split active time plus recovery. Returned as unattributed_duration_seconds.
Movement rollup
A session-level aggregation of work and occurrences for a movement across splits. Movement-specific power is only reported when timing is directly attributable from isolated splits.
Grouped split
A split that contains multiple movements in the same work segment. Grouped splits preserve totals but do not let the API invent per-movement timing.
Isolated split
A split where one movement owns the timing directly. This allows movement-specific power attribution in movement rollups.
Denominator semantics
The meaning of the time value used when computing average power. Power Oracle makes these semantics explicit in both field structure and response notes.
x402
The payment protocol used for the paid compute routes. The server issues a 402 challenge in PAYMENT-REQUIRED, the client satisfies that requirement, and then retries with PAYMENT-SIGNATURE.
L402
The Lightning payment protocol supported on the same paid routes. The server issues a 402 challenge in WWW-Authenticate: L402 ..., the client pays the invoice, and then retries with Authorization: L402 <token>:<preimage>.