Freshness and fallbacks
How readers report market age, delivery state and safe fallback behavior.
A bundled snapshot can contain real market data with a real observation timestamp and still be stale.
Public clocks
| Field | Question it answers |
|---|---|
| Snapshot timestamp | When was the market state observed? |
| Component timestamp | When was the ordinary, multivariate or Sports component observed? |
| Generation identity | Which immutable set supplied these components? |
| Health checked time | When did the service inspect the current delivery state? |
BizHedge uses a six-hour live refresh window for market freshness. Health can return HTTP success while reporting a degraded state. Consumers must inspect the body rather than treating status code alone as freshness evidence.
Fallback states
Before activation, readers can use the bundled release snapshot. Afterward they resolve the server-selected immutable manifest. If a later read fails, a warm reader can retain its last verified generation; a cold reader fails closed rather than returning a mutable legacy object as current data.
The prior coherent generation remains preferable to a newer incomplete one. Health reports the retained generation together with the manifest failure so a consumer can distinguish available-but-stale evidence from an active refresh.
What freshness does not mean
Freshness does not prove that a market will accept an order, that a quoted price remains available or that the owner can fill the advisory quantity. BizHedge exposes a time-bounded observation and an advisory calculation. Execution remains outside the product boundary.