# 0012: The footer renders a derived projection, never a stored percentage

Status: accepted. Supplemented by decisions 0013 and 0014, which supply the
first two real adapters. Every rule below still holds.

Decision 0002 established that usage observations carry provenance. This
decision fixes how those observations become the five answers the footer owes
the user, and what the footer must do when it cannot answer.

## The contract

`lumbridge-core` owns an append-only `UsageLedger` of `UsageObservation`s per
`AccountProfile`. An observation is a fact: consumed units, an optional ceiling,
an optional provider window, a provenance, and the time it was observed. The
ledger never edits an observation and refuses one that predates the newest entry
for that profile, because an append-only stream cannot move backwards.

`UsageLedger::project` derives the footer view. Reported facts keep their own
provenance. Anything the projection computes is labelled `Estimated` even when
every input was provider-reported, because a derived rate is not a reported
fact.

## Rules the projection enforces

- A burn rate needs at least two observations inside the same window, the same
  unit, and a minimum elapsed sample. One reading yields no rate at all rather
  than a rate of zero.
- A window fraction requires a reported ceiling. A self-hosted endpoint has no
  quota, so it reports consumption and explicitly says no ceiling exists.
- An exhaustion estimate is withheld when the window resets first. Telling a
  user they will run out after the quota has already refilled is worse than
  telling them nothing.
- An `Unavailable` observation invalidates older facts for that profile instead
  of letting a stale reading keep rendering as current.
- An expired window is reported as rolled over, not as a frozen percentage from
  a window that ended.
- Staleness is surfaced, not hidden: past the staleness budget the value still
  renders but its confidence drops to unknown and the footer says so.

## What the UI may do

A compact surface may substitute the short provenance label. It may not drop the
label, round an estimate into a reported fact, or substitute a placeholder
number for a missing one. `FooterUsage` therefore returns explicit phrases —
`usage unavailable`, `reset time unavailable`, `burn rate unavailable`,
`no usage source` — and the GPUI shell renders unavailable values in the quiet
tone with the provenance chip coloured by source rather than by value.

A pane with no harness attached shows the detached roll-up. It never inherits
another pane's account, because attributing one agent's spend to another is the
same class of untruth as inventing the number.

## Status of the numbers

The GPUI shell's observations are still a declared spike fixture. The path is
real: the fixture records through the same ledger and reads back through the
same projection, so the honest-gap behaviour above is exercised on every frame
rather than asserted only in tests.

The first real adapter now exists in `lumbridge-harness` (decision 0013) and its
integration tests drive a synthetic Codex transcript through this ledger and
this footer, proving every rule above survives the adapter path. Pointing the
running shell at a live account spawns a process against the user's own
subscription, so it stays a separate, user-consented step.

All arithmetic is integer arithmetic and fractions are carried as permille, so a
rendered percentage cannot drift from the stored fact.