Historical data and analysis

Snapshots land on exact UTC boundaries — :00, :15, :30, :45 — and every dataset in a cycle shares one timestamp. That is what makes an end-of-day figure an end-of-day figure rather than a reading taken four minutes past midnight, and it is what lets slots be joined and bucketed by arithmetic instead of by tolerance windows.

• Twenty metrics per slot, recorded for the whole book and for each client
• One row per slot, written once and never revised
• Every slot stamped with how stale the underlying marks were
• Off-grid recomputes reach the screen but are deliberately not recorded

Full resolution is kept for a configurable recent window, then rolled up to hourly and retained. The roll-up keeps minimum, maximum and last for each metric rather than an average, because averaging is what hides the dip to 0.95× coverage that was the only thing worth seeing in that hour.

• Retention set by an administrator, not per user
• Legal hold: set the raw window to zero days and nothing is purged
• Purges are logged, so a gap in the series has an explanation
• Breach, call and liquidation events are captured exactly and never purged

One database engine, deliberately. Where the TimescaleDB extension is present the history tables are created as hypertables; where it is not, the same schema runs as plain PostgreSQL tables and everything else is identical. It is an accelerator, never a requirement — so the choice of managed host stays yours.

The series is not a data lake you export and forget. Build dashboards from a catalogue of nine datasets, chart any metric over any window, put a trend column beside a live figure, group and total the rows, export to CSV or Excel — and save a query as a watch, so a condition you care about raises an alert the moment it turns true rather than the next time somebody looks.