Zero, Unknown and Learning
Guide status: Foundation contract. Last reviewed 14 August 2026. Visible state labels may evolve, but zero, Unknown, Learning and Unavailable must remain meaningfully distinct.
Purpose
Empty and incomplete states are part of the operating system. This guide prevents Liva 7 from manufacturing certainty when data is absent, still accumulating or cannot be accessed.
The four states
Zero means the system made a valid measurement for the defined scope and the resulting value was 0. It requires a known denominator or eligible scope where relevant.
Unknown means the value cannot currently be established. The source may be incomplete, identity may not resolve, processing may be pending or the definition may not be satisfied.
Learning means valid evidence is accumulating but the current amount or duration is not sufficient for a settled judgement. It should show what is being learned and, where possible, the condition for review.
Unavailable means a required source, permission, service or capability cannot be used in the current context. This is different from a measured zero and from temporary learning.
Apply the distinction
- A placement with verified exposure and no recorded interactions may have zero interactions.
- A configured placement with no valid exposure data has an unknown interaction value, not zero.
- A new experiment receiving valid exposure may be Learning until its planned review condition.
- A metric requiring a source the merchant has not connected is Unavailable.
Present the state usefully
Show the state beside the value, not only in a distant tooltip. Include relevant scope, freshness and the safest next step. Do not replace Unknown with 0 in calculations or rank Unknown items as if they performed poorly.
Learning should not become a permanent waiting room. Provide the owner, next review point or missing condition. Unavailable should explain whether the resolution is a connection, permission, plan, product or service decision without pressuring the merchant to widen access unnecessarily.
Safe fallback
Customer-facing behaviour should use an approved default when eligibility or a personalised decision is Unknown, Learning or Unavailable. Internal interfaces should preserve the actual state and avoid invented estimates. If a last-known value is operationally useful, display it only with its timestamp and stale status.
You are finished when
- a valid zero cannot be confused with missing evidence;
- Learning has a defined subject and review condition;
- Unavailable identifies the missing capability or dependency; and
- the customer experience remains useful in every state.