Dashboard history — where the charts read from

All three bars plot the daily snapshot series. That store started 2026-02-28 and every row expires after 400 days — by design it can never hold 2018. Meanwhile all three monthly stores already hold 8 years of AppFolio history for Camellia (99 / 98 / 102 months) and nothing on the dashboard reads them for the bars.

Same move on each metric — and after Fable's check, all three are repoints: the data is already in the tables for every one of them. The one extra piece is a small monthly cron so the occupancy/revenue stores keep advancing (today they only fill from a one-off script and stop at June 2026). Crucially, the read is one server-built series per metric — not two fetches stitched in the browser — so the bar can never disagree with the number above it.

The 400-day TTL is on the daily store only (snapshots/compute.ts:28). It was put there to keep that store bounded, back when it was purely a live-dashboard cache. Two honest things about it:

• Removing it does not give us history backward. You can't snapshot a day that already passed — so the 2018→now bars come from the monthly stores regardless. TTL removal only stops future daily rows from deleting themselves.
• It's still worth removing, and cheap. One row per property per day — Camellia is 170 rows total right now. Even 100 properties × 365 days ≈ 36k small rows/year. Negligible. Letting it accumulate forever costs ~nothing and means we never again lose a day of real granularity. Revisit if/when volume actually bites.

1. Monthly series route — one server-built series per metric (NOI, revenue, occupancy) from the monthly stores, all uncapped, date-range reads, honest "since <month>" coverage per property. No UI change yet.
2. Repoint the three bars (collapsed sparkline, big trend, drill-down) to it; delete the client-side stitching; window token rides the request. Closes #5260 for these three. For the daily-only metrics, stop offering a lying "All time".
3. Live writer for the occupancy/revenue stores — a sliding 3-month re-derive on the existing nightly financials cron, so they advance past June 2026.
4. TTL removal — separate PR: drop TTL_DAYS, range-query the reader, ADR-0013 one-liner. "Preserves daily history from today forward."
5. Docs truth-up (the stale "backfill not run" lines, the NOI catalog provenance).

Verdict: CONFIRMED — WITH CHANGES. The direction is right and is already the data layer's own doctrine (monthly no-TTL stores are the history; daily is the short cache). Fable pushed back on three things, and it was right on each:

• Occupancy is already backfilled — I had that wrong. UnitRentSnapshot holds 12,240 rows / 102 months for Camellia, 2018-01 → 2026-06, occupancy on 100% of rows. The repo docs saying "backfill not yet run" are stale. So occupancy is a repoint, same as the other two.
• But none of the occupancy/revenue stores has a live writer. They were filled once by a script and will freeze at June 2026 unless we add a small monthly re-derive cron (NOI already has one — that's why it reaches July). Repointing without that ships a chart that quietly stops this summer.
• "Two-tier" must mean one server-built series, not client stitching. Mixing daily + monthly on one line produces a visible step at the seam — Fable measured it on real June numbers: NOI $53.9k (daily rolling) vs $50.0k (closed books), rent $126k vs $130k. So: the three money/occupancy bars read monthly only, built in one route, with the window token in the request. That also closes the existing ticket #5260 ("I click rent income all time and only see back to February").

Also flagged: only Camellia has monthly stores today (16 other properties have none) — the series must fall back per property and label what arrived, never blank or lie. And ~14 other summary-table metrics (work orders, delinquency, tours…) have no monthly store at all — for those, dropping the TTL is the only lever, and it only helps from today forward.